This issue occurred while I’m using OpenFOAM v7 - CalculiX 2.16 - preCICEv2.0.0 for a FSI simulation.
The Case is about a flow passes a bluff body with a flexible cantilever.
And I’m running this case on a HPC using 36 processes.
At first, I was trying to solve the “memory access out of range” but I apparently failed, then I was thinking can this be a problem since I used a 3D mesh for solid and a 2D mesh for fluid (front and back are assigned with empty BC). Then, I checked it online and many suggested that the cause of this problem can be different, therefore, I posted it here to get more advice.
Has anyone ever encountered similar issues? Any suggestions?
Hi everyone, here are some updates since I built a new mesh for Calculix, not suprisingly, errors occured, but it seems that they are still similar to errors as I posted above. See here:Fluid.log (18.7 KB) Solid.log (7.5 KB) stderr.log (26.1 KB)
I don’t quite understand that why the errors keep happenning since this case was totally workbale with my previous orignal CalculiX mesh. The CalculiX mesh I’m now using: all.msh (182.0 KB) fix1.nam (319 Bytes) flap.inp (837 Bytes) surface.nam (15.6 KB)
Yesterday, I switched back to the orignal CalculiX mesh, and it can be run without any problem, so I’m pretty sure the OpenFOAM side and the precice.xml file are just fine, the problem is on the CalculiX side.
The reason why I want to re-run my simulation using a new CalculiX mesh is because the results were not very satisfying and I suspect this was probably because the element type I used in CalculiX mesh was C3D8, and also considering the number of cells in my mesh is not very large, now I want to use C3D20R to avoid potential shear locking, to see whether this can give me a better result.
Hope these information has specified the situation I’m currently dealing with. If you need more information please fell free to reply.
I suspect that this is due to a 2D-3D mapping problem.
In your CalculiX coupling mesh, the y coordinate seems to be the span-wise axis (coordinates -0.0003 and 0.0003).
Currently, you ignore the z coordinate for your write mapping (option z-dead). You might need to change this to y-dead. And maybe you also need this for the read mapping.
Could you try to visualize both coupling meshes in paraview (fluid and solid, only the coupling meshes, so the meshes that preCICE exports) and upload a screenshot?
Is your span-wise width the same in OpenFOAM? Is your span-wise axis the same in OpenFOAM?
One thing I don’t quite understand is that since there is only one layer of cell I extruded on Z-direction, I surely want to ignore the write / read mapping on Z-direction, therefore, I think probably it’s fine to use “z-dead” option, I’m I correct?
The span-wise width for both OpenFOAM and CalculiX meshes is the same, equals to 0.01 m (1 cm). The axises are the same, too.
Suggested by the posted discussion, I also changed the BC for front and back from “empty” to “wall” for the mesh file and also the initail condition files (p / U / displacement / vorticity).
Unfortunately, the error “RBF linear system has not converged” still occured.
I’m thinking does the explicit coordinates of starting nodes in both meshes have to be exactly the same correspondingly? I’m just asking, even though I think this won’t arouse any serious issues since I used RBF mapping for non-conforming meshes.
You do have more than one layer of cells in z-direction for preCICE. Does this come from your type of elements you use in CalculiX?
Is what you plotted the fluid mesh?
I suspect that the mapping in y-direction might still be tough or RBF. Even if it converges you might not be too happy with the results.
What you could try is to split the mesh up in two parts: one top layer and one bottom. For both fluid and solid. And then define mappings top<->top and bottom<->bottom. And then switch off the mapping in y-direction.
