I am performing FSI simulations with OpenFOAM and CalculiX. In particular, I am trying to set up a case with a pre-deformed solid, which is subjected to a preload . My idea was:
Dynamic CalculiX simulation to deform the solid
Export deformed solid shape to .stl, create fluid mesh which fits the deformed interface
Start the FSI simulation
→ CalculiX: Use initial (undeformed) geometry file, initialize with the deformation and tension results from step 1
In his master’s thesis [1], @KyleDavisSA used the restart-option in CalculiX. He stopped the FSI simulation, exported the deformed CalculiX mesh to .stl and built a new OpenFOAM mesh with the new geometry, using the solid deformation and the mapped flow field as initial conditions for the new simulation. This worked well and it is similar to what I want.
However, I feel like my approach might be fundamentally wrong. The way I understand it, CalculiX receives the force at the interface from OpenFOAM in the coupling step. This might be the source of the problem, maybe the internal tension state of the solid is “incompatible” with the pressure coming from the fluid?
This question is more on a theoretical level, but I can supply some files if anyone thinks it should work.
I’m using CalculiX 2.16, OpenFOAMv2012 and preCICE-2.2.1.
I’m trying to do something very similar. Were you ever able to sort our your issues?
I think it may come down to what the CalculiX adapter considers as the initial state when the FSI analysis begins from a CalculiX restart file. My understanding is that restarting a CalculiX sim from a previous solution is essentially like adding a *STEP to your input file prior to the step that is being used to apply the loads from the fluid solver. If CalculiX adapter deems the geometry prior to the restart step as the “initial” geometry, I presume it would combine the displacements from the restart step AND the FSI step and pass those back to the fluid solver. If the fluid mesh already exists at the shape after the restart step (like you describe in your steps), then the deformation applied from CalculiX to the fluid solver will be incorrect.
I think what you should do is TURN OFF data exchange initialization and pass DisplacementDeltas instead of Displacements. My understanding of what happens under these settings is that even though the CalculiX restart step contains displacements you tell preCICE to never pass them to the fluid solver. Instead, you only pass the change in displacement due to the FSI step to the fluid solver, and that is exactly what it needs because it already exists at the shape after the initial dynamic CalculiX deformation.
Does this make sense? Does anyone see any issues with this approach?
Sorry for the late answer.
For my master’s thesis I chose to set this topic aside and use another initialization setup.
But your idea sounds plausible. Unfortunately I am not able to test it now.
One more question: You address the displacement communication. Don’t you think the force is another problem? Since there is no such thing as “force delta” (similarly to “displacement delta”), I figured that the force at the interface nodes is overwritten by preCICE which could cause the solid solver to diverge. What do you think?
More testing in this direction would certainly be very interesting! Although I’m moving on to a different subject in my future work, I’m looking forward to reading about your progress.
I’ve slowed down on this project a bit too, but did want to jump on and answer your question. I do not think that a force delta is necessary. My understanding is that when executes a CalculiX sim that loads a restart, the restart data loaded in acts as a previous *STEP. So, the deformed solid will arrive pre-stressed. My understanding is that the CalculiX adapter communicates forces to the next *STEP in the CalculiX input file. The effect of the first simulations forces remain because they were used to pre-stress the model.
I think about it this way: you have an input file from your 1st step (CalculiX simulation to deform the solid), so let’s call it deform.inp. When you start the FSI simulation in step 3, you have a different input file for Calculix; let’s call that one fsi.inp. The first line of fsi,inp is:
*RESTART, READ
and all this is doing is telling Calculix to take the *STEP (and potentially multiple steps) from deform.inp and drop it into fsi.inp.
For me, I only see one problem with your steps. When you read in a *STEP from a dynamic CalculiX simulation the physical time it took to run that *STEP is read in. So, your time steps between the CalculiX side and the OpenFOAM side of your fsi simulation won’t match in your solution outputs. The only way I can see around this is to run a Static CalculiX simulation in step 1 and use the *TIME RESET parameter to make the static simulation accumulate no physical time. There is no *TIME RESET parameter for dynamic simulations in CalculiX, as far as I can tell.
you’re right, that’s a very plausible way of describing the initialization method in CalculiX.
The *TIME RESET function also sounds promising, especially since a static simulation usually suffices for creating an initial state.
I’m going to mark your answer as solution, but sadly I am not able to test it.
Thanks for the interesting discussion.