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]

@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.

[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.

[Crazy-Rich-Meghan]

Hi @uekerman and @MakisH,

Thanks again for your help! We @hverhelst have merged PRs to stable G+Smo and the preCICE adapter to fix the compatibility with the newer version G+Smo. Now the previous mentioned issue should be resolved

[MakisH]

@Crazy-Rich-Meghan @hverhelst side question: How do you normally rebuild G+smo? Do you always need to make a clean build? Whenever I try to pull (also in the submodules) and directly run make, it leads to all kinds of compilation errors.

I am just trying to save a bit of time, since a clean build takes a while. Not urgent (I already rebuilt successfully), but I was wondering.

[MakisH]

Looks perfect to me now, thanks for the quick updates! 😄

See also precice/precice.github.io#516

[hverhelst]

@Crazy-Rich-Meghan @hverhelst side question: How do you normally rebuild G+smo? Do you always need to make a clean build? Whenever I try to pull (also in the submodules) and directly run make, it leads to all kinds of compilation errors.

I am just trying to save a bit of time, since a clean build takes a while. Not urgent (I already rebuilt successfully), but I was wondering.

@MakisH I never run a clean build. I usually pull (incl. submodules) and run a make target instead of a make. In that way I avoid compiling all examples. In addition, for small changes it will only compile the changed files, so a build should be small.
Regarding the compilation errors: what do you get? We had some breaking changes recently, most of them are resolved since today. In addition, we have some deprecated functions right now that will go out in a new release (probably June).

[MakisH]

Ah, ok, I guess I stumbled upon some of the breaking changes then. I was also previously building all targets, which probably increased the range of what can go wrong. I did not log the messages, as this was clearly a dirty build. Thanks!