Restructure flap_perp FSI case

[davidscn]

Closes #135
I have not yet adjusted the physical parameters and not yet tested any relevant cases. Here is an overview of what I expect to work and open TODOs:

The overall case has been taken from this paper, so that some physical parameter change in contrast to previous settings. Also, the whole simulation is performed in the xy-plane which lead to geometrical changes of some cases using the xz-plane before.

• fluid-nutils There are currently two different meshes in use for reading and writing. We can only use one mesh here (I would prefer this option at least). I suggest we leave out the cell centers and go with the Gauss-points. Also, the pythin binding path is somehow wrong @uekerman
• fluid-openfoam
• fluid-su2 Biggest TODOs left. We need to support absolute Displacement data and a more flexible configuration. Related to Extend adapter to read Displacements (and allow configuration) su2-adapter#17, WIP
• solid-calculix I copied the meshes from Reformat FSI/flap_perp/SU2-CalculiX tutorial to new 2D-3D coupling strategy #143 thanks to @IshaanDesai, still waiting for Add functionality to handle 2D interfaces calculix-adapter#49 to be merged
• solid-dealii we need to support force data reading, as described in Support Force data in addition to Stress data dealii-adapter#41, Open to discuss, do we also want to support DisplacementDeltas? The information is already there and it would ensure compatibility to other adapter linear case is ready, nonlinear is an open TODO. I think the more important part is the linear here.
• solid-fenics

Apart from that, what is our clean.shscript supposed to clean? I just want to mention that cleaning all cases might be undesired and deletes a lot. Maybe we should require some cleaning target specification.

[uekerman]

There are currently two different meshes in use for reading and writing. We can only use one mesh here (I would prefer this option at least). I suggest we leave out the cell centers and go with the Gauss-points.

Good point. Didn't have this on my radar. Yes, let's go with the GPs then.

Also, the pythin binding path is somehow wrong

See comments above

[uekerman]

solid-dealii: Do we also want to support DisplacementDeltas? The information is already there and it would ensure compatibility to other adapter

In my opinion this is not strictly necessary. We don't need it here. I would definitely keep it out for the moment. We could still do this later.

Apart from that, what is our clean.shscript supposed to clean? I just want to mention that cleaning all cases might be undesired and deletes a lot. Maybe we should require some cleaning target specification.

Let's clean everything for the moment. We anyway wanted to revisited the cleaning in #133. Let's discuss this then / there.

[davidscn]

Nutils output:

  File "nsale.py", line 8, in <module>
    @function.replace
AttributeError: module 'nutils.function' has no attribute 'replace'

I think I have an obvious issue I am not aware of?

[MakisH]

I like how this looks a lot red! 😄 A lot of hard work!

See a few comments below. I have not yet tried to run the cases. The target branch is correct.

[IshaanDesai]

I compared the results of SU2-FEniCS and SU2-CalculiX runs for the perpendicular flap and the comparison looks like:

The results are clearly different. The corresponding case setups can be found here: https://github.com/precice/tutorials/tree/formatSU2-CCX-tutorial/FSI/flap_perp_2D
I am purposely resolving this issue on the branch: https://github.com/precice/tutorials/tree/formatSU2-CCX-tutorial to avoid pushing an inconsistent scenario within the restructuring.

[BenjaminRodenberg]

I'm attaching a picture of current setup + physical parameters. I hope that this agrees with what you are doing here. If not: please shout out loud 🔈 🙉

