Collapsible Tube (OpenFOAM+CalculiX)

Good strategy! You could even use ASTE to mock the other participant: Artificial Solver Testing Environment (ASTE) | preCICE - The Coupling Library (even though it currently only works with explicit schemes).

No. The participants know nothing about each other’s internals (including their mesh) and you don’t need conforming meshes on the interface: that’s what data mapping is for.

Generally, the mesh resolution is defined by the needs of the solvers themselves. Most commonly, we use much finer fluid meshes than solid meshes, just because usually flows are much more complex than solid dynamics.

This is indeed a much more important point. By default, we use displacementLaplacian in our OpenFOAM tutorials, which is a rather simple mesh motion solver, that does not perform so well. But it just works most of the time.

If your mesh gets too skewed, then you could try, e.g., RBFMeshMotionSolver: Mesh Solver OpenFOAM Error - #10 by Makis

Thank you @Makis.
I corrected this and the one-way FSI still diverges.
calculix.out (9.2 KB)
foam.out (7.1 KB)
preciceDict.txt (459 Bytes)
precice-config_t.xml (2.5 KB)
config.yml (242 Bytes)

Why are you not exchanging and reading displacements in the fluid side?
Note that you need DisplacementDelta (displacements relative to the last coupling time window), in contrast to Displacement (relative to the original reference point).

Which brings me to the question: does the fluid simulation itself (without coupling, since anyway OpenFOAM does not read anything) converge?

Hi @Makis
Sorry for the delayed response. The simulation runs well with the fluid side alone.
I did manage to get the coupling to work by regenerating the meshes with fewer software packages. Maybe the import from one software to another led to more mesh discrepancies than expected.
However, the weird thing is that the case diverges at a certain point in time and the displacements in the x direction look like they are only happening on 3/4ths of the tube (Shown below).

One side:

Other side:

I tried to check if maybe my nodesets in CalculiX were only defining 3/4th of the pipe, but this is not the case.

Would appreciate any help.

I am not sure I understand what you expected to see in the figure and what you see at the moment. If this is indeed an issue, then it probably has something to do with the definition of the coupling interface. Maybe try exporting the coupling mesh from preCICE and visualize it:

The observation that the case eventually diverges is not surprising: even if everything in the setup is fine (check the above point), there are often aspects you can tune in the configuration.

Have you modified the configuration to also read displacements, as I wrote in Collapsible Tube (OpenFOAM+CalculiX) - #23 by Makis?

If yes, could you upload the config and any further logs, such as the preCICE iterations.log, convergence.log, and the logs of the solvers?

Hi @Makis
I adding the export lines to my precice-config however it says:

—[preciceAdapter] Loaded the OpenFOAM-preCICE adapter - v1.1.0 + unreleased changes.
MPI startup(): PMI server not found. Please set I_MPI_PMI_LIBRARY variable if it is not a singleton case.
—[preciceAdapter] Reading preciceDict…
—[precice] ERROR: The configuration contains an unknown tag export:vtu.

precice-config.xml (2.7 KB)

You mean this for one-way FSI correct?

it works for export:vtk/ but not vtu

I used the visualization and if I am not mistaken it is just like visualizing the mesh at any timestep.
The case does not even get through the first iteration and then diverges.

This is what the forces look like for the fluid-mesh-face-fluid after 1st iteration.

What configurations do you suggest I tune to get the case to converge? Is it more of a trial and error?

This looks more like an system-specific execution issue, which I assume you solved already. Can you reproduce it?

While one-way coupling is a natural first step when setting up a simulation, I would not expect a one-way FSI to converge. But this diverges too early, which hints an issue with the configuration.

Looking at your precice-config.xml:

      <participants first="Fluid" second="Solid" />
      <max-time-windows value="100000" />
      <time-window-size value="1e-4" />
      <exchange data="Force" mesh="Solid-Mesh" from="Fluid" to="Solid" />
      <exchange data="DisplacementDelta" mesh="Solid-Mesh" from="Solid" to="Fluid" />
      <max-iterations value="30" />
      <relative-convergence-measure limit="1e-3" data="DisplacementDelta" mesh="Solid-Mesh" />
      <relative-convergence-measure limit="1e-3" data="Force" mesh="Solid-Mesh" />
        <data name="DisplacementDelta" mesh="Solid-Mesh" />
        <preconditioner type="residual-sum" />
        <initial-relaxation value="0.1" />
        <max-used-iterations value="10" />
        <time-windows-reused value="1" />

The preciceDict you posted above:

    mesh              Fluid-Mesh-Faces;
    patches           (interface);
    locations         faceCenters;

The config.yml you posted above:

        - nodes-mesh: Solid-Mesh
          patch: interface
          read-data: [Force]
          write-data: [DisplacementDelta]

Some observations:

  • You are (correctly) exchanging both force and relative displacement, but (based on the preciceDict I saw before) you are not reading those displacements.
  • You are writing displacements from CalculiX, but not reading them in OpenFOAM, which looks unmotivated.
  • You are (correctly) using an implicit coupling scheme, but this requires a bi-directional coupling to work, as it is based on iterations and corrections. If one participant always gives the same values, preCICE will complain.

When you say “it diverges”, what exactly do you mean? Who is “it” and what errors / logs are you getting?

Correct. But this is, in this case, important to check that the definition of the mesh is correct. You previously observed that CalculiX was “only defining 3/4th of the pipe”. Do the Solid exports confirm this observation? Are the nodes there and always with the same results, or simply not there?

