Dear preCICE community,
I am working on a FSI problem considering the following mesh:
The flap is 0.04m long and is divided in 100 segments in the fluid side (OpenFOAM) and 50 in the structural side. When I simulated a similar domain (i.e. TUrek Hron benchmarks) I used the rbf-compact-tps-c2 like this:
<mapping:rbf-compact-tps-c2 support-radius="0.01" direction="write" from="Fluid-Mesh-Faces" to="Solid-Mesh" constraint="conservative"/> <!-- z-dead="true"/> -->
<mapping:rbf-compact-tps-c2 support-radius="0.01" direction="read" from="Solid-Mesh" to="Fluid-Mesh-Nodes" constraint="consistent"/>
But the simulation crashes at the second timestep giving the following message:
---[precice] WARNING: The coupling residual equals almost zero. There is maybe something wrong in your adapter. Maybe you always write the same data or you call advance without providing new data first or you do not use available read data. Or you just converge much further than actually necessary.
---[precice] ERROR: All residual sub-vectors in the residual-sum preconditioner are numerically zero. Your simulation probably got unstable, e.g. produces NAN values.
I have tried also different values for the support-radius and I also tried with the rbf-thin-plate-splines mapping, both with or without the z-dead option. Both crash with the same error.
If I use the simple nearest-neighbor mapping, the simulation runs correctly giving good results.
I have been using that same mappings for other very similar cases without errors. I don’t understand exactly what is going on.
I attach an extract of the preCICE output regarding the residuals in the three cases:
nn.txt (4.3 KB)
splines.txt (2.3 KB)
tps.txt (2.3 KB)
Hi @Claudio ,
may I ask you to provide your complete
I guess you use preCICE in 2D mode, right? In this case, the
z-dead wouldn’t make any difference (or any sense).
Do you ramp up the velocity? Your time-step size is very small and it might also be that there is not enough ‘change’ in your coupling data so that the acceleration scheme crashed and produces a zero column in the Newton scheme. What happens if you switch your acceleration to an Aitken acceleration?
Hi @DavidSCN ,
you can find it attached: precice-config.xml (4.2 KB)
No, the models are 3D, even if the problem is intrinsically 2D.
I don’t ramp up the velocity, I am initializing the fluid with potentialFoam and, in the data I sent before, I was loading the structure with a fraction of the load. I have just tried with 100% of the load (which indeed is very low) the simulation with tps crashes a little bit later (10 timesteps). If I look at the residuals, in this case the force residual stops decreasing before converging to the required value, while the displacement residual continues decreasing until the acceleration produces a zero column.
The timestep is indeed very low, that is because in the past I had problems with the OpenFOAM mesh deformation with larger timesteps. I might try to go back to 1ms.
Alright. Does the simulation work if you use Aitken acceleration as it is done e.g. here tutorials/precice-config.xml at 6d90ae3eb179113beb400e472c8832e29a48db9b · precice/tutorials · GitHub?
I have computed this case as well in the past and you can find my config file here matrix-free-dealii-precice/precice-config.xml at master · DavidSCN/matrix-free-dealii-precice · GitHub
It worked with local RBFs as well, though there is a NN mapping used by default. As you see, I used the 1ms time-step size as well and ramped the velocity (still much faster than the in the Turek case) using groovyBc. Maybe it helps you, I cannot find an obvious issue in your configuraiton.
I have just tried with Aitken acceleration and it works, 1ms of timestep and incremental load (starting from 20%). Just for a recap:
- Nearest Neighbor mapping and IQN-ILS acceleration works fine, being really fast in convergence (2-3 iterations)
- RBF mapping and IQN-ILS acceleration does not work (all other parameters being the same). I am using serial-implicit coupling with Solid first (basically because it was the best configuration I found in other experiments). It looks to me that sometimes the forces (subject to acceleration) converge too much, while displacement residuals remain almost constant. This didn’t happen to me in other experiments and I am not finding a way to overcome this with a suitable configuration of the mapping.
- RBF mapping and Aitken acceleration works well, even if convergence is slower (4-5 iterations, sometimes many more).
I have seen your configuration and now I might try parallel coupling, as you did, so that both forces and displacements benefit of acceleration.
I am trying to recreate the perpendicular flap tutorial case. I used the same fluid files as is in the tutorial and modified the mesh using calculiX however, I get this error which is very similar to @Claudio.
Adapter writing coupling data…
Writing DISPLACEMENTS coupling data with ID ‘2’.
Adapter calling advance()…
—[precice] relative convergence measure: relative two-norm diff of data “Displacement” = 0.00e+00, limit = 5.00e-03, normalization = 4.00e-11, conv = true
—[precice] relative convergence measure: relative two-norm diff of data “Force” = 0.00e+00, limit = 5.00e-03, normalization = 2.16e+03, conv = true
—[precice] All converged
—[precice] WARNING: The coupling residual equals almost zero. There is maybe something wrong in your adapter. Maybe you always write the same data or you call advance without providing new data first or you do not use available read data. Or you just converge much further than actually necessary.
—[precice] ERROR: Attempting to add a zero vector to the quasi-Newton V matrix. This means that the residual in two consecutive iterations is identical. There is probably something wrong in your adapter. Maybe you always write the same (or only incremented) data or you call advance without providing new data first.
I am not sure why this is the error and would appreciate any help.
precice-config.xml (2.4 KB)
Did you also try with Aitken? If everything stays zero for a while in the beginning of your simulation, IQN usually fails with this error.