Relative two-norm diff = -nan at beginning of analysis

Using preCICE
, ,
1

I’m attempting to couple OpenFOAM and Calculix to perform two-way FSI of flow through an artery. My coupling is extremely strong, so it was suggested (https://precice.discourse.group/t/openfoam-calculix-fsi-diverging-sim-never-ends/645/14) that I make sure I start with a fully converged fluid solution. Previously, I was only initializing my fluid solution with a potential flow solver (potentialFOAM), so I drummed up a simpleFOAM run in a different directory and then mapped the velocity and pressure solutions to the initial state of the FSI simulation. I then started up the sim. The flow solution converged fine, and so did the structural solver. Then, preCICE attempted to compute the convergence metrics to determine if another iteration of the solvers was necessary, and I was met with this:

Adapter writing coupling data...
(0) [cplscheme::BaseCouplingScheme]:352 in getThisTimeWindowRemainder:  return 0.001
Writing DISPLACEMENTS coupling data with ID '2'.
Adapter calling advance()...
(0) [utils::Events]:59 in stop:  Stopped event solver.advance
(0) [utils::Events]:40 in start:  Started event advance
(0) [impl::SolverInterfaceImpl]:399 in advance:  Synchronize timestep length
(0) [cplscheme::BaseCouplingScheme]:352 in getThisTimeWindowRemainder:  return 0
(0) [cplscheme::BaseCouplingScheme]:352 in getThisTimeWindowRemainder:  return 0
(0) [cplscheme::BaseCouplingScheme]:352 in getThisTimeWindowRemainder:  return 0
(0) [impl::SolverInterfaceImpl]:426 in advance:  Advance coupling scheme
(0) [cplscheme::BaseCouplingScheme]:352 in getThisTimeWindowRemainder:  return 0
(0) [cplschemes::SerialCouplingSchemes]:115 in exchangeDataAndAccelerate:  Test Convergence and accelerate...
(0) [cplscheme::BaseCouplingScheme]:657 in accelerate:  measure convergence of the coupling iteration
(0) [cplscheme::BaseCouplingScheme]:555 in measureConvergence:  relative convergence measure: relative two-norm diff = -nan, limit = 0.001, normalization = 0.0122898, conv = false
(0) [cplscheme::BaseCouplingScheme]:555 in measureConvergence:  relative convergence measure: relative two-norm diff = 0, limit = 0.001, normalization = 0.244577, conv = true
(0) [utils::Events]:40 in start:  Started event advance/cpl.computeQuasiNewtonUpdate
(0) [acceleration::BaseQNAcceleration]:208 in updateDifferenceMatrices:     Update Difference Matrices
(0) [acceleration::BaseQNAcceleration]:326 in performAcceleration:     Performing quasi-Newton Step
(0) [acceleration::ResidualSumPreconditioner]:72 in _update_:  preconditioner scaling factor[0] = -nan
(0) [acceleration::BaseQNAcceleration]:133 in computeQNUpdate:     Compute Newton factors
(0) [acceleration::BaseQNAcceleration]:192 in computeQNUpdate:     Apply Newton factors
(0) [acceleration::BaseQNAcceleration]:418 in performAcceleration: ERROR:  The quasi-Newton update contains NaN values. This means that the quasi-Newton acceleration failed to converge. When writing your own adapter this could indicate that you give wrong information to preCICE, such as identical data in succeeding iterations. Or you do not properly save and reload checkpoints. If you give the correct data this could also mean that the coupled problem is too hard to solve. Try to use a QR filter or increase its threshold (larger epsilon).

Certainly, this could just be an issue with my IQN-ILS acceleration settings, but the I tested it using Aitken under-relaxation and received a very similar error:

Adapter writing coupling data...
(0) [cplscheme::BaseCouplingScheme]:352 in getThisTimeWindowRemainder:  return 0.001
Writing DISPLACEMENTS coupling data with ID '2'.
Adapter calling advance()...
(0) [utils::Events]:59 in stop:  Stopped event solver.advance
(0) [utils::Events]:40 in start:  Started event advance
(0) [impl::SolverInterfaceImpl]:399 in advance:  Synchronize timestep length
(0) [cplscheme::BaseCouplingScheme]:352 in getThisTimeWindowRemainder:  return 0
(0) [cplscheme::BaseCouplingScheme]:352 in getThisTimeWindowRemainder:  return 0
(0) [cplscheme::BaseCouplingScheme]:352 in getThisTimeWindowRemainder:  return 0
(0) [impl::SolverInterfaceImpl]:426 in advance:  Advance coupling scheme
(0) [cplscheme::BaseCouplingScheme]:352 in getThisTimeWindowRemainder:  return 0
(0) [cplschemes::SerialCouplingSchemes]:115 in exchangeDataAndAccelerate:  Test Convergence and accelerate...
(0) [cplscheme::BaseCouplingScheme]:657 in accelerate:  measure convergence of the coupling iteration
(0) [cplscheme::BaseCouplingScheme]:555 in measureConvergence:  relative convergence measure: relative two-norm diff = -nan, limit = 0.001, normalization = 0.0122898, conv = false
(0) [cplscheme::BaseCouplingScheme]:555 in measureConvergence:  relative convergence measure: relative two-norm diff = 0, limit = 0.001, normalization = 0.244577, conv = true
(0) [acceleration::AitkenAcceleration]:91 in performAcceleration:  AitkenFactor: -nan
(0) [com::SocketCommunication]:528 in send: ERROR:  Send using sockets failed with system error: write: Broken pipe
(0) [utils::Events]:59 in stop:  Stopped event _GLOBAL

Why is the displacement convergence value -nan instead of 1? Why is the force convergence value 0 instead of 1? Whatever it is, it’s affecting the acceleration parameter, driving it to nan, and crashing the analysis.

I read somewhere on here that there may be residual information left over from previous runs in the precice-run directory, so I made sure to delete this directory before each test.

Any help is most appreciated.

Here are the relevant files:
precice-config.xml (3.3 KB)
zuncp_fsi.o46104.txt (812.3 KB)
zuncp_fsi.o461045.txt (814.0 KB)
precice-Solid-convergence.log (159 Bytes)
solid.log (34.6 KB)
fluid.log (753.3 KB)

2

What happens when you add an export vtk tag on the solid participant and check the data as well as the size of the data?

3

What do you mean by “check the data”?

image
image995×390 72.7 KB

The gray surface here is the fluid interface boundary at time = 0. The black dots are Solid-Mesh-Solid.init.vtk, which is the only .vtk file output when I apply the export vtk tag.

To me, it appears that the vtk data lines up well enough with the interface. The scale of the two data sets is the same. There is no solution from either solver, yet, so I don’t know of any other data to compare.

Here’s the updated precice-config file showing my vtk export tag:
precice-config.xml (3.2 KB)

4

Your fluid solver crashes in the second iteration. My best guess right now is that the forces in the first iterations are very high already → solid deforms too much → mesh mover in OpenFOAM cannot handle the situation.

Try using a parallel-implicit coupling scheme with both data field in the IQN-ILS acceleration:

<acceleration:IQN-ILS>
  <data name="Displacement" mesh="Solid-Mesh"/>
  <data name="Force" mesh="Solid-Mesh"/>
  <preconditioner type="residual-sum"/>
  <filter type="QR2" limit="1e-3"/>
  <max-used-iterations value="100"/>
  <initial-relaxation value="0.05"/>
  <time-windows-reused value="10"/>
</acceleration:IQN-ILS>

Then, both data fields are underrelaxed in the first iteration.

5

Thanks @uekerman! This helped a ton! I’m not out of the woods yet with this analysis, but this change at least got those first time steps out of the way so I can work out the next issues.

1 Like