Partitioned heat conduction: Crash, if max-time >= 2.0. Why? about tutorials

[uekerman]

The failing case is a steady-state solution, right?
Then,

This means that the residuals in two consecutive iterations are identical.

can very well happen once you are converging.

Of course, usability could be better.

[BenjaminRodenberg]

@uekerman it's a time-dependent case: $u = 1 + x^2 + \alpha y^2 + \beta t$ (even without modifications as suggested further down in the issue)

[uekerman]

Could you attach the iterations and convergence file of the failing case?

[BenjaminRodenberg]

Here you are.
precice-Neumann-iterations.log
precice-Neumann-convergence.log
precice-Dirichlet-iterations.log
precice-Dirichlet-convergence.log

Case is identical to 3ad4542 except the time step size:

diff --git a/partitioned-heat-conduction/precice-config.xml b/partitioned-heat-conduction/precice-config.xml
index 3b20fad..2027e19 100644
--- a/partitioned-heat-conduction/precice-config.xml
+++ b/partitioned-heat-conduction/precice-config.xml
@@ -41,7 +41,7 @@
   <coupling-scheme:serial-implicit>
     <participants first="Dirichlet" second="Neumann" />
     <max-time value="1.0" />
-    <time-window-size value="0.1" />
+    <time-window-size value="0.05" />
     <max-iterations value="100" />
     <exchange data="Heat-Flux" mesh="Dirichlet-Mesh" from="Dirichlet" to="Neumann" />
     <exchange

[BenjaminRodenberg]

Update: I decided to comment out the PRECICE_CHECK that causes the crash. I do not observe clear problems w.r.t iteration count of the quasi-Newton acceleration or overall numerical error of the solution. For context: I'm currently performing convergence studies with this case.

Might be good to open a corresponding issue in precice/precice, since this looks to me like a problem with the quasi-Newton scheme that we should understand better.

[uekerman]

Without doing a close look, my best guess would be that the CHECK should be replaced by a "do not add the column and move on", maybe documented by a warning or info output.
I guess that this is anyway what happens in @BenjaminRodenberg commented-out version as then the filter removes the column again.

There are many connected issues in preCICE already:

• precice/precice#1496
• precice/precice#1107
• ...

[BenjaminRodenberg]

Without doing a close look, my best guess would be that the CHECK should be replaced by a "do not add the column and move on", maybe documented by a warning or info output.
I guess that this is anyway what happens in @BenjaminRodenberg commented-out version as then the filter removes the column again.

If the solution is that simple: Could we do this and even backport it to 2.5.1 for a bugfix release? Currently I have to patch 2.5.0 to perform some experiments and having a 2.5.1 release would simplify things.