Recreating the perpendicular flap tutorial with CalculiX and Gmsh


I´m currently writing my bachelor thesis about FSI. I came across PreCICE and would like to run some simulations with it.

I tried to rebuild the tutorial “perpendicular flap” to get a better understanding. Since I already know OpenFoam, I wanted to rebuild the mesh for CalculiX. I used Gmsh to create the mesh and the CalculiX-Launcher to convert the .msh file.
I built the mesh like the one from the tutorial, so I had the same number of elements.
After creating the .nam and the input file like in the tutorial, I ran the simulation and everything worked fine. CalculiX rendered everything perfectly.
But the transfer of the deformation to OpenFoam is faulty. The flap does not bend at the top, but at the bottom. I have attached a screenshot of the meshes.

At first it looks like the coordinate axes are wrong, but I checked that. The flap behaves exactly as in the tutorial, only the transfer to Openfoam is not correct.
Is there a way to find out how the deformation is transferred to OpenFoam?

Thank you very much and best regards,

Systen information:

  • Ubuntu 20.04 LTS
  • OpenFoam v2106
  • CalculiX 2.16

HI @Johannes_S,

From the first look it seems like the fixed boundary of the perpendicular flap has somehow been defined at the top of the flap rather than the bottom. Can you check if the fixed boundary part of the CalculiX mesh is really where it is supposed to be?

Hi @IshaanDesai ,

I checked everthing again, but the problem still remains. The fixed side is coordinate and axes -wise the correct one. The simulation of CalculiX runs perfectly fine. But there’s something wrong with OpenFoam.

Although I´ve found something else.
In the tutorial, the front and back sides were taken out in the interface_beam.nam file, which I didn’t notice at first. The nodes on the two sides must not be passed to OpenFoam, of course, because OpenFoam does not calculate in the Z-axis. This could have caused the problems from before, because OpenFoam tries to interpolate over these points anyway. But this doesn’t solve the problem in any way…

After taking out those nodes, however, I get the following error from OpenFoam:

PIMPLE: iteration 1
smoothSolver:  Solving for cellDisplacementx, Initial residual = 0.976232, Final residual = 2.23259e-17, No Iterations 2
smoothSolver:  Solving for cellDisplacementy, Initial residual = 0.998748, Final residual = 8.16963e-18, No Iterations 2
DICPCG:  Solving for pcorr, Initial residual = 1, Final residual = 0.00083934, No Iterations 76
DICPCG:  Solving for pcorr, Initial residual = 0.85702, Final residual = 7.34795e-09, No Iterations 98
time step continuity errors : sum local = 2.98789e-07, global = 2.17537e-08, cumulative = 29.3178
[0]PETSC ERROR: ------------------------------------------------------------------------
[0]PETSC ERROR: Caught signal number 8 FPE: Floating Point Exception,probably divide by zero
[0]PETSC ERROR: Try option -start_in_debugger or -on_error_attach_debugger
[0]PETSC ERROR: or see
[0]PETSC ERROR: or try on GNU/linux and Apple Mac OS X to find memory corruption errors
[0]PETSC ERROR: configure using --with-debugging=yes, recompile, link, and run 
[0]PETSC ERROR: to get more information on the crash.
[0]PETSC ERROR: User provided function() line 0 in  unknown file  
MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD
with errorcode 59.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.

And from CalculiX the following one:

Adapter calling advance()...
---[precice]  relative convergence measure: relative two-norm diff of data "Displacement" = 1.00e+00, limit = 5.00e-03, normalization = 1.18e+04, conv = false
---[precice]  relative convergence measure: relative two-norm diff of data "Force" = 1.00e+00, limit = 5.00e-03, normalization = 3.59e+15, conv = false
---[precice] ERROR:  Send using sockets failed with system error: write: Broken pipe

I´ve searched for a solution in this forum, but the only thing I´ve found is an article, which stated a problem with the IQN-ILS acceleration. Due to I haven´t done anything to the precice-config, the acceleration looks like this, which is the same as the tutorial:

          <data name="Displacement" mesh="Solid-Mesh" />
          <data name="Force" mesh="Solid-Mesh" />
          <preconditioner type="residual-sum" />
          <filter type="QR2" limit="1e-2" />
          <initial-relaxation value="0.5" />
          <max-used-iterations value="100" />
          <time-windows-reused value="15" />

Hi @Johannes_S

The simulation of CalculiX runs perfectly fine. But there’s something wrong with OpenFoam.

What do you mean by this? That you see sensible data on the side of CalculiX even if OpenFOAM is not working as expected?

If you are really trying to replace the existing perpedicular-flap tutorial then lets try something very simple; what is the difference between the mesh files you have created and the ones already provided in the tutorial? You can check this by running the diff command. As the tutorial already exists and works, lets try to figure out the error you are facing the perspective of the working case.

Hi @IshaanDesai ,

What I mean by this is that the flow data is transferred correctly from OpenFOAM to CalculiX. Because CalculiX calculates the correct deformation from it.
Therefore I assumed that the problem is not with CalculiX.

I compared the two meshes using the diff command. The result was that the numbering and therefore the coordinates are in a different order. (Understandable, since a different mesher was used.) The number of elements and nodes is exactly the same.

