Added Pressure ExchangeData, hexaedral elements and Modal Dynamic Modus

[MatthiasFreimuth]

This PR enhances the adapter with respect to the following functionalities:

• Support of Pressure as a read exchange variable
• Support of faces for hexaedral elements e.g. to create facecenters meshes using hexaedral elements (without connectivity)
• Support of the MODAL_DYNAMIC Modus of CalculiX

Closes issue #90 Related to issue #89 (Related to issue #87)

Once this PR is accepted the new functionalities should be described in the adapter's documentation.

[boris-martin]

Why read at 1*8 instead of 0?

[MatthiasFreimuth]

0 should also work.

[KyleDavisSA]

Is keeping it 1*8 fine?

[boris-martin]

I think as long as the mesh uses only one type of elements it should work. In the long run if we want to support "hybrid" meshes we should change this but for now I expect it to work. (Unless maybe there is exactly one element?)

[boris-martin]

Hi @MatthiasFreimuth,

Thank you very much for this PR. I already had a quick look but will make a more complete review in a few days.
A few questions to be sure I understand everything:

• Pressure can be read, because we convert it to a distributed load in CalculiX. However there is no Pressure write, because Calculix only outputs forces on nodes, but no pressure. Right ?
• For MODAL DYNAMIC simulations, we must first compute the eigenmodes, then configure the simulation with this keyword, and everything else related to the adapter works the same way? Or are there necessary precautions? I read that Temperature loading or residual stresses are not allowed, but I'm not good enough with solid mechanics to fully understand this. Residual stress only occur when using non elastic material, if I understood it right.
• I see that for faces mesh, you look whether the first (second?) element is a tetrahedron or a hexaedron. Do you think it would be doable to refactor the code to allow mixed meshes? I'm thinking of some kind of loop over all elements where for each element we look up its type, but maybe there's a pitfall I didn't see. I imagine for now you implemented non mix mesh because that was enough for your requirements.

[MatthiasFreimuth]

Hi Boris,
regarding your questions:

Pressure can be read, because we convert it to a distributed load in CalculiX. However there is no Pressure write, because Calculix only outputs forces on nodes, but no pressure. Right ?

Actually I just implemented pressure as a read variable, because I need it that way and never thought about wether writing pressure is possible or would be useful for any kind of simulation. I'm not sure if CalculiX only outputs forces.

For MODAL DYNAMIC simulations, we must first compute the eigenmodes, then configure the simulation with this keyword, and everything else related to the adapter works the same way? Or are there necessary precautions? I read that Temperature loading or residual stresses are not allowed, but I'm not good enough with solid mechanics to fully understand this. Residual stress only occur when using non elastic material, if I understood it right.

