You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current method of handling compositional coupling schemes with implicit coupling schemes is the following:
run all explicit schemes
run the implicit scheme
Then rerun the implicit schemes until it achieves convergence and move to the next time-window.
The implicit scheme defines a fixed-point problem on the interface, which is accelerated using the configured acceleration schemes.
This problem changes every time window, until the implicit scheme reaches convergence.
As explicit schemes run during the first iteration along the implicit scheme, they also exchange data.
Even if the exchanged data via the explicit scheme is not used in the implicit scheme, it may change available readData of the solver and thus changes the fixed-point problem.
Hence, the fixed-point problem of the first iteration is different than following iterations.
This numerically doesn't make sense.
Furthermore, a serial explicit scheme where the participant with the implicit scheme runs first sends the data of the first iteration to the coupling partner. This data should really be the data of the converged iteration.
Expected behaviour
The implicit coupling scheme should run until convergence is achieved without any interference from explicit schemes. Only when the implicit scheme converges, should the explicit schemes run.
For serial schemes, where the participant with the implicit scheme
comes first: the data of the converged iteration should be sent to the coupling partner.
comes second: the data of the coupling partner should be received before the implicit scheme starts iterating.
Example
A-B parallel-implicit; A-C serial-explicit
Top is our currently incorrect method. Bottom is the expected way of handling this.
Additional context
This means that splitting the former CouplingScheme::advance() into substeps is more complex as assumed.
This makes remeshing for serial coupling significantly more difficult to implement, while remeshing for parallel participants should be largely unaffected.
The text was updated successfully, but these errors were encountered:
fsimonis
added
bug
preCICE does not behave the way we want and we should look into it (and fix it if possible)
hotfix
requires hotfix
labels
May 14, 2024
Describe your setup
preCICE Version: 3.0.0 (since #1453)
Describe the problem
The current method of handling compositional coupling schemes with implicit coupling schemes is the following:
Then rerun the implicit schemes until it achieves convergence and move to the next time-window.
The implicit scheme defines a fixed-point problem on the interface, which is accelerated using the configured acceleration schemes.
This problem changes every time window, until the implicit scheme reaches convergence.
As explicit schemes run during the first iteration along the implicit scheme, they also exchange data.
Even if the exchanged data via the explicit scheme is not used in the implicit scheme, it may change available
readData
of the solver and thus changes the fixed-point problem.Hence, the fixed-point problem of the first iteration is different than following iterations.
This numerically doesn't make sense.
Furthermore, a serial explicit scheme where the participant with the implicit scheme runs
first
sends the data of the first iteration to the coupling partner. This data should really be the data of the converged iteration.Expected behaviour
The implicit coupling scheme should run until convergence is achieved without any interference from explicit schemes. Only when the implicit scheme converges, should the explicit schemes run.
For serial schemes, where the participant with the implicit scheme
Example
A-B parallel-implicit; A-C serial-explicit
Top is our currently incorrect method. Bottom is the expected way of handling this.
Additional context
This means that splitting the former
CouplingScheme::advance()
into substeps is more complex as assumed.This makes remeshing for serial coupling significantly more difficult to implement, while remeshing for parallel participants should be largely unaffected.
The text was updated successfully, but these errors were encountered: