Describe Navier-Stokes Diffeq example mesh by gmsh api usage and translate via FerriteGmsh

[koehlerson]

Need to include an optional finer discretization with vortex street. Currently only coarse discretization for CI is in the literate file. Will test around when I'm back at my workstation

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.75%. Comparing base (a10097a) to head (c7bd22e).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #498   +/-   ##
=======================================
  Coverage   93.75%   93.75%           
=======================================
  Files          36       36           
  Lines        5441     5441           
=======================================
  Hits         5101     5101           
  Misses        340      340           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[termi-official]

This might work.

[koehlerson]

@fredrikekre mesh from stokes example chokes 🤔

[koehlerson]

I could not reproduce the vortex street with the updated mesh, but it's very likely not a problem with the mesh itself

[termi-official]

To elaborate on the likely issue: The solution for the formulation is not unique up to a constant value in the pressure. For the currently used mesh with equisized elements the linear solvers seems to not have trouble finding a close sequence of constants. We should fix this with the trick from the stokes example, where we force the constant to a proper value by setting the boundary integral of the pressure to zero. Does not seem to be super straight forward in this example.

[termi-official]

Can we make the grid generation deterministic?

[termi-official]

I could find several open issues.

1. the pressure ramp protocol causes discontinuities in the second derivative. The chosen solver uses a second derivative approximation to control the time step. This causes the failure at the end of the ramp.
2. Solver tolerances were too high for the unstructured grid to resolve the oscillations sufficiently.
3. Since we cannot enforce the time-dependent constraints consistently everywhere in OrdinaryDiffEq (interface does not allow this yet) the time step length degrades severly for the adaptive implicit Euler. Higher order methods just fail.
4. The evaluation of the right hand side is dead slow. After merging this we might want to open 2 issues here: One about speeding up the solver via custom solver and one about parallelizing the rhs evaluation (+user-defined, parallel Jacobian). The former should also be a first good step towards enforcing time-dependent constraints.
5. Internal norms were erroneous as they included the constraints.

I will push the fixes for 1,2,5 later today, after commenting everything. This should then make the PR ready to merge.

[termi-official]

Also as a future project idea: 3D Navier Stokes with MPI parallelization in tandem with OrdinaryDiffEq.

[termi-official]

Some final changes and this should be good to go.

[termi-official]

Should be ready transiently through #917 .

[termi-official]

xref SciML/OrdinaryDiffEq.jl#2238 the information needs to be added

[termi-official]

Thanks Maxi! I will update the example to use the TimeChoiceIterator in a separate PR later after the interpolation issue in DifferentialEquations.jl is resolved.

[termi-official]

Last commit broke the gif :D

[termi-official]

LGTM otherwise.