FSI/cylinderFlap_2D/OpenFOAM-deal.II gives IQN error

[MakisH]

With preCICE v2.1.0 (release candidate, 295d27), either something changed in behavior, or some check became stricter:

Timestep 1 @ 0.002s
_______________________________________________________________________________________
    SOLVER STEP     |  LIN_IT   LIN_RES    RES_NORM   RES_ABS      U_NORM     U_ABS 
_______________________________________________________________________________________
  0  CST  ASM  SLV  |       1  0.000e+00  1.000e+00  1.115e+02    1.000e+00  7.714e-05  
  1  CST  ASM  SLV  |       1  0.000e+00  2.800e-04  3.122e-02    6.721e-04  5.184e-08  
  2  CST  ASM  SLV  |       1  0.000e+00  8.246e-08  9.193e-06    2.823e-06  2.178e-10  
  3  CST  ASM  SLV  |       1  0.000e+00  4.042e-10  4.506e-08    2.300e-08  1.774e-12  
  4  CST  ASM  CONVERGED! 
_______________________________________________________________________________________
Relative errors:
Displacement:   2.300e-08
Residual:   3.427e-12
v / V_0:    7.020e-03 / 7.020e-03
---[precice]  relative convergence measure: relative two-norm diff = 5.50865e-11, limit = 5e-05, normalization = 19916.5, conv = true
---[precice]  relative convergence measure: relative two-norm diff = 1, limit = 5e-05, normalization = 4.46315e-05, conv = false
---[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.

The FSI/flapPerp_2D/OpenFOAM-deal.II is not affected.

[uekerman]

This is due to a new check introduced in https://github.com/precice/precice/pull/787

[davidscn]

I rebuild preCICE yesterday in the evening and it worked with the deal.II adapter (in 2D). I think this is a problem of the initial ramp, where not very much is happening and we just write the same data due to nothing is happening in the first time step. I get also a warning in the beginning, but not an error. In 3d, it might be heavier, since the out of plane direction writes always zero data.

[MakisH]

So, what do we do then?

[davidscn]

Remains the error, when you remove the ramp?

Options are 1) raise a warning instead of an error in preCICE 2) remove the 3d deal.II examples 3) modify the ramp

[MakisH]

Could you please try again with the release candidate?

This error I get with the 2D case, so I don't understand how removing the 3D examples would help.

[davidscn]

This error I get with the 2D case, so I don't understand how removing the 3D examples would help.

My bad, i will check it again, though I'm working with the parabolic profile and groovy.

[davidscn]

This looks really seriously, I can reproduce it. It fails in the first iteration (for some strange reason not with groovyBC, but with the original one): The problem is (my best guess), that the displacement doesn't converge according to the prescribed limits, but the initial data (zero) is passed to the solid solver again due to reloading.

Quick workaround/fix: Switch to a serial-implicitscheme

[uekerman]

The problem is the missing data entry in the acceleration

        <acceleration:IQN-ILS>
            <data name="Displacement" mesh="Solid_mesh"/>
+           <data name="Stress" mesh="Fluid-Mesh-Centers"/>
            <preconditioner type="residual-sum"/>
            <filter type="QR1" limit="1e-6"/>
            <initial-relaxation value="0.1"/>
            <max-used-iterations value="50"/>
            <time-windows-reused value="10"/>
        </acceleration:IQN-ILS>

However, then, dealii destroys the SolverInterface early in the second timestep

---[precice]  Implicitly finalizing in destructor

I guess due to convergence problems?

All in all, I think the preCICE error message here is meaningful.

[davidscn]

Hm, I'm currently running parallel-implicit without acceleration in both data sets, should not cause problems.

So yes, looking at the solver data, the error is right, deal.II receives all the time the same data leading to all the time the same output..

I guess due to convergence problems?

This should happend only, when the simulation is terminated abnormal.

[uekerman]

We used to have a check for this:

https://github.com/precice/precice/blob/b2b33b1efba24bdbdee22f1ed3b1901cd3552fab/src/cplscheme/ParallelCouplingScheme.cpp#L54-L55

But we removed it at some point as it does not always make sense.

For the nonlinear dealii solver it also crashes with serial-implicit for me (have not tested the linear one yet).

[davidscn]

Yes this is related to #77 . It runs properly with a better config.

In your case, the problem should be different from this though.

[uekerman]

linear works

[uekerman]

Suggestion: let's remove this tutorial from the documentation until we have #77 ?

[davidscn]

linear works

parallel or serial?

I think we can not resolve this in a few hours without looking more in detail what's going wrong, so yes.

[uekerman]

parallel or serial?

with the linear solver both coupling schemes work

[MakisH]

I ran all the cases (flap/turek, 2D/3D, and linear/nonlinear) in serial. Here are some results: https://github.com/precice/precice/pull/835#issuecomment-661824557

[IshaanDesai]

Resolved in https://github.com/precice/tutorials/pull/116