Perpendicular flap (IGA solid participant G+Smo)

[Crazy-Rich-Meghan]

Perpendicular Flap with G+Smo (IsoGeometric Analysis) and OpenFOAM

NOTE: Stress instead of Force.

This PR is still a draft, because the G+Smo adapter's documentation is still ongoing.

I have added a README.md file to guide users on running the tutorial with G+Smo. It includes detailed instructions for setup and execution.

[uekerman]

Thanks for these great contributions!
I did not yet try it out, but wanted to give some initial tips already.

Guidelines worth checking out:

• tutorials contribution guidelines
• style guide of the preCICE docs.

[uekerman]

I am trying to install and run the case.

I am doing:

git clone gismo ... & cd gismo
mkdir build & cd build
cmake .. -DGISMO_OPTIONAL="gsKLShell;gsPreCICE;gsElasticity;gsStructuralAnalysis"
make solid-gismo-elasticity

and get

make: *** No rule to make target 'solid-gismo-elasticity'.  Stop.

And normal make works and gives me libgismo.so as expected.

I am a bit puzzled. How do I build the solid-gismo.cpp here? How does the adapter know about the available tutorials? Do I need to clone gismo into the tutorial case?

I guess what we need to do is to install the lib / make is discoverable and then add a CMakeLists.txt to the tutorial, which builds the actual solver?

[Crazy-Rich-Meghan]

I am trying to install and run the case.

I am doing:

git clone gismo ... & cd gismo
mkdir build & cd build
cmake .. -DGISMO_OPTIONAL="gsKLShell;gsPreCICE;gsElasticity;gsStructuralAnalysis"
make solid-gismo-elasticity

and get

make: *** No rule to make target 'solid-gismo-elasticity'.  Stop.

And normal make works and gives me libgismo.so as expected.

I am a bit puzzled. How do I build the solid-gismo.cpp here? How does the adapter know about the available tutorials? Do I need to clone gismo into the tutorial case?

I guess what we need to do is to install the lib / make is discoverable and then add a CMakeLists.txt to the tutorial, which builds the actual solver?

Hi Benjamin,

Thanks for testing this! The thing is, if you try to compile the file from the G+Smo side, we are using a different name for the filename since G+Smo and preCICE have different naming rules. On the G+Smo side, the solid participant filename is perpendicular-flap-vertex-gismo.cpp I have also changed the filename to perpendicular-flap-vertex-gismo under this PR.

Since we have multiple CPP files on our side, we cannot use a simple name like solid-gismo-elasticity.cpp. We have discussed this internally and decided that in the next version, we will consolidate everything into a single CPP file. Additionally, we will specify the meshes, boundary conditions, participant names, and other configurations using an XML file.

[uekerman]

With a few minor changes, I was able to run the case. Most importantly, I changed the data mapping constraint for the stresses to "consistent".

I now get:

The missing difference is probably due to the elements or refinement?

Thanks for testing this! The thing is, if you try to compile the file from the G+Smo side, we are using a different name for the filename since G+Smo and preCICE have different naming rules. On the G+Smo side, the solid participant filename is perpendicular-flap-vertex-gismo.cpp I have also changed the filename to perpendicular-flap-vertex-gismo under this PR.

The file perpendicular-flap-vertex-gismo.cpp here is not really needed, right? I now simply copied the executable over. And the name is fine. There is no standard for names of executables. The run.sh only needs to know the name.

I will continue cleaning up the case the next days. Please don't force push.

[uekerman]

I think, we don't need to show all other variants here. One non-linear one (e.g. deal.II) could be enough.
And we need a brief sentence that we have not yet found the reason for the difference.

[uekerman]

@Crazy-Rich-Meghan The results look good now 👍 What did you change?
It seems that the linear and the non-linear version of the code give (nearly?) the same results. Is this correct or a copy-paste issue?

[Crazy-Rich-Meghan]

@Crazy-Rich-Meghan The results look good now 👍 What did you change? It seems that the linear and the non-linear version of the code give (nearly?) the same results. Is this correct or a copy-paste issue?

Hi @uekerman , for the nonlinear version we iterate with Jacobian matrix, and the linear version with stiffness matrix. In principle, if the problem we are solving is a linear problem, the nonlinear time integrator should converge within the first timestep and result should be the same as time-integrator with stiffness matrix, that's why you see they are overlapping.

And we checked the source code from dealii, in linear_elasticity there is no geometric nonlinearlity so we changed a bit from our side.

[MakisH]

