Fix given displacement BC's of FEA solver and CElasticityMovement

[pcarruscag]

Proposed Changes

Problem: If a given displacement boundary was cut during partitioning the solver would give wrong results.
Reason: When "de-singularizing" the stiffness matrix the column was only being deleted by the rank that owned the corresponding node.
Fix: All ranks delete the column (and update the load vector).

Before:

After:

PR Checklist

• I am submitting my contribution to the develop branch.
• My contribution generates no new compiler warnings (try with the '-Wall -Wextra -Wno-unused-parameter -Wno-empty-body' compiler flags).
• My contribution is commented and consistent with SU2 style.
• I have added a test case that demonstrates my contribution, if necessary.

[vdweide]

Did you check whether the results are identical, independent of the number of MPI ranks?

[pcarruscag]

I sure did. What I did not do was reproduce the problem in CElasticityMovement, that is only used for FSI and I only have 2D FSI cases, for which it is less probable that the boundaries will be cut.

[pcarruscag]

This had to be more intricate than first impressions suggested...
The displacements applied by CElasticityMovement to FSI interfaces come from the vertices, but halo vertices do not have the correct (i.e. communicated) coordinates which means for those the force vector contributions were not being computed correctly.
The known blocks (prescribed displacement) of the displacement vector are now set and communicated before "de-singularizing" the matrix, that process then grabs displacements from the displacement vector instead of from the vertices.

[economon]

LGTM. Just one comment

[economon]

There are several places where you do a similar operation as to what is done here.. have you considered reusing something like StiffMatrix.DeleteValsRowi() or creating a new version that suits what you are doing here within the matrix class to save some code by calling it instead?

[pcarruscag]

Yes definitely, especially since these operations can be performed more efficiently if the sparsity pattern is know. And there are other areas too, for example we currently add the contribution of the mass matrix to the stiffness matrix in a similar block by block way. But I would prefer to address all of those in one PR and avoid creating conflicts between ongoing PR's.

[rsanfer]

I think creating a StiffMatrix.DeleteValsColi() would do the job. There is some room for code saving in all of this implementation, but I agree with @pcarruscag, that could be done in an additional PR.

[rsanfer]

Hi @pcarruscag,
nice catch! This should have a positive impact on the parallel behaviour of the mesh adjoint, which required some particular treatment back in time to get it working. I've synced the PR with develop and will get it merged as soon as the tests pass.
Thanks!

[rsanfer]

I think creating a StiffMatrix.DeleteValsColi() would do the job. There is some room for code saving in all of this implementation, but I agree with @pcarruscag, that could be done in an additional PR.