OpenFoam fails with Floating point error

Using preCICE
, , ,
1

Hello,

I started with a 6-way coupling with OpenFOAM+CalculiX+XDEM.
I have reduced from 6-way coupling to 4-way and now to 2-way since there seems to be an issue only in between OpenFOAM and CalculiX.

I am using modified OpenFOAM solver PorouspimpleFoam, which takes into account for porosity in addition to normal things in pimpleFoam solver. (attached in the files).
This I need because this will be used for coupling with the 3rd solver (XDEM).
I have used this Fluid with Deal.II (2-way), and it works. This also works fine with 6-way and 4-way coupling. So it seems that issue is not with Fluid.

I have taken the tutorial flap case and replaced it with the Fluid folder I have.
With all the settings kept the same as the tutorial case, I get a PETSc error

smoothSolver:  Solving for cellDisplacementy, Initial residual = 0, Final residual = 0, No Iterations 2
[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 http://www.mcs.anl.gov/petsc/documentation/faq.html#valgrind
[0]PETSC ERROR: or try http://valgrind.org 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.

So read about the issues with rbf mapping (Parallel calculation problem for OpenFOAM-CalculiX Perpendicular flap tutorial) and replaced it with nearest-neighbour mapping.

<mapping:nearest-neighbor   direction="write" from="Fluid-Mesh-Faces"   to="Solid"     constraint="conservative" />
<mapping:nearest-projection direction="read"  from="Solid"     to="Fluid-Mesh-Nodes"   constraint="consistent" />

I get the following error:

smoothSolver:  Solving for cellDisplacementy, Initial residual = 0, Final residual = 0, No Iterations 2
#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::sigFpe::sigHandler(int) at ??:?
#2  ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3  void Foam::fvc::surfaceIntegrate<double>(Foam::Field<double>&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&) in "/home/prasad/OpenFOAM/prasad-7/platforms/linux64GccDPInt32Opt/bin/PorouspimpleFoam"
#4  Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > Foam::fvc::surfaceIntegrate<double>(Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&) in "/home/prasad/OpenFOAM/prasad-7/platforms/linux64GccDPInt32Opt/bin/PorouspimpleFoam"
#5  Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > Foam::fvc::div<double>(Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&) in "/home/prasad/OpenFOAM/prasad-7/platforms/linux64GccDPInt32Opt/bin/PorouspimpleFoam"
#6  ? in "/home/prasad/OpenFOAM/prasad-7/platforms/linux64GccDPInt32Opt/bin/PorouspimpleFoam"
#7  ? in "/home/prasad/OpenFOAM/prasad-7/platforms/linux64GccDPInt32Opt/bin/PorouspimpleFoam"
#8  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#9  ? in "/home/prasad/OpenFOAM/prasad-7/platforms/linux64GccDPInt32Opt/bin/PorouspimpleFoam"
./runFluid: line 40: 18109 Floating point exception(core dumped) $solver -case Fluid

When I use <coupling-scheme:serial-explicit> the Fluid crashes at t=0.0202, no matter what the mapping. (Just error changes between PETSc and one above).

When I use <coupling-scheme:parallel-explicit> the Fluid crashes at t=0.0302, no matter what the mapping. (Just error changes between PETSc and one above).

When I use <coupling-scheme:serial-implicit> the Fluid crashes at t=0.0102, no matter what the mapping. (Just error changes between PETSc and one above).This coupling-scheme was already present (commented out) in the precice-config.xml which is available with the tutorial case.

I need help in solving this issue.
What can I try next? Different Mapping or maybe different coupling schemes.
Or is it to do with something else.

I have attached my case with the solver inside (link).
Thank you very much in advance for all the help.

Here is the link for drive:

2

Hi @Alphaoo1,

the explicit coupling is no surprise that it very soon leads to instabilities. I would stick to an implicit coupling scheme. I find it very strange that the implicit scheme crashes earlier than the explicit and I think these two are different issues.

If you run the same case with as close configuration as possible to this one, then I assume you don’t get any problems, right? Then, we could isolate that the problem is with changing from pimpleFoam to PorouspimpleFoam.

In implicit couplng, we need to store and reload checkpoints. We currently checkpoint all the registered objects of several types, but could you check that before storing and after reloading a checkpoint, all the additional fields of your solver are restored correctly?

It is also interesting that you did not have a problem with deal.ii, but you have with CalculiX. I assume that in deal.ii you used the linear model? In CalculiX the solver is non-linear, which should actually introduce less issues.

Finally, to check the mapping, you can always export and visualize your preCICE meshes.

3

@Makis Thank you for your reply.
I did start with the pimpleFoam solver instead of PorouspimpleFoam.

I was able to run a 6-way simulation. But it seems that the domains are not aligned.

6-way_domain_mismatch
6-way_domain_mismatch1472×768 73.9 KB

Is there way to change the orientation of the OpenFoam+Calculix domain from XZ to XY ?
I think, for OpenFoam I can do with transformPoints -rotate '( (0 0 1) (0 1 0) )'. But please let me know if I am wrong.

I also think I won’t need to change anything else since in both cases fluid flows in +X direction.

I am not sure about CalculiX though.

4

@Alphaoo1 I have no idea how to do it in CalculiX, but probably you need to change something in the file Solid/pre_flap.fdb, which is used as input for CGX (see Solid/mesh.sh).

If you manage to rotate the case, it would be a perfect contribution, as this issue is already open since longer and did not have a clear reason to get implemented yet: https://github.com/precice/tutorials/issues/34

5

@Makis Yes. I am looking into changing the orientation of CalculiX flap from XZ plane to XY plane. I will update once I have done the necessary changes.

I have got a suggestion from Martin KRASKA to check the command ‘move’ in the cgx handbook. An example with extensive use of positioning commands is this one.

I mentioned it here in case if somebody runs into similar issue.

-X- SOLUTION -X-

About the initial issue. This error seems to be caused because of the misalignment of OpenFOAM and CalculiX domain. I have tested this out with the base tutorial flap case from preCICE. If you use the transformPoints -rotate '( (0 0 1) (0 1 0) )' after the blockMesh, this error can be replicated.

I was able to perform the 6-way coupling after adjusting the alignments of the Fluid and XDEM domains. (Since I know this, it was easier to do.)

Vol_porosity_6-way.0002
Vol_porosity_6-way.00021472×533 145 KB

Fig: Volume Porosity in FLuid with heavy and light particles.

force
force1472×768 223 KB

Fig: Forces applied by particles on the flap.

Another thing to mention here is that in config.yml, I used read-data: [Forces, Forces0].
It seems that the sequence (and the naming) matters, if I switch their position the second one is not mapped on Solid participant. (I know the keyword to be used is Forces in case of Calculix)
I used the <export:vtk> feature to check if the forces were mapped on CalculiX, they were. (Could not upload vtk file)

After this, I will also try and implement the summation action.
Currently, the value of Forces is very small and insignificant, all the major forces come from Fluid Forces0.

Thank you for all the help from preCICE community. :smile:

1 Like
6

Amazing! :smiley:

Next step: Try using RBF or Nearest-Projection mapping. It should fix the “staircase” shape of your flap.

7

Yes. Already done, it works just fine. :smile:

CCX_flap_disp_rbf_iso1
CCX_flap_disp_rbf_iso11472×768 38.1 KB

8

7 posts were split to a new topic: 2D-3D Coupling OpenFOAM-DUNE