Multiple flaps case with OpenFoam and CalculiX

Hello @Makis @uekerman
Hope you are all well.
I am trying to recreate the multiple flaps tutorial case with calculix instead of dealii.
I have one fluid domain and them 2 different solid domains and I am using the same precice-config file too.
When I have the following for read and write in ccx,

participants:

Solid-Downstream:
    interfaces:
    - nodes-mesh: Solid-Downstream-Mesh
      patch: flapBot
      read-data: [Stress-Downstream]
      write-data: [Displacement-Downstream]

precice-config-file: …/precice-config.xml

I get this error:

ERROR: Read data ‘Stress-Downstream’ does not exist!

I am guessing this is because ccx can only take certain key terms?
If that is so and I use force and displacement, then how would I modify the names to distinguish between the two flaps?

Would appreciate any help:)

Hi @mishal49,

the CalculiX adapter guesses the type of the data based on the beginning of the name:

In this case, however, the problem is that the CalculiX adapter does not support stresses:

You could use forces, instead.

1 Like

Perfect. Got it
Thank you so much!

1 Like

Hi @Makis
my fluid side and solid side are now running great individually however, when coupled the case diverges on the fluid side at first time step. The forces transferred to solid, I think, are too big. I tried changing the underrelaxation factor from 0.1 to 0.5 but that still resulted in the same.
I would like to point out that the flaps are arranged as below and fluid and solid density are the same (1060kg/m3)

This is what I have in my precice-config:

<coupling-scheme:multi>
  <time-window-size value="0.0001" />
  <max-time value="1" />
  <participant name="Fluid" control="yes" />
  <participant name="Solid-Upstream" />
  <participant name="Solid-Downstream" />
  <exchange data="Force-Upstream" mesh="Fluid-Upstream-Mesh-Centers" from="Fluid" to="Solid-Upstream" />
  <exchange data="Force-Downstream" mesh="Fluid-Downstream-Mesh-Centers" from="Fluid" to="Solid-Downstream" />
  <exchange data="Displacement-Upstream" mesh="Solid-Upstream-Mesh" from="Solid-Upstream" to="Fluid" />
  <exchange data="Displacement-Downstream" mesh="Solid-Downstream-Mesh" from="Solid-Downstream" to="Fluid" />
  <max-iterations value="50" />
  <relative-convergence-measure limit="1e-4" data="Force-Upstream" mesh="Fluid-Upstream-Mesh-Centers" />
  <relative-convergence-measure limit="1e-4" data="Displacement-Upstream" mesh="Solid-Upstream-Mesh" />
  <relative-convergence-measure limit="1e-4" data="Force-Downstream" mesh="Fluid-Downstream-Mesh-Centers" />
  <relative-convergence-measure limit="1e-4" data="Displacement-Downstream" mesh="Solid-Downstream-Mesh" />
  <extrapolation-order value="2" />
  <acceleration:IQN-ILS>
    <data name="Displacement-Upstream" mesh="Solid-Upstream-Mesh" />
    <data name="Displacement-Downstream" mesh="Solid-Downstream-Mesh" />
    <data name="Force-Upstream" mesh="Fluid-Upstream-Mesh-Centers" />
    <data name="Force-Downstream" mesh="Fluid-Downstream-Mesh-Centers" />
    <preconditioner type="residual-sum" />
    <filter type="QR1" limit="1e-6" />
    <initial-relaxation value="0.5" />
    <max-used-iterations value="50" />
    <time-windows-reused value="10" />
  </acceleration:IQN-ILS>
</coupling-scheme:multi>

Would appreciate your guidance on this.

My first thought the moment I saw the picture was: how does the mesh between the flaps move? I could imagine that the cells eventually break. Maybe check how the mesh evolves over time.

This makes sense. The case runs now and deforms as follows:


It is coupling well, but now I am wanting to address an issue that I have seen many posts on but no one solution.
As you can see, this has deformed by 10e-1 (0.01 secs) and then failed. This means that I have to map (restart) this 100 times to get to the end results at 1 sec. Is there a way to have this run longer without getting the mesh to tangle up so fast and fail?
I am currently following the procedure for restarting the case:
OpenFOAM:

  • I export the deformed fluid mesh and recreate the fluid domain using it.
  • This is imported back to OF and then I mapfields from the last timestep run to the new folder with the deformed mesh.
    CalculiX:
    -I also export the deformed solid geometry into PrePoMax and recreate node sets
  • import back deformed geometry into CCX and then run the coupled case.

For CalculiX, since the case fails abruptly, no .rout file is created hence, I use this approach. Of course, I am only now realizing that this might not be the best way to restart the case. Will it still give the same results? (maybe not :frowning: )

I looked at the following posts about restarting a simulation:
How can I restart a coupled simulation? - Using preCICE - preCICE Forum on Discourse
Restarting coupled FSI simulation with preCICE - Using preCICE - preCICE Forum on Discourse
FSI with CalculiX and OpenFOAM: Preload and pre-deformation of solid - Using preCICE - preCICE Forum on Discourse
CalculiX coupling Restart mode (uni-stuttgart.de)
Seems as though my fluid side set up for restart is fine, but the Calculix side is questionable. I re-ran the case to have a .rout file and then restart the CCX side without regeneration of mesh but the case fails at first timestep.
What may I do to prevent this from happening?

Would appreciate any help

You are using a tetrahedral mesh, right? Since we have mostly (only?) tested hexahedral meshes so far, I wonder if there is any issue with the force calculation on tetrahedral cells.

Hi @Makis
I tried to use structured grid as well, but I have had similar issues.
@KyleDavisSA used tetrahedral grids in his thesis and it seemed to work fine…I think?

Hi @Makis
I have an update. The case runs much longer with use of rbfMeshMotionSolver and the mesh does not tangle at all. The reason for divergence is a sudden high oscillation of the tip. Could this be because of the mesh? Or is there a way to tune the rbf parameters to make it run smoother?

Also, since it’s a 2D case, I just copied the same settings as the perp flap case, but my issue is visualization of the displacement after the run.
Using Laplacian, the x displacement would have contours on the x-y surface however, when I use rbf, the result for X rbfMotionCentersField shows contours only in the z direction and not on the x - y plane (the flap moves but the colors dont change :smiley: )

My dynamicMeshDict looks like this:

dynamicFvMesh dynamicMotionSolverFvMesh;

motionSolverLibs (“libfvMotionSolvers.so” “libRBFMeshMotionSolver.so”);

// Radial basis function solver
solver RBFMeshMotionSolver;

RBFMeshMotionSolverCoeffs
{
// Settings for the RBF solver
staticPatches (top symPlane);
movingPatches (flapTop);
//otherPatches (symPlane);
fixedPatches (inlet outlet);
interpolation
{
function TPS;
}
coarsening
{
enabled no;
}
}

and preciceDict:

FSI
{
rho rho [1 -3 0 0 0 0 0] 1060;

// The point displacement field is unused for the RBF mesh motion solver
namePointDisplacement unused;

// Specify the RBF cell motion field
nameCellDisplacement rbfMotionCentersField;

}

Should I maybe change the unused namePointDisplacement to like rbfMotion2 or something?
Would it then record displacement across the x-y plane?

@Makis @uekerman
I want to point out that the above was when my flap was one cell thick in both directions, however, when I make the flap 2-cell thick in the x-y plane the rbf solver behaves in a monumentally different way. The mesh tangles just like it does with displacementLaplacian.
Why is that?

When it comes to debugging FSI simulations, @DavidSCN has much more experience than me.

Hello, have you resolved your issue? I think it may be the additional mass effect caused by a density ratio of 1. Will the transmitted force cause divergence?

I have the case running however, I still have an issue with the contours not plotting right for displacement when I use the rbfMeshMotionSolver.