For MODAL DYNAMIC simulations you first need to calculate the eigenmodes, which can be stored by CalculiX in a file with the ending ".eig". (This doesn't have to be a coupled simulation!) I guess everything else related to the adapter works similar, even though I'm not quite sure wether the adapter is able to perform a clean exit of the simulation or not. Regarding your question about the temperature loading and residual stresses I'm unsure too, as my background isn't in structural mechanics either.

I see that for faces mesh, you look whether the first (second?) element is a tetrahedron or a hexaedron. Do you think it would be doable to refactor the code to allow mixed meshes? I'm thinking of some kind of loop over all elements where for each element we look up its type, but maybe there's a pitfall I didn't see. I imagine for now you implemented non mix mesh because that was enough for your requirements.

I did not think about mixed meshes yet, because i did not need them, thats true. But right now I see no pitfalls for the implementation for mixed meshes you suppose.

[boris-martin]

I tried running the "perpendicular flap" tutorial with a modal dynamic analysis and it crashes (apparently because Quasi-Newton acceleration doesn't converge). Did you manage to get it running? Or am I using it wrong? I simply used the default .inp file and changed the DYNAMIC analysis with a FREQUENCY followed by a MODAL DYNAMIC analysis.

*INCLUDE, INPUT=all.msh
*INCLUDE, INPUT=fix1_beam.nam
*INCLUDE, INPUT=interface_beam.nam
*MATERIAL, Name=EL
*ELASTIC
 4000000, 0.3
*DENSITY
 3000
*SOLID SECTION, Elset=Eall, Material=EL
*STEP, INC=1000000

*BOUNDARY
Nfix1, 1, 3
*BOUNDARY
Nall, 3

*FREQUENCY, STORAGE=YES
780

*MODAL DYNAMIC DIRECT
1.E-2, 5.0

*CLOAD
 Nsurface, 1, 0.0
 Nsurface, 2, 0.0
 Nsurface, 3, 0.0
*NODE FILE
 U
*EL FILE
 S, E
*END STEP
```^


EDIT: I also tried running the elastic tube 3D and got a segfault when starting the simulation, any tips ?

[MatthiasFreimuth]

Hi Boris,
as far as I know the Frequency card and the Modal dynamic card should each be a separate step. I always do two separate simulations, one to generate the .eig file with CalculiX (FREQUENCY; STORAGE=YES as STEP) and then the coupled simulation (MODAL DYNAMIC as STEP). The approach to leave the rest of the input file the same is basically correct.
I did not try any of the tutorial cases with the new features yet, but for the testcases I used it worked fine, but there I only used explicit coupling so far.

What did your output look like that you think the problem was that quasi newton does not converge?

[boris-martin]

Hi Matthias,

It converges now, having both frequency and modal dynamic in one step seems to be what broke the simulation.
However now I face the problem of a zero displacement of the flap (i.e. nothing happens)
I don't know yet whether the reading fails or somehow the object if fixed. Any tips ?

Frequency file:

*INCLUDE, INPUT=all.msh
*INCLUDE, INPUT=fix1_beam.nam
*INCLUDE, INPUT=interface_beam.nam
*MATERIAL, Name=EL
*ELASTIC
 4000000, 0.3
*DENSITY
 3000
*SOLID SECTION, Elset=Eall, Material=EL

*BOUNDARY
Nfix1, 1, 3
*BOUNDARY
Nall, 3

*STEP, INC=1000000
*FREQUENCY, STORAGE=YES
750
*END STEP
*NODE FILE
 U
*EL FILE
 S, E

*CLOAD
 Nsurface, 1, 0.0
 Nsurface, 2, 0.0
 Nsurface, 3, 0.0
*NODE FILE
 U
*EL FILE
 S, E
*END STEP

Dynamic file:

*INCLUDE, INPUT=all.msh
*INCLUDE, INPUT=fix1_beam.nam
*INCLUDE, INPUT=interface_beam.nam
*MATERIAL, Name=EL
*ELASTIC
 4000000, 0.3
*DENSITY
 3000
*SOLID SECTION, Elset=Eall, Material=EL

*BOUNDARY
Nfix1, 1, 3
*BOUNDARY
Nall, 3

*STEP, INC=1000000
*MODAL DYNAMIC DIRECT
1.E-2, 5.0

*CLOAD
 Nsurface, 1, 0.0
 Nsurface, 2, 0.0
 Nsurface, 3, 0.0
*NODE FILE
 U
*EL FILE
 S, E
*END STEP

Also, I noticed running the frequency analysis with preCICE doesn't work. (The adapter says that preCICE doesn't support frequency analysis)
So I need to run without preCICE participant to compute the frequency first. Shouldn't we tweak this to ismply discard preCICE if frequency analysis is selected?

[MatthiasFreimuth]

In the frequency file there seems to be at least one END STEP too much, but I dont know if that changes anything. The zero displacement might also come from a too big Time Step for the Modal Dynamic Step. Or have you tried it without the DIRECT Keyword?
The Frequency Analysis should always be done without preCICE. I'm not sure if it makes sense to discard preCICE in that case or if it is maybe enough to just document it well.

[KyleDavisSA]

The perpendicular flap moves when I use explicit coupling, but not implicit coupling. Examining dyna_precice.c, I see there is no variable 'icutb', which I think controls the time stepping if I am not mistaken. This variable is used to reset the displacements when convergence is not reached. I am happy to merge this while only supporting explicit coupling for now, and we can work on extending to implicit coupling.

[precice-bot]

This pull request has been mentioned on preCICE Forum on Discourse. There might be relevant details there:

https://precice.discourse.group/t/how-to-define-mesh-connectivity-information-when-using-nearest-projection/1713/3