For a more detailed overview i have provided the files from CalculiX here:

Mesh: GigaMove 2.0
CalculiX config: GigaMove 2.0
Fixed side: GigaMove 2.0
Surface: GigaMove 2.0
Input file: GigaMove 2.0

PreCICE config: GigaMove 2.0

Hi @Johannes_S ,

Sorry for the delay in response, things have been busy. I’ll try to run your case and figure out what is the problem.

@Johannes_S I tried to run your case and it is not immediately clear what is going wrong. I get the same result as what you got above. I checked your CalculiX mesh and it seems to be fine. The mesh in itself is 3D with the second layer being at Z=1.0.

I see a better error than you did, which I think is because you have compiled preCICE in Release mode. If you want to see a better error then try compiling preCICE in Debug mode. If you have installed it via the debian package then you might have to change to a source installation.

I am not fully convinced that the problem is on the OpenFOAM side. I will check a few more things.

@IshaanDesai Okay, that sounds good, if the mesh is in order. I have adjusted the mesh as well as I could to the one from the tutorial.

That’s true, the problem is not necessarily on the OpenFOAM side, since I have not changed anything there.

I am very grateful for your efforts.

Hey @IshaanDesai ,

did you find anything yet? I am still stuck.

Meanwhile I will try antoher case to test more things. I guess the next one I’ll try to recreate with my own mesh is the elastic-3D-tube from the tutorial. Another motivation is this video I’ve found (Cylinder with a flap in OpenFOAM and CalculiX - YouTube) with the additional thesis linked in the description.
This is what i want to go for. Is there a probability that this person was activ in the forum too to build contact with?

Hi @Johannes_S

Sorry for the late response, the preCICE workshop is live this week so things are quite busy!

Did you try to compile preCICE in Debug mode and then run the perpendicular flap case again? That would give us more errors. I tried this quickly but did not see any difference in the error but perhaps you see something.

Similar to this case we can also try to help you recreate the elastic-tube-3d and also the Turek-Horn FSI2 benchmark. The person who uploaded the video to YouTube is no longer part of the team but I am sure we will be able to help you if you face any issues.

Hi @IshaanDesai

I haven’t tried it yet but I did some testing with the mapping and came up with some good results:

I tried the nearest neighbor mapping in 3D since 3D mapping worked in the elastic-tube-3d case with my own mesh created in GMSH! :slight_smile: And here it is, it worked! Sure i adjusted OpenFOAM to calculate in 3D and so did I with CalculiX. I assume there are some issues with the quasi 2D-3D coupling.

I will try to figure this out with the Debug mode somehow since it’s just a workaround for the Problem itself… But fortunately it’s some good news!

1 Like

Hi @Johannes_S ,

I plan to investigate some of the issues related to 2D-3D coupling in the coming weeks. Let me know if you’re having issues with it again.
(The links you posted to your files have expired, though)

1 Like

Hi @boris-martin ,

That is nice to hear, I appreciate it!

Here are the files again, I didn’t know I can upload them directly.

Mesh: all.msh (39.8 KB)
CalculiX config: config.yml (224 Bytes)
Fixed side nam-file: fix1_beam.nam (67 Bytes)
Input file: flap.inp (376 Bytes)
Surface nam-file: interface_beam.nam (2.8 KB)

The precice-config ist the same as in the tutorial, since I didn’t change anything, just like on the OpenFoam side.

Hi @Johannes_S ,

Can you please try your case again with the CalculiX adapter branch 2d3d_revamp?

Hi @IshaanDesai ,

I downloaded your mentioned CalculiX adapter and ran my case again. But unfortunately I am still getting the same issue as in the beginning.
I’ve updated my OpenFoam adapter to the newest since the one I used is quite old. However, even that didn’t change anything.

Hi @Johannes_S,

Are you sure that the CalculiX adapter is really using the branch which I pointed to? If you ave already compiled the adapter before, it is a good idea to run make clean before compiling the new branch again. Also, which version of CalculiX are you working with?

Something that we developers missed in the last months was that actually the error you see was also present in the original tutorial case. More information here: perpendicular-flap tutorial run with solid-calculix crashes with unexpected results · Issue #268 · precice/tutorials · GitHub
Hence I want to make sure that you are really using the adapter branch 2d3d_revamp

Hi @IshaanDesai ,

I have removed my old CalculiX adapter, ran make clean and recompiled the 2d3d_revamp with make again. I still get the same issue.

My guess is that I still use the old adapter somehow. Is there a way to make a clean uninstall of the adapter or find out which version of adapter I’m currently using?

I switched my CalculiX to version 2.19.

Hi @Johannes_S

Doing a make clean in the adapter repository should be sufficient in terms of cleaning up the adapter. So if you checkout the 2d3d_revamp branch and do make clean and then make again then you are in the correct state.

Which state of the preCICE-OpenFOAM adapter are you using? Also is it possible for you to try the same CalculiX case with SU2? This would give us an idea if something is going wrong on the fluid side.

Hi @IshaanDesai

Alright, then it should be in the correct state.

I’m currently running the newest version of the OpenFOAM adapter. I’ve already mentioned it here:

I’m not familiar with SU2.
But is there a possibility that I have an old or uncleaned tutorial case?
Since it worked for you, as you wrote on GitHub.