DualMortarCoupling: Design clarification
The DualMortarCoupling
class has two members
Dune::BCRSMatrix<MatrixBlock> mortarLagrangeMatrix_;
Dune::BDMatrix<MatrixBlock> nonmortarLagrangeMatrix_;
From my understanding, I should currently not need access to the nonmortarLagrangeMatrix_
as a user. That seems to be confirmed by the lack of getters for it (in contrast, mortarLagrangeMatrix_
does have getters, even though (them being declared virtual) there might be other reasons for that).
That said, I can access nonmortarLagrangeMatrix_
because all members of DualMortarCoupling
are public (Q: this is probably meant to change, no?).
If I do, I will find something rather odd: I can first populate this member through the public function assembleNonmortarLagrangeMatrix()
(Q: why is there such a function and why is it public. Would I ever call this independently of setup()
?). Then I can access it. A subsequent call to setup()
would call assembleNonmortarLagrangeMatrix()
again (no harm done) but leave the field nonmortarLagrangeMatrix_
in a state that contradicts its name: It will actually contain the inverse of said matrix (D^-1
rather than D
in the nomenclature of the comments). So this is very confusing. I believe nonmortarLagrangeMatrix_
should, once it has been populated, not all of a sudden become its inverse. Something related is true for mortarLagrangeMatrix_
: From my understanding, once setup()
has finished, in its notation, it contains D^{-1}*M
rather than M
. Programmatically, this makes sense because it's the matrix that the user actually needs and it needs to be stored somewhere. But it's not the mortarLagrangeMatrix
contrary to what its name suggests.
If it's clear that the dual mortar coupling is only there to compute a matrix and obstacles (which I believe to be true -- correct me if I'm wrong), I would expect the nonmortarLagrangeMatrix_
and mortarLagrangeMatrix_
to be hidden and there to be public getters called e.g. getMatrix()
and getObstacles()
(the latter for obstacles_
).
To make it clearer, what I'm talking about, here's setup()
again in pseudocode:
setup()
{
NM = nm();
(M,obs) = ...;
NM = NM^-1; // Weird: NM now contains something contradicting its name
(M,obs) = (NM*M,NM*obs); // Weird: M now contains something contradicting its name
}
My problem here is that I do want to be able to access both nonmortarLagrangeMatrix_
and mortarLagrangeMatrix_
yet find that neither one contains what I expect after a call to setup()
.
Now, the easiest solution would be to introduce additional members but that would be undesirable because of the additional storage I believe. Would it be possible to make the matrices accessible when they're computed (to be overwritten later), though -- to that end, setup()
would have to be broken up into smaller steps.
So maybe (better ideas anyone?) one could break setup()
up like this:
setup1 = nm; // Afterwards, NM can be retrieved
setup2() { (M,obs) = ...; } // Afterwards, M can be retrieved
setup3() { // potentially invalidates NM and M but now the matrix NM^{-1}*M and obs can be retrieved
NM = NM^-1;
(M,obs) = (NM*M,NM*obs);
}