[GeoMechanicsApplication] Degrees of freedom should be freed in between stages

[rfaasse]

As a user, I would like to be able to run a multi-stage analysis, where I fix degrees of freedom in one stage, and free them in the next.

Background
This issue was found by an external user (see #12277). A 2-stage problem was presented, where displacements were fixed in the first stage and should be free in the second. However, the dofs were never freed.

A way to fix this is to add a loop in the ModifyInitialGeometry function in geomechanics_analysis.py, a virtual method which is called in the initialize of a stage, before (and that's important) the process initialization:

for node in self._GetSolver().GetComputingModelPart().Nodes:
    for dof in dofs:
        if node.HasDofFor(dof):
            node.Free(dof)

Where in the worst case we can use a hard-coded list for the dofs (see snippet), and in the best case we can retrieve a dof list from the node

dofs = [KratosMultiphysics.DISPLACEMENT_X, KratosMultiphysics.DISPLACEMENT_Y, KratosMultiphysics.DISPLACEMENT_Z,
        KratosMultiphysics.WATER_PRESSURE, KratosMultiphysics.ROTATION_X, KratosMultiphysics.ROTATION_Y, KratosMultiphysics.ROTATION_Z,
        KratosMultiphysics.TEMPERATURE]

If we get permission, we can use the reported case LysmerBoundaries-K0.zip as a test case.

This needs discussion with CIMNE about the philosophy of orchestrator multi-stage analysis/initialization, either:

• Change the model state with respect to the previous stage, specifically for the boundary conditions/constraints.
• Start from scratch in each stage.

[RiccardoRossi]

Hi,

this is a bit strange to me. In principle degrees of freedom are fixed by processes in the InitializeSolutionStep and are freed in the FinalizeSolutionStep ... so that they should be definitely free between one stage and the other

[rfaasse]

Hi @RiccardoRossi,
Thank you for reaching out! We are using our ApplyVectorConstraintTableProcess which makes use of the ApplyComponentTableProcess and/or ApplyConstantScalarValueProcess from Kratos Core.

However, they don't seem to have an override for the FinalizeSolutionStep or Finalize, therefore at least the process itself doesn't seem to free the dofs if I'm correct.

Is this something that could be implemented in the core processes?

[RiccardoRossi]

to my understanding the expected behavioru is what is shown in here

Kratos/kratos/python_scripts/assign_scalar_variable_process.py

Line 143 in e55171c

fixity_status = False

(variables freed in the ExecuteFinalizeSolutionStep).

pinging @KratosMultiphysics/technical-committee for comments

[roigcarlo]

As far as I can see @rfaasse is correct. The ApplyConstantScalarValueProcess does not free anything previously fixed.

My understanding is that they can not make use of the process we would normally use for that (assign_scalar_variable_process.py) as it only exists in python.

If we want the dofs to become free we have to implement the ExecuteOnFinalize as we do with the Assign_scalar_variable_process

[rfaasse]

That is a good point @RiccardoRossi, I didn't know this functionality was there in the python process. However, as @roigcarlo mentioned, indeed for the case described here, we can rely only on the C++ implementation of the processes and therefore, cannot use the python implementation of finalize solution step.

It would help us a lot if that functionality could be moved to the C++ process (that would hold for ApplyComponentTableProcess as well as ApplyConstantScalarValueProcess).

FYI @mcgicjn2 @avdg81 @WPK4FEM on the issue of freeing dofs.