Use waveform iteration with partitioned-heat-conduction/fenics/heat.py

[BenjaminRodenberg]

This PR introduces waveform iteration for the partitioned-heat-conduction case. Currently only the fenics-adapter supports this feature via precice/fenics-adapter#153 + precice/python-bindings#147. This also means that the tutorials for other adapters/solvers will break.

I think that the partitioned-heat-conduction case + subcycling is a nice test case for waveform iteration + subcycling. However, we might want to shift this specialized configuration of the case into an independent folder (as long as not all adapters support waveform iteration).

This is a breaking change, because some required features will only be introduced with preCICE v3.0.0.

[BenjaminRodenberg]

Basically this tutorial is ready to merge now that precice/develop is broken. Since it shifts the focus a bit (not simple tutorial, but a bit more advanced with subcycling), we should first agree here whether we actually want this change.

On the other hand: We sooner or later will need tutorials that illustrate how to use subcycling and this one along with https://github.com/precice/tutorials/tree/master/oscillator are good candidates. Any opinion @uekerman ?

[uekerman]

Yes, let's use new features (here waveform relaxation) whereever reasonable. I don't see any reason against this.
This will now also require the develop version of the FEniCS adapter, right? I think we should document such knowledge somewhere while updating everything.
@MakisH Where would be a good place?

[MakisH]

Having tutorials for such new features is indeed quite important for communicating and teaching the new features. Since the partitioned-heat-conduction was already designed to be a tutorial for studying the methods themselves, it makes a lot of sense to use it here.

The first place to document this change would be in the changelog (missing here). We should then mention it in the release notes / blog post.

Regarding the changes required in adapters, they need to go to the v3 porting guide. I think it would be great to document the necessary changes there, and/or link to the waveform feature page from there.

This tutorial also has OpenFOAM and Nutils participants.

For the OpenFOAM adapter, we have an umbrella issue to migrate to v3, where waveform is already on the list: precice/openfoam-adapter#235

For Nutils, we need an issue here - opened: #312

[MakisH]

@BenjaminRodenberg the only feature required is to read data at specific times, right? This is already implemented in the OpenFOAM adapter and in the Nutils examples here (in develop at least).

I cannot test the OpenFOAM at the moment, as I don't have funkySetFields in this system. Nutils seems to at least run. What should I check?

[BenjaminRodenberg]

I cannot test the OpenFOAM at the moment, as I don't have funkySetFields in this system. Nutils seems to at least run. What should I check?

If you can port the OpenFOAM version of the tutorial to a waveform iteration version following this PR, this might help you debugging precice/openfoam-adapter#305. The only thing you have to keep in mind is that quasi Newton is not supported. But you should be able to get the analytical solution -- even with subcycling.

[MakisH]

I cannot test the OpenFOAM at the moment, as I don't have funkySetFields in this system. Nutils seems to at least run. What should I check?

If you can port the OpenFOAM version of the tutorial to a waveform iteration version following this PR, this might help you debugging precice/openfoam-adapter#305. The only thing you have to keep in mind is that quasi Newton is not supported. But you should be able to get the analytical solution -- even with subcycling.

This PR just works with the OpenFOAM case and the results look fine.

In the OpenFOAM adapter develop, we are already reading at the relative time:

https://github.com/precice/openfoam-adapter/blob/c3968687a9cbaeacc599730681cb266108dd3a71/Interface.C#L552-L557

[MakisH]

Reducing the dt (similarly to FEniCS), I get a non-smooth interface in the intermediate times, with a gap that increases as the relative read time increases. Is this expected with a waveform-order=1?