Open rfaasse opened 3 months ago
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
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?
to my understanding the expected behavioru is what is shown in here
(variables freed in the ExecuteFinalizeSolutionStep).
pinging @KratosMultiphysics/technical-committee for comments
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
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.
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 https://github.com/KratosMultiphysics/Kratos/discussions/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: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
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: