Update dealii tutorials for new solver

[davidscn]

Updates the tutorials according to precice/dealii-adapter#26.

The solver apply now stress data instead of force as provided in precice/openfoam-adapter#125.

#77 Becomes a separate PR, since it might take some time to investigate the appropriate parameters.

[davidscn]

@uekerman @MakisH I think we should remove the 3D (quasi 2D) examples here. They are a great example of how it shouldn't be done, since the amount of work in the solid solver is much larger. Example: For a simple mesh with 150 cells and a polynomial degree of 4 I obtain 5 082 unknowns. The same mesh has in 3D 38 115 unknowns.

Also, the cases are a duplication. Opinions?

[MakisH]

These are the only 2D cases we have and with these tutorials we mainly want to teach users how to configure preCICE for 2D (and showcase that the OpenFOAM adapter can also work in quasi-2D).

You write

They are a great example of how it shouldn't be done, since the amount of work in the solid solver is much larger.
I would not worry about this, as it is clear that our tutorials are mostly toy/skeleton problems.

Do you have any alternative solution in mind so that we can still offer a (better, if possible) 2D-2D tutorial case?

[davidscn]

Sorry, I was a bit unclear.
I propose to remove the (in FE space 3d) OpenFoam-deal.II tutorials located in flap_perp and cylinderFlap and keep only the flap_per_2D and cylinderFlap_2D cases.

[MakisH]

A few questions that I got looking at the changes, maybe not all of them are action items.

[MakisH]

Sorry, I was a bit unclear.
I propose to remove the (in FE space 3d) OpenFoam-deal.II tutorials located in flap_perp and cylinderFlap and keep only the flap_per_2D and cylinderFlap_2D cases.

Oh, I see, I misunderstood it as "remove the 2D". I don't see any strong reason not to remove the 3D deal.ii cases, but also not a strong reason to remove them. I guess that the 2D is the case adding value for our tutorials, and the 3D is maybe indeed duplicate from the deal.ii side. We should just make sure to document that 3D is also possible and how.

[davidscn]

This is now ready to run with the current deal adapter. I also added a runSolid script, which can be executed with -linear or -nonlinear.
Waiting now for precice/systemtests#228 to be merged.

[uekerman]

I also don't see any strong reason why to remove the 3D case. I would see it as an example how to best approach these cases, but how to work with the dealii solver in 3D. And we have it tested then.

Eventually, we will need to reorganize our tutorials anyway, but that's the story for another day :)

[davidscn]

Ok, then I need to update the nonlinear solver to cope with 3d and update the 3d tutorial cases here as well!

[uekerman]

I just ran the 2D tutorials. A few small things:

• dealii adapter does not build with dealii v9.1.1 (I already talked with @davidscn about this, just for completeness)
• flap_perp_2D/OpenFOAM-deal.II/Fluid/system/preciceDict still uses Force instead of Stress
• cylinderFlap_2D is missing the runSolid script
• ./runFluid -parallel does not work due to the write-consistent mapping. We need to move the mapping to the other participant if we use stresses.

The non-linear solver already for the flap is extremely slow. Any simple ideas how to speed this up? Maybe a coarser mesh?

[uekerman]

Ok, then I need to update the nonlinear solver to cope with 3d and update the 3d tutorial cases here as well!

So, currently only the linear solver supports 3D, not the nonlinear solver, correct?

[uekerman]

One more thing: if we use stresses we currently need the develop version of the OpenFOAM adapter, but this PR goes to the master branch.
@MakisH Can we merge that feature in the OpenFOAM adapter to the master? Or should this PR better target develop?

[MakisH]

@MakisH Can we merge that feature in the OpenFOAM adapter to the master? Or should this PR better target develop?

I just now merged it.

[davidscn]

The non-linear solver already for the flap is extremely slow. Any simple ideas how to speed this up? Maybe a coarser mesh?

Do you run the 2D case? Running it in release is considerably faster. I should set it as the default build option.

So, currently only the linear solver supports 3D, not the nonlinear solver, correct?

That's more a matter of the setup. I have already tested it once for three 3D, but discarded it.

Can we merge that feature in the OpenFOAM adapter to the master? Or should this PR better target develop?

Please merge the OpenFOAM version to master, there is also an open PR for a systemtest dev->master update and the deal.II adapter needs it in master as well (which is also the target).

[MakisH]

Please merge the OpenFOAM version to master, there is also an open PR for a systemtest dev->master update and the deal.II adapter needs it in master as well (which is also the target).

For the system tests, I would prefer to leave the decision to @Eder-K

[davidscn]

Please merge the OpenFOAM version to master, there is also an open PR for a systemtest dev->master update and the deal.II adapter needs it in master as well (which is also the target).

For the system tests, I would prefer to leave the decision to @Eder-K

That's the case, see precice/systemtests#230

I just now merged it.

Perfect, this will probably fix the failing build there as well.

[davidscn]

There were some unstaged changes. I added now a .gitignore in these cases in order to avoid it.
We should maybe add a gitignore for the whole repo.

[uekerman]

The non-linear solver already for the flap is extremely slow. Any simple ideas how to speed this up? Maybe a coarser mesh?

Do you run the 2D case? Running it in release is considerably faster. I should set it as the default build option.

If you mean for dealii then yes 👍

[davidscn]

You run it in CMAKE_BUILD_TYPE release and it is slowly? This should not be the case.

./runFluid -parallel does not work due to the write-consistent mapping. We need to move the mapping to the other participant if we use stresses.

I updated now everything. Only the config is erroneous (flap_perp case) and leads to a failure after switching the consistent mapping. I get a segfault and I can't figure out the reason right now.

[uekerman]

You run it in CMAKE_BUILD_TYPE release and it is slowly? This should not be the case.

Just talked with @davidscn
dealii is by default built in debug and release. If the adapter is built in release it also links against the dealii release version. Then, it's indeed much faster and fast enough for the perpendicular flap. Let's make this the default for the adapter documentation.

[davidscn]

@uekerman I forgot one thing: Are you able to open up the generated vtk files with your paraView version?

[uekerman]

@uekerman I forgot one thing: Are you able to open up the generated vtk files with your paraView version?

I can open them, but I only get point data (which I can visualize with the glyph filter), but no cell data.
paraview version 5.4.1

Btw, Allclean does not yet remove those files.

[davidscn]

Ok, no need to hurry, let's discuss it during the next meeting. Your version would be too old.
ParaView/ vtk has a new feature for higher order methods, which is use in deal.II.