I adapted /tutorials-master/FSI/cylinderFlap/OpenFOAM-CalculiX (cylinderFlap) to a square pillar with a flap. It would report the error:
—[preciceAdapter] [DEBUG] Writing coupling data…
—[preciceAdapter] [DEBUG] Advancing preCICE…
—[precice] e[0m Mapping Forces0 conservative from Fluid-Mesh-Faces (ID 0) to Calculix_Mesh (ID 2) for dimension 0) with polynomial set to separate
—[precice] e[0m Mapping Forces0 conservative from Fluid-Mesh-Faces (ID 0) to Calculix_Mesh (ID 2) for dimension 1) with polynomial set to separate
—[precice] e[0m Mapping Forces0 conservative from Fluid-Mesh-Faces (ID 0) to Calculix_Mesh (ID 2) for dimension 2) with polynomial set to separate
—[precice] e[0m Compute read mapping from mesh “Calculix_Mesh” to mesh “Fluid-Mesh-Nodes”.
—[precice] e[0m Using tree-based preallocation for matrix C
—[precice] e[0m Using tree-based preallocation for matrix A
—[precice] e[0m Mapping Displacements0 consistent from Calculix_Mesh (ID 2) to Fluid-Mesh-Nodes (ID 1) for dimension 0) with polynomial set to separate
—[precice] e[0m Mapping Displacements0 consistent from Calculix_Mesh (ID 2) to Fluid-Mesh-Nodes (ID 1) for dimension 1) with polynomial set to separate
KSP Object: Coefficient Solver (solverC_) 1 MPI processes
type: gmres
restart=30, using Classical (unmodified) Gram-Schmidt Orthogonalization with no iterative refinement
happy breakdown tolerance 1e-30
maximum iterations=10000, nonzero initial guess
tolerances: relative=1e-09, absolute=1e-50, divergence=10000.
left preconditioning
using PRECONDITIONED norm type for convergence test
PC Object: (solverC_) 1 MPI processes
type: icc
out-of-place factorization
0 levels of fill
tolerance for zero pivot 2.22045e-14
using Manteuffel shift [POSITIVE_DEFINITE]
matrix ordering: natural
factor fill ratio given 1., needed 1.
Factored matrix follows:
Mat Object: 1 MPI processes
type: seqsbaij
rows=330, cols=330
package used to perform factorization: petsc
total: nonzeros=54615, allocated nonzeros=54615
block size is 1
linear system matrix = precond matrix:
Mat Object: C 1 MPI processes
type: seqsbaij
rows=330, cols=330
total: nonzeros=54615, allocated nonzeros=54615
total number of mallocs used during MatSetValues calls=0
block size is 1 > —[precice] e[31mERROR: e[0m The linear system of the RBF mapping from mesh Calculix_Mesh to mesh Fluid-Mesh-Nodes has not converged. This means most probably that the mapping problem is not well-posed. Please check if your coupling meshes are correct. Maybe you need to fix axis-aligned mapping setups by marking perpendicular axes as dead?
In my example, the z-axis is dead in precice-config.xml (2.7 KB) . And i adapted the ./fluid/system/blockMeshDict and ./solid/flap.inp to blockMeshDict.txt (6.8 KB) and flap.inp (56.2 KB) .
This is my fluid mesh:
Hi,
I have only tried to open your Fluid mesh and I have seen that it is very very thin. does it have the same thickness of the solid? Can you do it thicker and check if fluid and solid have the same thickness?
It is just a guess, I hope it helps.
Claudio
the z-dead entry for your Fluid-Mesh-Faces mesh is probably wrong since you use preCICE in 3D. The error might be hidden at the moment because you explicitly initialize the displacement field in the exchange data tag.
The other mapping fails. May I ask you to check the following:
export your solid mesh by adding an <export:vtk.. tag on the Calculix participant
If you don’t get any exported meshes due to a failing mapping, switch the mapping to a NN mapping, which should work
Run the following script on one of the Solid meshes, e.g. on Solid-Mesh-Calculix.init.vtk, by executing it with the mesh name as argument.
#! /usr/bin/env python3
import sys
with open(str(sys.argv[1])) as f:
seen = set()
for line in f:
line_lower = line.lower()
if "CELLS" in line:
sys.exit()
if line_lower in seen and line_lower.strip():
print(line)
else:
seen.add(line_lower)
The script checks and prints duplicated nodes in your vtk export. So, if you don’t get anything, everything should be fine. Duplicated nodes on the other hand lead to RBF problems.
Out of curiosity: Do you have a case description of this setup?
Actually, i set it need to calculate untile 10s in /system/controlDict. Did you meet this kind of circumstances?
Thanks for your help and advice!
Cucumber
Hi @littlecucumer ,
can you tell if the simulation stops for some error? OpenFOAM in general would stop only if it crashes for some reason, as the final time is driven by the adapter. What about the structural solver? And the precice config file?
The residuals seem very small so the Fluid solution should not be crashing, but it is hard to tell.
Before any further analysis, can you send the output messages of the solvers at stop?
Claudio
The stop means that both solver just stopped and there wasn’t any change in the screen for a long time as shown in the picture(fluid.log and solid.log).There was no hint of error.
f.log:
Hi @littlecucumer
It looks like you are using the configuration in which you have 50 outer correctors in OpenFOAM, that is why you have so small residuals. OpenFOAM is finishing its iteration, then hangs. Is the other solver CalculiX? What about the precice output?
Claudio
Yes, the OpenFOAM has finished its iterration. I think problem is in CCX.
Here is my xml:precice-config.xml (2.6 KB)
Should i change some parameter？Can you upload your xml? I want to make a comparison to find out where i am wrong.
The configuration looks good to me. I’ll send you mine (I don’t have it with me rn). In your log files I can only see the output of the two solvers. What about precice? how is the convergence going? How many iterations are you making for each timestep? I think that the issue might be there.
Claudio
I’ve been looking at your log files. They look good, also the last iteration at 2.496 seconds converges. For what I can see, the simulation advances correctly.
I haven’t much experience with the CalculiX adapter and CalculiX itself. So mine is just a guess: as you stop at around 2.5 seconds, is it possible that CalculiX advances by a different timestep or the solid simulation stops for some other reason? If you can share the case I can try to simulate it myself and try to see what happens, because from the logs and the precice configuration everything looks fine to me.
Claudio
You are accommodating! Thanks for your help. The case files are over 1Mb, so i could not upload it in post. My adress is littlecucumberzhou@163.com. Can you give me your e-mail adress or send me your xml-file and i would reply with case files.
littlecucumber
Hi @littlecucumer ,
I tried to simulate the case that you gave me. I have just made a couple of modifications to ease the convergence on the fluid side, to compute the forces on the flap and to display min/max velocity and pressure. The original case you gave diverged after a few iterations on my machine, I wasn’t able to reach 2.496 as you did. You are using OpenFOAM 5.x , I simulated the case with OF v2012, I don’t know if it could be the origin of the difference. I didn’t touch neither your precice config file nor the Solid configutation.
With this setup Dropbox - squareFlap_clean.zip - Simplify your life the simulion is running, I reached 3.5s and the flap is oscillating at about \pm 0.01.
Personally, I prefer to run Fluid and Solid in two different shells giving:
./runFluid -parallel
./runSolid
so that i can see what is going on and also the — [precice] output.
I hope it works also for you. Thank you for sharing the case, let me know if this setup is good also for you.
A final note: if the deformation of the flap looks a little bit “bumpy”, in my opinion it can be due to the nearest neighbor mapping, depending on the position of the nodes. I usually use mapping:rbf-compact-tps-c2 and the wetSurface is generally smooth
With your help, I have solved my problem which was mentioned in the title and a new problem.
To solve ‘ERROR: The linear system of the RBF mapping from mesh Calculix_Mesh to mesh Fluid-Mesh-Nodes has not converged.’ , I follow the advice from @DavidSCN and @uekerman. My mapping method: rbf-thin-plate-splinesr is not suitable for this case which is very thin compared with /tutorials-master/FSI/cylinderFlap/OpenFOAM-CalculiX (cylinderFlap). So i change it to N-N-mapping. It worked, but the operation stopped when it comes to 2.49s. This is the new problem.
To solve the new one, i contact with @Claudio and send my case file to him. Finally, i can simulate my case to 10s as i set in /controlDict and make wetSurface more smooth, because i change the STEP parameter NLGEOM to NLGEOM=NO in /flap.inp and i follow the advice from @Claudio that he said in post#17.
):
