Dirichlet Boundary Conditions are not (always) handled correctly in PETScLUSolver
There seems to be a severe inconsistency in the handling of Dirichlet Boundary conditions in the PETScLUSolver
class. Depending on the internal settings these are handled by calling on of
applyDirichletBCSymmetrically()
applyDirichletBC()
on the sparse matrix object. Either of the two functions obtains the indices of the DoFs fixed by Dirichlet BCs by calling in turn
hyteg::applyDirichletBC( numerator, bcIndices, level );
which is coming from sparseassembly/DirichletBCs.hpp
.
The numerator
object that is passed from PETScLUSolver
to the two methods is the internal num_
attribute. The latter can be supplied externally as part of the constructor call. If that does not happen, it will internally be generated using the default BoundaryCondition
object we obtain from create0123BC()
.
That, boundary condition, however, can be completely unrelated to the boundary condition of the problem that is to be solved, when that uses its own mesh boundary flags and BoundaryUID
s. Originally there was this call inside solve()
:
num.copyBoundaryConditionFromFunction(x);
I don't understand the rationale why that was commented out in [193d58fd]. However, it is anyway at the wrong location, if symmetry is not given, as the copying only happens after assembleAndFactorise()
.
Cheers
Marcus