Thanks a lot for the contribution! Looks already very neat! I also compared the differences to the perpendicular-flap and it looks very clean. I also think that it is fine having this as a separate subcase, and I expect we will have more solvers opting for stresses instead of forces.

I could not run the case, but maybe I am doing something wrong, or something still needs to be documented. Other than that, this is in good shape already.

[MakisH]

Trying to run this, I get, in the beginning, on the Fluid:

---[precice]  Automatic RBF mapping alias from mesh "Solid-Mesh" to mesh "Fluid-Mesh" in "read" direction resolves to "partition-of-unity RBF" .
---[precice]  Computing "partition-of-unity RBF" mapping from mesh "Solid-Mesh" to mesh "Fluid-Mesh" in "read" direction.
---[precice] ERROR:  The interpolation matrix of the RBF mapping from mesh "Solid-Mesh" to mesh "Fluid-Mesh" is not invertable. This means that the mapping problem is not well-posed. Please check if your coupling meshes are correct (e.g. no vertices are duplicated) or reconfigure your basis-function (e.g. reduce the support-radius).

and the Solid waits with:

Solving timestep 0...
	It. |R|/|R0|         |dU|/|U0|        
	0   0                0                
Finished
---[precice]  relative convergence measure: relative two-norm diff of data "Displacement" = inf, limit = 5.00e-03, normalization = 0.00e+00, conv = true
---[precice]  relative convergence measure: relative two-norm diff of data "Stress" = inf, limit = 5.00e-03, normalization = 0.00e+00, conv = true
---[precice]  All converged
---[precice] WARNING:  The coupling residual equals almost zero. There is maybe something wrong in your adapter. Maybe you always write the same data or you call advance without providing new data first or you do not use available read data. Or you just converge much further than actually necessary.
---[precice] WARNING:  The IQN matrix has no columns.
---[precice]  Time window completed
---[precice]  Mapping "Stress" for t=0.01 from "Fluid-Mesh" to "Solid-Mesh"
---[precice]  iteration: 1 of 50 (min 1), time-window: 2, time: 0.01 of 5, time-window-size: 0.01, max-time-step-size: 0.01, ongoing: yes, time-window-complete: yes, write-iteration-checkpoint 

Am I missing something?

[Crazy-Rich-Meghan]

Hi Makis,
Thanks for testing! I tested this PR with a clean clone. I did not run into this problem.

My procedure is:

• cloned this pr
• cloned a clean G+Smo
  • in the build folder of G+Smo, I included submodule: gsPreCICE;gsKLShell;gsElasticity;gsStructuralAnalysis
  • make perpendicular-flap-vertex-gismo
  • sudo make install perpendicular-flap-vertex-gismo
• switched back to the pr, and run the run.sh script in fluid-openfoam and solid-gismo

I am able to run this example following these steps and I could not replicate the issue here.

[MakisH]

I tried again, after pulling the latest state of this branch and of Gismo:

• Tutorials perpendicular-flap-gismo-elasticity-stress Mar 24 (bd0610f)
• Gismo stable Mar 23 (390eaf68de077ecddb5ae9f899fa88bf8a84a244)
• preCICE develop Mar 21 (6c1b8590c1895502443901f73bdde71a53d776f2) with PRECICE_FEATURE_PETSC_MAPPING ON and PRECICE_FEATURE_GINKGO_MAPPING OFF
• OpenFOAM v2406
• OpenFOAM adapter develop Mar 21 (fc16b305bd43f455b9ce044acadd42c56b52fdf4)
• Running on my laptop: Ubuntu 22.04, Eigen 3.4.0, PETSc 3.15.

Same error.

[MakisH]

@Crazy-Rich-Meghan which state of preCICE are you using? I can try checking with that, to exclude any bugs in preCICE develop.

[uekerman]

It worked for me previously, but I am now trying to mimic @MakisH 's setup.

I, however, get an error when trying to build that version of gismo:

Building CXX object optional/gsElasticity/CMakeFiles/gsElasticity.dir/gsBiharmonicAssembler_.cpp.o
In file included from /home/uekermbn/Repos/gismo/optional/gsElasticity/gsBaseAssembler.h:17,
                 from /home/uekermbn/Repos/gismo/optional/gsElasticity/gsBiharmonicAssembler.h:17,
                 from /home/uekermbn/Repos/gismo/optional/gsElasticity/gsBiharmonicAssembler_.cpp:3:
