FSI of a deformable pitching foil with OpenFOAM and Calculix

[Andres]

@KyleDavisSA

So at the moment, you are using RBF CP C0 with 3 seperate meshes, correct?

Correct, in part. For the top and bottom meshes, I’m using RBF CP C0, while for the side (flap’s tip) I’m using NN mappings as per Benjamin’s recommendation. It also “works” with RBF CTPS C2, though fails at a later time. I say “works” because I suspect I have been doing something wrong; I’ll elaborate on this at the end of this post.

@KyleDavisSA

In your message on 31 December, you switch from 1 surface to 3 surfaces due to an error, but this error was related to the quasi-Newton coupling. This might be too much work, but does going back to a single surface help? You mentioned that something else was the cause of the QN crashing.

At first I had only one surface making up the interface, yes. If I used an RBF mapping, I received an FPE during the mapping. If I used an NN mapping, I had problems with the QN coupling.

I could go back to a single surface for the fluid/solid interface, though I suspect that might make RBF unsuitable. The flap is very, very thin. Unless I used an absurdly fine solid mesh, it would lead to the issue you brought up here: if a gaussian RBF is used as an example, it selects all points within a specified radius around each point. This could then select points on an opposing surface which is not physically correct.

@KyleDavisSA

Another test would be to use the direct solver for the RBF, depending on the problem size. You can try the setting use-qr-decomposition="1" . This will avoid the FPE error as PETSc will not be run, but if there is a problem we should see an error in Eigen. As always, now that the simulation seems to be running, does it eventually fail with nearest-neighbor mapping?

I could try with that setting and see what happens. The simulation seems to be running and even though the results so far seem reasonable (i.e. are not unphysical), I have a suspicion that I have done something wrong. Specifically, I mentioned before that I had to downgrade the CalculiX adapter (2.16 to 2.15) because of the “stagnant node 1 problem” (seen here, here, and here for example). However, looking at dates I think this is not implemented in the adapter for 2.15 (right?). I have been running the case with <solver-interface dimensions="2">, but if the CCX-2.15 adapter can’t handle that then my set up is definitely wrong (strangely, no error messages).

I have built the 2.16 calculix adapter, and while I have an idea to get around the node-1-is-fixed problem, I can’t get it to work in Quasi 2D-3D mode with my interface-split-into-3 set up. I receive:

---[precice]  I am participant "Solid"  
Using quasi 2D-3D coupling  
Set ID Found  
ccx_preCICE: adapter/PreciceInterface.c:559: PreciceInterface_ConfigureNodesMesh: Assertion `count == interface->num2DNodes && "Filtering of 2D nodes not done properly. Please make sure the out-of-plane axis is Z-axis"' failed.

The mesh is correct for a quasi 2D-3D case, however, since if I create only one interface with the same nodes that doesn’t pop up. I mentioned this in a related GitHub issue. I think it would be best to wait for that to be looked into and then migrate to the newer adapter before continuing with this case.

Of course, thanks for taking the time to look into this.

Andrés