Introduce a ramp similar to turek-hron-fsi3 in perpendicular-flap?

[BenjaminRodenberg]

I saw that the boundary condition in turek-hron-fsi3 is implemented as a cosine-shaped ramp. Why do we not use a similar kind of boundary condition for the perpendicular flap?

In precice/precice#2172 I studied the case perpendicular-flap and made the observation that not all data equals zero at the beginning with the current boundary and initial conditions.

I implemented precice/precice#2181 to plot the watchpoints at initial time. I get non-zero forces if I set <exchange data="Force" ... initialize="true" />:

  Time  Coordinate0  Coordinate1  Displacement0  Displacement1  Force0  Force1
 0.00000000e+00   0.00000000e+00   1.00000000e+00   0.00000000e+00   0.00000000e+00   2.29427968e+00  -3.02282515e-14

I assume that this is due to the initial condition (IC) where the fluid velocity in x direction is homogeneously set to 10 on the whole domain. However, the cross section of the channel is smaller at the x-coordinate of the flap. Here, one would expect a larger velocity due to mass conservation which makes the given IC unphysical. A ramp should lead to a more realistic scenario.

Additionally, I realized that using a ramp also leads to better results in a subcycling-based experiment I developed for my thesis. See here. I will probably also change this implementation to a cosine shaped ramp since this gives us C0 and C1 continuity in contrast to the piecewise linear ramp that is only C0.

Side note: Looking at the watchpoints I would claim that setting initialize="false" is actually wrong since it ignores the initial forces produced on the OpenFOAM side. Using a ramp "heals" this problem since here we really have zeros for all exchanged quantities. Related issues/PRs: precice/precice#2033, #540

[BenjaminRodenberg]

@MakisH @davidscn @uekerman this is related to #94 and maybe you have experienced similar problems while working on the FSI3 benchmark?

[uekerman]

Why do we not use a similar kind of boundary condition for the perpendicular flap?

Historic reason: Since it did not crash without one. Unphysical initial conditions are a common thing in CFD in my experience.

What makes things complicated: Do all solvers have functionality to describe such a cosine ramp? We would need to investigate for all. And adding further solvers gets more complicated in the future.

[BenjaminRodenberg]

From a practical perspective I totally understand both arguments but if we stick to this policy the problem will just get bigger over time. Using a wrong BC just because this often happens and implementing the correct one is complicated or even impossible for some solvers is ok for illustrative purposes but then we need to be more transparent with this. I was quite surprised to see such a big difference and this issue resulted in one week of work on my side.

We need a different policy for the tutorial cases. Otherwise we are stuck in a bad state where we cannot improve any of the configurations without touching everything at once (unrealistic for outside contributors and increasingly becoming a problem for developers as well). I also think it is hard to motivate outside contributors to contribute a case if they first have to change it to use wrong BCs in order to fit into our schema.

[MakisH]

In this tutorial, we already have two groups of fluid solvers (incompressible and compressible), leading to two groups of results. Making it more complicated, in case we cannot support time-dependent boundary conditions in all solvers, would be a bit ugly. In that case, we could start with commented-out configuration (or documentation) to configure a ramp.

In terms of solvers, we currently have:

• OpenFOAM: easy, either with the codedFixedValue that we use in the FSI3, or with a table.
• SU2: seems to be at least complicated, please correct me.
• Nutils: I could not find anything, please correct me.
• (fake): trivial

[uekerman]

I would not call the BC "wrong". Concerning transparency, the BCs are documented. We could indeed add the IC. But I would not be strict here, a fluid solver could in theory use a different IC.

IMO, simplistic scenarios such as the perpendicular flap are indeed for illustrative purposes mainly, showcasing the technical side of things.

What would you like to change?

[BenjaminRodenberg]

I would not call the BC "wrong".

The initial condition of the (incompressible) case is at the moment unphysical since the velocity field is not divergence free. If some solvers allow for better initial conditions and some don't I think we should not force the solvers to stick to the unphysical initial conditions because some other solvers cannot implement a physical initial condition.

If we implement a certain initial condition only in some solvers and not in others this can lead to inconsistencies in the case. I don't see this as a big problem (especially if the cases mainly serve illustratory purposes). As long as we know which solution is the one that is closest to the "true solution" of the case and, additionally, explain why certain solvers cannot reproduce this "true solution" everything is fine from my perspective.

What would you like to change?

I would propose to relax a bit on consistency across the tutorials in favor of tweaking the case to towards a physically correct solution.

For example, if CalculiX did not offer C3D8I elements the fix #250 would not have been available. Sticking to C3D8 elements is not optimal but it would be the best available compromise in this hypothetic situation. If we want to get consistent without C3D8I elements and #250 the only available option is to change FEniCS and deal.II to mimic the behavior of CalculiX' C3D8 elements leading to a consistent but incorrect solution.

Additionally, we already have inconsistencies in other tutorials. It just depends how close you look: If I compute the partitioned-heat-conduction scenario using dirichlet-fenics and neumann-nutils I do not get the same level of accuracy as for dirichlet-fenics and neumann-fenics. I think this is not really a big problem. Ideally, we would improve the nutils solver to reach the same level of accuracy as the FEniCS solver. But if we don't do it I think this is also ok.

[uekerman]

I would propose to relax a bit on consistency across the tutorials in favor of tweaking the case to towards a physically correct solution.

I think that this is what we are doing already. The "only" consistency we require is that cases use the same preCICE configuration. All other differences can be documented in theory.