I think the z = 1 is still an open topic (see #108). What "thickness" do you use here?

[BenjaminRodenberg]

Comments mostly related to #108

[IshaanDesai]

Some suggestions regarding physical parameters and changes to the FEniCS script to calculate Displacements instead of DisplacementDeltas

[davidscn]

I'm attaching a picture of current setup + physical parameters. I hope that this agrees with what you are doing here. If not: please shout out loud speaker hear_no_evil

I think the z = 1 is still an open topic (see #108). What "thickness" do you use here?

@BenjaminRodenberg I like the figure very much. The current README uses the preCICE wiki overview of this case, which is certainly less informative. Regarding the 'z' topic: for OpenFOAM, we must use z=1, otherwise you're doing things wrong (in conmbination with force data). IIRC, it doesn't really matter for CalculiX, but we still use z=1. Since this is a tutorial, we should definitely use z=1 in order to prevent errors (in case of a different setup) and to show some best practice.

[MakisH]

Just so that somebody asks this: shouldn't we wait for the paper to be published before using the new figures here?

[uekerman]

Just so that somebody asks this: shouldn't we wait for the paper to be published before using the new figures here?

Should not change the copyright. Once we publish we might need to transfer the copyright. Maybe then we need to delete them here, but normally nobody cares about that.

[davidscn]

Related to precice/su2-adapter#22

[uekerman]

Our best guess currently is that there is sth wrong in with the FEniCS solid solver. @BenjaminRodenberg wanted to have a look at that. I will merge this nevertheless already. We can also fix things on the restructure branch. Otherwise, changes drift too far apart. We will anyway test everything again before merging to develop.

The only thing I still want to invest is the strangely high number of coupling iterations needed for the Nutils case.

[uekerman]

Nutils-dealii converges very well for me. @davidscn Do you still get the bad convergence?

precice-Solid-iterations.log

And I get sufficiently good agreement between Nutils-dealii and OpenFOAM-dealii. My tip displacement does however not match the one from @IshaanDesai above. Some changes in between or still some inconsistency?

[davidscn]

And I get sufficiently good agreement between Nutils-dealii and OpenFOAM-dealii. My tip displacement does however not match the one from @IshaanDesai above. Some changes in between or still some inconsistency?

Your solution looks indeed wrong and @IshaanDesai results should be the reference here. Do you use the develop branch of deal.II and this PR branch for your test?

[davidscn]

The nutils case looks for me something like this in terms of iterations:
precice-Solid-iterations.log

[IshaanDesai]

My tip displacement does however not match the one from @IshaanDesai above. Some changes in between or still some inconsistency?

@uekerman the results you posted look suspiciously similar to the old results before the physical parameters were tuned as part of this restructuring. I am highly confident that several oscillations of the flap are seen as per the new tutorials.

[uekerman]

I used an old version of the OpenFOAM and deal.II adapters. I now get the same results. Trying to reproduce the Nutils problem now.

[uekerman]

Nutils-dealii is looking good now.

precice-Solid-iterations.log

I tweaked a few things to get better convergence. I guess in the end the difference between Nutils and OpenFOAM is the less robust trapezoidal rule that Nutils uses.

@davidscn merge now or do you still want to tweak the SU2 case here?

[davidscn]

Nutils-dealii is looking good now.

Awesome. Let's merge in case you approve this PR.

[alicezanella]

Hi,
I'm trying to run this tutorial, but It doesn't seem to work.
I have precice 2.2.0, SU2 6.0.0 (with adapter) and CalculiX 2.16 (with adapter).
I simply downloaded the test case, run ./Allrun and checked the logs. This is the error I get in Solid.log:

---[precice] �[31mERROR: �[0m The quasi-Newton update contains NaN values. This means that the quasi-Newton acceleration failed to converge. When writing your own adapter this could indicate that you give wrong information to preCICE, such as identical data in succeeding iterations. Or you do not properly save and reload checkpoints. If you give the correct data this could also mean that the coupled problem is too hard to solve. Try to use a QR filter or increase its threshold (larger epsilon).

While the Fluid.log shows SU2 has diverged.

Why do I get these results while you can run it perfectly?

[IshaanDesai]

Hi @alicezanella, can you please try to run the case with this branch: https://github.com/precice/calculix-adapter/tree/handle2DInterfaces of the CalculiX adapter? As this particular restructuring has not been merged into the develop or master branch of the tutorials, we have not synced the working with the respective adapter branches till now.

[alicezanella]

Hi @IshaanDesai ,

I successfully run the case. Thank you for your answer!

[vryy]

Hello, I tried to run this example recently, using OpenFoam v2012-Calculix 2.16, and encounters an error:

"The interpolation matrix of the RBF mapping from mesh Fluid-Mesh-Faces to mesh Solid is not invertable. This means that the mapping problem is not well-posed. Please check if your coupling meshes are correct. Maybe you need to fix axis-aligned mapping setups by marking perpendicular axes as dead?"

In fact, it run successfully one week ago, but after some system update I recompiled all the packages and see this error. I'm struggling of the reason.

[BenjaminRodenberg]

@vryy Please post this question on https://precice.discourse.group/. My first careful guess is that you are facing a problem similar to the one resolved in a166efa for a different case.

If you take a look at the commit message you will see exactly the same error you are facing.

[vryy]

@BenjaminRodenberg I reposted the question and follow-up on discourse

[precice-bot]

This pull request has been mentioned on preCICE Forum on Discourse. There might be relevant details there:

https://precice.discourse.group/t/fsi-scenario-with-updated-tutorials-and-openfoam-adapter/566/2