/home/uekermbn/Repos/gismo/src/gsAssembler/gsAssembler.h: In instantiation of ‘void gismo::gsAssembler<T>::apply(ElementVisitor&, size_t, gismo::boxSide) [with ElementVisitor = gismo::gsVisitorBiharmonicMixed<double>; T = double; size_t = long unsigned int]’:
/home/uekermbn/Repos/gismo/src/gsAssembler/gsAssembler.h:462:13:   required from ‘void gismo::gsAssembler<T>::push(const ElementVisitor&) [with ElementVisitor = gismo::gsVisitorBiharmonicMixed<double>; T = double]’
/home/uekermbn/Repos/gismo/optional/gsElasticity/gsBiharmonicAssembler.hpp:93:54:   required from ‘void gismo::gsBiharmonicAssembler<T>::assemble(bool) [with T = double]’
/home/uekermbn/Repos/gismo/optional/gsElasticity/gsBiharmonicAssembler_.cpp:8:25:   required from here
/home/uekermbn/Repos/gismo/src/gsAssembler/gsAssembler.h:721:27: error: cannot convert ‘gismo::gsBasis<double>::domainIter’ {aka ‘gismo::gsDomainIteratorWrapper<double>’} to ‘gismo::gsDomainIterator<double>&’
  721 |         visitor_.assemble(domIt, quWeights);
      |                           ^~~~~
      |                           |
      |                           gismo::gsBasis<double>::domainIter {aka gismo::gsDomainIteratorWrapper<double>}
In file included from /home/uekermbn/Repos/gismo/optional/gsElasticity/gsBiharmonicAssembler.hpp:20,
                 from /home/uekermbn/Repos/gismo/optional/gsElasticity/gsBiharmonicAssembler_.cpp:4:
/home/uekermbn/Repos/gismo/optional/gsElasticity/gsVisitorBiharmonicMixed.h:74:48: note:   initializing argument 1 of ‘void gismo::gsVisitorBiharmonicMixed<T>::assemble(gismo::gsDomainIterator<T>&, const gismo::gsVector<T>&) [with T = double]’
   74 |     inline void assemble(gsDomainIterator<T> & element,
      |                          ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~

[uekerman]

@hverhelst Thanks for the quick reaction. I wasn't aware that this is necessary. I now used a fresh clone again.

And indeed I also run into the same problem as @MakisH

• Tutorials: same as @‌MakisH
• Gismo: same as @‌MakisH
• preCICE develop Mar 24 (5909d6548) (PETSc off), almost the same as @‌MakisH
• OpenFOAM v2212
• OpenFOAM adapter v1.3.1
• Ubuntu 20.04, Eigen 3.4.0

[hverhelst]

Okay, that's somehow good. I think @Crazy-Rich-Meghan is on it right now. I'll wait for her response.

[uekerman]

I get a similar problem with preCICE v3.1.2

---[precice] ERROR:  The interpolation matrix of the RBF mapping from mesh "Solid-Mesh" to mesh "Fluid-Mesh" is not invertable. This means that the mapping problem is not well-posed. Please check if your coupling meshes are correct (e.g. no vertices are duplicated) or reconfigure your basis-function (e.g. reduce the support-radius).

[uekerman]

Visualizing the coupling mesh of G+Smo looks strange. I get a volume mesh, not a surface mesh. The tip of the flap:

[uekerman]

And it is a 3D mesh, so duplicated vertices for a mapping in 2D, which explains the error.

@hverhelst Did you change anything in the adapter in this direction recently?

[Crazy-Rich-Meghan]

Hi @MakisH and @uekerman ,

I tried to do it as Makis suggested and I arrived at the similar error. So I set back G+Smo and submodules few commits and now it worked for me:

• Main gismo (stable at 460d8dc4)
• gsElasticity (master at 5eb301c)
• gsStructuralAnalysis (main at 99ee486)
• gsPreCICE (main at 8633422 latest)
• preCICE version (3.1.2)

grep "VERSION" /usr/lib/x86_64-linux-gnu/cmake/precice/preciceConfigVersion.cmake
# The created file sets PACKAGE_VERSION_EXACT if the current version string and
# PACKAGE_VERSION_COMPATIBLE if the current version is >= requested version,
# The variable CVF_VERSION must be set before calling configure_file().
set(PACKAGE_VERSION "3.1.2")

• Tutorial version (this PR at bd0610f latest)

And my PC is Ubuntu 24.04. @hverhelst Maybe you have an idea about what is going wrong here, could be related to one of the recent commits to G+Smo.