[ToDo] [Core] Revamp Multifreedom Constraints

[matekelemen]

Motivation

As things stand right now, multifreedom constraints are handled in a rather rigid manner. They are assumed to be imposed using master-slave elimination (hence the name: MasterSlaveConstraint) and give off the impression that the constraint object is responsible for the imposition itself.

In reality, BuilderAndSolver alone is responsible for modifying the linear system to impose these conditions, and it alone can choose what method to use (for example, ResidualBasedBlockBuilderAndSolver can choose between a weird version of master-slave elimination and Lagrange multipliers). This leads to confusing setups in which "MasterSlaveConstraint"s are imposed using Lagrange multipliers ¯\_(ツ)_/¯.

Things get more complicated as I have to implement penalty-based constraint imposition, so I was thinking of refactoring the system a bit.

Proposal

First of all, rename the misleading MasterSlaveConstraint to MultifreedomConstraint.

At their core, multifreedom constraints represent linear equations of the form

a^i_0 u_0 + ... + a^i_j u_j + ... + a^i_n u_n + b^i = 0

where $u_j$ is the $j$-th DoF, $a^i_j$ refers to the coefficient of the $j$-th DoF in the $i$-th constraint equation, and $b^i$ stands for the constraint gap of the $i$-th constraint equation.

It stands to reason that MultifreedomConstraint should then only represent the (nonzero) coefficients, related DoFs and the constraint gap. @sunethwarna tells me that some types of constraints (especially in fluid dynamics) share coefficients between different equations, so MultifreedomConstraint should represent a set of equations. This is exactly how the interface is defined right now, so no changes there.

The first change would be getting rid of GetMasterDofsVector and GetSlaveDofsVector, since BuilderAndSolver decides on what imposition to perform, and how to partition DoFs into masters or slaves if master-slave imposition is chosen.

Then, we could get completely rid of the MASTER and SLAVE flags, and no longer flag any Nodes during constraint imposition. BuilderAndSolver would store an internal data structure that identifies masters and slaves.

Tasks

1) MasterSlaveConstraint => MultifreedomConstraint 2) LinearMasterSlaveConstraint => LinearMultifreedomConstraint 3) remove GetMasterDofsVector and GetSlaveDofsVector 4) adapt processes to these changes 5) have BuilderAndSolver perform the master/slave partitioning and store the result in internal data structures 6) implement penalty-based imposition

[loumalouomega]

I am OK with the changes, but this is super ultra deep change. But originally the constraints were managed in a very different manner, more like pure master-slave stuff. Me and @RiccardoRossi implemented the current B&S and we didn't change the name at the time.

FYI @KratosMultiphysics/technical-committee

[clazaro]

Hi everyone! If this task goes ahead, it would be good to try to solve issue #9801 (When using multipoint constraints, the eigensolver produces spurious modes and non-diagonal mass matrices).

[matekelemen]

I'm not an expert on eigenanalysis, but my takeaway after scrolling thorugh that issue is that having a separate constrained and unconstrained system would solve that problem.

If that's the case then yes, I'm planning to write a B&S based on ResidualBasedBLockBuilderAndSolver that stores both systems.

Note however that the B&S abstraction is going away in the future.

[RiccardoRossi]

Hi guys,

we (@rubenzorrilla, @roigcarlo and myself) are already on the move for a big proposal on this, and we will address that. We are currently blocked by project writing, but we have a quite clear roadmap. If you like in 10 days or so we could organize a meeting to explain our proposal

[matekelemen]

Hi, I'm assuming that's related to replacing the B&S. Can I get started on revamping the MFCs in the meantime, or are you touching them as well?

[RiccardoRossi]

well, the change will not touch the MPCs ... but you will still need them to hold the master and slave info...

[RiccardoRossi]

that is, how do you expect to pass the info of what is master and what is slave from outside?

[matekelemen]

I wouldn't pass them from the outside. Whatever class is responsible for imposing the constraints (currently the B&S) would decide which DoFs are masters and which are slaves.

[matekelemen]

An algorithmic partitioning into masters and slaves would have to follow these rules:

• pick one slave for each constraint equation
• slaves must be unique; no constraint equation must share slaves
• no Dof can be master in one equation and slave in another

Following these rules would not lead to a unique partition in general. To ensure reproducible partitions, we can also add the extra rule that slaves should be preferably the Dofs with the largest coefficient in each equation. This creates a priority queue for slaves in each equation.

[RiccardoRossi]

Hi @matekelemen, it has to be possible that the user prescribes what is master and what is slave ... for example because for any reason one wants to have a specifical dof to be used as master and others as slave.

This is not to say that it would be nice to have ways to only prescribe the relations to be complied with and the builder and solver takes care of imposing them. The problem of course is that while it is very nice and convenient (smaller system, conditiononing, etc) to use Master/Slave constraining the method is not general (and actually with a well limited scope). Of course when the restrictions are met the method has no competitor.

Now, if one wants to use lagrange multipliers (or penalty, or variations of it a-la augmented lagrangian) than this is easily accomplieshed by the element interface. What do you need that is not achievable by the element interface?

[matekelemen]

If someone wants to manually force a specific master/slave partitioning, that'll have to happen through DataValueContainer (MasterSlaveConstraint already has one).

How about this: 1) the user specifies which DoFs are slaves by Node+Variable pairs (same as now) 2) in the MultifreedomConstraint constructor, these pairs get converted to Dof IDs and stored in the member DataValueContainer under the SLAVE variable (we'd have to add SLAVE as a variable that has vector of ints type). 3) B&S (or whoever is imposing constrainrs) checks whether SLAVE is defined on a constraint. If it is, it uses the slave specified there. If not, it assigns a slave based on the algorithm I mentioned in my earlier comment.