I don’t know how the results are expected to look like, but if you are applying a pulse at the inlet (as we do in Elastic tube 3D | preCICE - The Coupling Library), it is normal that the values near the outlet will stay constant for a few time steps.

Make it first bi-directional, we are not yet at the point that it needs fine-tuning.

The coupling scheme and acceleration method you have selected are appropriate, but the convergence measures may be a bit too relaxed. There are a few more parameters in the acceleration, which would need looking closer into the case. The mapping also looks reasonable.

Thank you for your response.

Yes, the command works when I use the tag export:vtk however, it gives the error when I change to export:vtu. Maybe the cluster system does not have anything for vtu files I am guessing.

The case diverges on the fluid side first and looks like a timestep continuity error.
Please find attached the log files for the fluid and solid side.
foam.out (72.1 KB)
calculix.out (56.7 KB)
I have the output files for the interface if you would like those as well

This one was a wrong case setup. I had the scales off for the two sides which is why it gave me that error regardless, of the boundary conditions used. I corrected this and the case is back to diverging after the first timestep. Sorry for forgetting to clarify this.

So, all the precice files are exactly like the tutorial elastic 3d case, however, the meshes and tube sizes are obviously different. Also, my boundary conditions are not the same as the tutorial. I have a fixed value velocity inlet and a fixed value pressure outlet. The case is supposed to align with experimental data and the pipe should stay almost intact with no displacement, i.e. the cross section should still be circular. Once I have this confirmed I can move on to higher displacement cases.
The fluid side works perfectly fine alone.

I would be happy to attach the updated case if it is needed.

Oh I understand now. Let me change this and get back to you.

I changed this.
Please find attached the preciceDict, precice-config.xml and config.yml files:
preciceDict.txt (700 Bytes)
precice-config.xml (2.9 KB)
config.yml (249 Bytes)

The case still diverged after the first timestep. Please find attached output files:
foam.out (70.4 KB)
calculix.out (56.7 KB)

I noticed something in my solid mesh;
I generate.nam, .sur and . msh files using cgx. I make my mesh in prePoMax and then run commands like ‘send all abq’ etc to generate precice required files.

The original file (solidtube.inp (730.8 KB)) results in a complete interface as shown however, when I split the file up into .nam files and a manually made .sur file, the mesh looks like the second image.


I noticed that the .sur file generated by cgx is not the same as the .sur file in the elastic tutorial case which is why I copy and paste sets manually to make the .sur file identical to the tutorial format.

I guess that could be the issue.

Do you maybe know how to generate those files without ruining with the original mesh?

Unfortunately, my CalculiX knowledge has reached its limits here… :confused: But this could be a nice question for

I have tried asking this on the ccx platform, but this is more of a preCICE file configuration issue which is why I was not really able to get an answer.

I am referring to this part, not the complete preCICE-related topic. Did you focus your question on this in the CalculiX forum? It is understandable that CalculiX users may overlook the topic if it seems to be preCICE-specific.

Hello @Makis
Yes, I had a conversation with a calculix user about this specific .sur file format issue.
The .sur file generated by CCX looks like this: Sinterface.sur (23.7 KB)
However, the one used in the 3D elastic pipe tutorial is: interface.sur (7.8 KB)
Hence, the question arises, why does preCICE have that specific format and how can it be generated without resulting in mesh distortion? Even though I can switch to a different mapping technique, some cases need the application of a distributed load in Calculix, which also needs a surface file.

As we try to figure this out, I switched my mapping technique to rbf-compact-tps-c2, which does not use any surface files, and the case has now coupled. I am still looking into the validity of results but so far it is coupling well and diverges after a bit, when a pressure wave hits, I think? Not sure and would love to get some clarity on this.

Linking to that conversation could be useful for the future reader.

I honestly have no idea about preparing CalculiX cases and the choices here… :man_shrugging: I think that @KyleDavisSA created this case (with Salome, if I am not mistaken). It could also be related to the nearest-projection mapping that the case uses and demonstrates.

Great! The RBF mapping is definitely a good choice.

Regarding the divergence when the pressure hits, it is probably time to tune the acceleration. Could you please upload your current precice-config.xml?

Unfortunately, I had this conversation in person and therefore, do not have a written version.
I have started a topic on the CalculiX platform and will see if I can get something more helpful for other users.
Please find attached the file:precice-config.xml (2.7 KB)
Should I change the relaxation factor perhaps?

You could add a filter to your acceleration:

<filter type="QR2" limit="1e-2" />

Complete coupling scheme:

      <participants first="Fluid" second="Solid" />
      <max-time-windows value="1000" />
      <time-window-size value="1e-4" />
      <exchange data="Force" mesh="Solid-Mesh" from="Fluid" to="Solid" />
      <exchange data="DisplacementDelta" mesh="Solid-Mesh" from="Solid" to="Fluid" />
      <max-iterations value="30" />
      <relative-convergence-measure limit="1e-3" data="DisplacementDelta" mesh="Solid-Mesh" />
      <relative-convergence-measure limit="1e-3" data="Force" mesh="Solid-Mesh" />
        <data name="DisplacementDelta" mesh="Solid-Mesh" />
        <preconditioner type="residual-sum" />
        <initial-relaxation value="0.1" />
        <max-used-iterations value="10" />
        <time-windows-reused value="1" />
        <filter type="QR2" limit="1e-2" />

Otherwise, the configuration looks good enough for a first try.
Could you please upload your iterations and convergence files (or did I overlook these?)?