[CoSim] Rigid Body Solver

[mtnzguillermo]

📝 Description A simple solver to represent rigid bodies that move or rotate but do not deform (e.g. a bridge cross section moving inside the fluid domain or a TMD attached to a structure).

It solves each degree of freedom (3 displacements and 3 rotations) as an independent SDoF solver, but it organizes the data so it can be easily coupled which other solvers when more than one DoF is necessary. One can assign structural properties, a root point excitation or a forced motion to each of the DoFs. Each of them can also be "activated"/"deactivated", so an SDoF case can be also solved with this solver.

Additions:

• The rigid body solver (rigid_body_solver.py, rigid_body_process.py, input_check.py)
• A wrapper so it can be used with CoSimulationApplication (rigid_body_wrapper.py)
• Two coupling operations to communicate with FluidDynamicsApplication if necessary (compute_resultants.py, impose_mesh_displacement.py).
• Two data transfer operators to sum to convert from several data values to one value and vice versa (copy_single_to_distributed_vectorial.py, sum_distributed_to_single_vectorial.py).

This pull request remains a draft until the following tasks have been done:

• [ ] Reference point for moments/rotations on coupling operations or solver, but not both.
• [x] Test in MPI and OpenMP
• [ ] Decide a good default value for rho_inf (Generalized Alpha scheme).
• [x] Check that exceptions raise when necessary.
• [x] Big cleanup
• [x] Add extensive comments to explain the solver
• [ ] Write tests for all files
• [x] Write Run() method for standalone usage
• [x] Add restart option
• [x] Review notation so it is not misleading
• [x] Put initial conditions to the root point excitation
• [ ] Create an SDoF wrapper which uses the RigidBodySolver, so the Sdof solver can be deleted.

[mpentek]

Thanks for the draft. Will be working here. ping @RiedlAndreas

[loumalouomega]

Nice contribution, the question is why a rigid solid is on the CoSIM?, it is something generic that may fit in other apps like the structural and even the core

[philbucher]

Nice contribution, the question is why a rigid solid is on the CoSIM?, it is something generic that may fit in other apps like the structural and even the core

That is indeed a good point @mpentek @mtnzguillermo I guess we should discuss this

[mpentek]

@loumalouomega I can see of 2 reasons.

1 - temporary - for now the testing and development is simpler, as one only need the CoSim to test and use. It also is a typical simplification to use such a structural model when coupling it to something else. Many parts of CoSim do not need extended compilation, being purely in python.

2 - long term - I think there is nothing specifically speacking against having it in the StructMechApp other than that is not so lightweight and not everyone might want to compile it.

Appart from these points, we are definitely open where to place it, whereh CoSim, Core, StrucMechApp or even perhap WindEngApp (which is currently a draft).

[mtnzguillermo]

Nice contribution, the question is why a rigid solid is on the CoSIM?, it is something generic that may fit in other apps like the structural and even the core

I think the main argument in favor of placing a Rigid Body solver in CoSim is that it's meant to be coupled with other solvers. Without coupling, it's nothing more than a pretty simple SDoF solver.

Do you think an SDoF solver would be used standalone in Structural? I believe an SDoF is in 95% of the cases easier to solve it by hand.

If the Rigid Body solver is always going to be used together with CoSimulation, it makes sense to me that it is placed there. Then the user doesn't even need to compile Structural when coupling it with CFD, for example.

What do you think?

[mpentek]

Adding to the list of ToDo-s:

• [x] Output time is not rounded (essential for restart), see here
• [ ] Takes the restarting capabilities from here, makes it aligned to the standard Kratos way
• [ ] Restart implicitly takes care of writing to the output files (it should use the ascii file writer and the Kratos restart)
• [ ] Thinks about adding the variables as solution step variables, otherwise functionalities, such as a CoSim predictor, might have a problem, as on the model part there is no historical data
• [ ] When the RBS simulation ends, it outputs a lot of stuff that we don't need

[philbucher]

Thinks about adding the variables as solution step variables, otherwise functionalities, such as a CoSim predictor, might have a problem, as on the model part there is no historical data

this should be solved/improved in #8950 but we should discuss it first!

[rubenzorrilla]

I wonder if we shouldn't implement the rigid body solver in the KratosCore. IMO this is a key capability that can be used not only in the context of co-simulation. Is there any technical limitation to move it to the core? (of course I'm only speaking about the rigid body motion part).

[loumalouomega]

I wonder if we shouldn't implement the rigid body solver in the KratosCore. IMO this is a key capability that can be used not only in the context of co-simulation. Is there any technical limitation to move it to the core? (of course I'm only speaking about the rigid body motion part).

I commented that long time ago (i think, the coversation is to long I cannot find myself)

[loumalouomega]

I wonder if we shouldn't implement the rigid body solver in the KratosCore. IMO this is a key capability that can be used not only in the context of co-simulation. Is there any technical limitation to move it to the core? (of course I'm only speaking about the rigid body motion part).

I commented that long time ago (i think, the coversation is to long I cannot find myself)

But then it would be interesting to port the code to C++

[rubenzorrilla]

I wonder if we shouldn't implement the rigid body solver in the KratosCore. IMO this is a key capability that can be used not only in the context of co-simulation. Is there any technical limitation to move it to the core? (of course I'm only speaking about the rigid body motion part).

I commented that long time ago (i think, the coversation is to long I cannot find myself)

But then it would be interesting to port the code to C++

Even in Python would be a great contribution. We can think on migrating it in the future.