Assertion failed on ResidualSumPreconditioner

Using preCICE
1

Hi,
sometimes during coupling, at the beginning or after afew timesteps, I get this error:

ASSERTION FAILED
  Location:          virtual void precice::acceleration::impl::ResidualSumPreconditioner::_update_(bool, const VectorXd&, const VectorXd&)
  File:             .... /PreCICE/precice-2.0.1/src/acceleration/impl/ResidualSumPreconditioner.cpp:43
  Rank:              0
  Failed expression: sum > 0
 0# getStacktrace[abi:cxx11]() in /usr/local/lib/libprecice.so.2
 1# precice::acceleration::impl::ResidualSumPreconditioner::_update_(bool, Eigen::Matrix<double, -1, 1, 0, -1, 1> const&, Eigen::Matrix<double, -1, 1, 0, -1, 1> const&) in /usr/local/lib/libprecice.so.2
 2# precice::acceleration::impl::Preconditioner::update(bool, Eigen::Matrix<double, -1, 1, 0, -1, 1> const&, Eigen::Matrix<double, -1, 1, 0, -1, 1> const&) in /usr/local/lib/libprecice.so.2
 3# precice::acceleration::BaseQNAcceleration::performAcceleration(std::map<int, std::shared_ptr<precice::cplscheme::CouplingData>, std::less<int>, std::allocator<std::pair<int const, std::shared_ptr<precice::cplscheme::CouplingData> > > >&) in /usr/local/lib/libprecice.so.2

Generally I manage to avoid this by tweaking with the config file, i.e. by changing the order of participants and changing data on which I apply acceleration. Nevertheless I have no a clear understanding on what is really going on so that I can avoid some try and error, because sometimes the data on the interface meshes seem ok also during each iteration.
Thank you
Claudio

2

Hi @Claudio

This is kind of a known bug, but I just saw that we have no issue yet for this.
Could you please open a bug report ?
To better understand the problem please attach a config that gave this problem and one where your tweaks fixed the problem. That would be very helpful. Maybe also the complete log of the solver that runs into the problem.

As a workaround, I guess you could always just remove the

<preconditioner type="residual-sum"/>

Thanks already,
Benjamin

3

Hi @uekerman
sorry for the huge delay. I have seen that this happens to me both in parallel-implicit and serial implicit coupling schemes when I have displacements in the acceleration configuration with IQN-ILS.
So I just switch solvers in serial implicit coupling scheme or I use only Forces in parallel-implicit schemes.
I have also noticed that changing preconditioner type does not change the behavior.
If I just remove the preconditioner everything works fine. Does this (removing the preconditioner) affect performance or not?
Do you still want me to open a bug report?

Thnak you
Claudio

The following is an example of config file where the use of the preconditioner gives the error:

<coupling-scheme:parallel-implicit>
        <time-window-size value="1.e-2" />
        <max-time value="10."/>
        <participants first="Fluid" second="Solid"/>
        <exchange data="Forces0" mesh="Solid-Mesh" from="Fluid" to="Solid" initialize="0"/>
        <exchange data="Displacements0" mesh="Solid-Mesh" from="Solid" to="Fluid" initialize="0"/>

        <max-iterations value="50"/>
        <relative-convergence-measure limit="1e-3" data="Displacements0" mesh="Solid-Mesh"/>
        <relative-convergence-measure limit="1e-3" data="Forces0" mesh="Solid-Mesh"/>
        <extrapolation-order value="2"/>
   
         <acceleration:IQN-ILS>
            <data name="Forces0" mesh="Solid-Mesh"/>
            <data name="Displacements0" mesh="Solid-Mesh"/>
            <!--<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>

</coupling-scheme:parallel-implicit>
4

I opened an issue and will “close” this post here. It is a bug. I am just not sure yet whether it is a wrong user input or a wrong assumption in our implementation.

Yes, it does if your variables (forces and displacements) live on very different scales. For an example, see my thesis, section 3.6.3 .

5

Hi @Claudio

After I had a deeper look into this and safeguarded the assertion by understandable error messages I suspect that it actually also points to a potential problem in your adapter. Probably you write the same values twice to preCICE in MBDyn. Maybe because you miss a read_(block)_scalar/vector_data?
A common mistake is to forget that new data can already be available after initialize, not only after advance, compare the adapter example.