Restart flow-over-heated-plate/fluid-su2 using initial condition

[j-signorelli]

This PR is a follow-up to fixes in the SU2 adapter outlined at precice/su2-adapter#47, where time iteration and time increment is made consistent with the SU2 source code, along with using the preferred/better approach of using a restart file for the initial condition.

An initial condition is added and the config file is updated accordingly.

Checklist:

• I added a summary of any user-facing changes (compared to the last release) in the changelog-entries/<PRnumber>.md.
• I will remember to squash-and-merge, providing a useful summary of the changes of this PR.

[MakisH]

@j-signorelli thanks for the PR! Could you please write a sentence here (or directly in the README.md of the tutorial) on how the initial flow file has been created?

Note to self: even though the system tests pass, they actually don't yet cover this case (flow-over-heated-plate with SU2).

[j-signorelli]

Had to do some digging... The initial flow file was generated using the attached config file, solving for the adiabatic steady-state flow:

laminar_config_steady.cfg.txt

Unfortunately I have no recollection why I did this... Maybe it was to have a flowfield that satisfies the BCs as the IC?

It looks like to me that the OpenFOAM IC uses just a uniform flow as the IC (is this correct?) so at first glance it makes more sense to use this instead. I will look into this.

[MakisH]

Thanks for the update! Clearly, starting from a better initial state is better.

With the risk of contradicting myself (we already had a similar discussion for the perpendicular-flap in #612), I would say let's go for the initialized flow, provided that we document how we got it and how to start from an uninitialized flow, if needed. In this tutorial, we only have SU2 and OpenFOAM as flow solvers, and doing the same in OpenFOAM is very easy, e.g., with potentialFoam (I can do it).

I did some comparisons:

We could also link to this page: https://su2code.github.io/docs_v7/Restart-File/

[j-signorelli]

Finally had some time to dig more into this!

So just to re-clarify, as discussed in precice/su2-adapter#47:

• Restarted simulations with a flow_00000.dat provided correctly enforces time-varying BCs and motion at the next timestep in the source code and Python scripts as is needed for implicit time schemes, and file suffixes flow_i.vtu represent solution at time dt*i. So a flow_00000.vtu represents solution at time=0, flow_00005.vtu represents solution at time dt*5.
• Non-restarted simulations do not enforce time-varying BCs and motion at the next time step as should be for implicit time schemes, and file suffixes output_i.vtu represent solution at time dt*(i+1). So a flow_00000.vtu represents solution at time=dt, flow_00005.vtu represents solution at time dt*(5+1).

Because of this, and the update/fix in precice/su2-adapter#47, technically there is an additional timestep included in the current configuration without an IC. It appears that this impact is quite subtle as you showed. I just pushed a corrected IC that is actually just a quiescent flow, as is in the OpenFOAM example, and here is the comparison (Note that Fluid-Nutils is SU2-Nutils -- the other Fluid participants are OpenFOAM from the reference-results/.

The effect however becomes more apparent when we directly compare flow_00005.vtu with a Solid_5.vtk. The current develop branch yields the following -- note that the temperature is discontinuous at the interface.

This is due to the inconsistency in the output file's suffix for non-restart simulations. We are not comparing data at the same timesteps.

Instead when a quiescent IC is used as now in this PR, the temperature distribution across the interface is continuous:

I generated this correct quiescent IC with the attached config file: laminar_config_steady.cfg.txt

Please let me know your thoughts. If this all sounds good, where would be an appropriate spot to add documentation explaining how this IC was created?

[MakisH]

Thanks for updating! So, the results now look even closer, correct?

If this all sounds good, where would be an appropriate spot to add documentation explaining how this IC was created?

If this is a one-liner, I would add it as a comment next to the SU2 option description in the tutorial README: https://github.com/j-signorelli/tutorials/blob/add_su2_ic_fohp/flow-over-heated-plate/README.md (e.g., Restarts from an initial condition using [option](link to the documentation).)

If this is longer, maybe it makes sense to start a section "Initial condition" in the same README. There, we could collect similar comments from the rest of the solvers.

[j-signorelli]

Actually I was mistaken -- for the preCICE outputs used in generating the plots, the results with a restart versus not are identical, as preCICE's timestep is independent of SU2's. The only difference here for this example case is that the output files are synced up (flow_00005.vtu == flow at same time as Solid_5.vtk). If one wanted to make a video of this example, it is do-able then with this PR. Otherwise, some gymnastics have to be done to output SU2 at 4,9,14,... instead of every 5,10,15,...

In general, this PR follows the guidance we provided in the adapter for using an initial condition restart file -- which is more compatible with SU2's implicit time scheme (and makes post-processing, as above, way easier!).

Either way, the plot output with and without this PR is the same. Would a comment in the config file near the restart settings make the most sense? Note that this IC is the same as the OpenFOAM participant and if we just did not use a restart file