precice / tutorials

Various tutorial cases for the coupling library preCICE with real solvers. These files are meant to be rendered on precice.org, so don't look at the README files here.

preCICE tutorials

Important

This repository is aimed for development purposes and the default branch is develop. If you want to use the tutorials, switch to the master branch or download the latest release.

This repository contains ready-to-run tutorial cases for the coupling library preCICE. The purpose of these cases is not to teach you how to use preCICE from scratch, but to serve as starting points for setting up similar simulation cases, as well as test cases. Read more on our preCICE tutorials documentation section.

As a general rule, you can start each participant from inside their <tutorial>/<participant>-<solver> using ./run.sh. Look into these short scripts and copy the parts you need for your new case. Before running again, execute the cleaning scripts you can find at each level, to clean from this point and deeper.

Contributions to this repository are very welcome. Please refer to the page Contribute to preCICE for a few guidelines and hints to help you in this direction.

Note that we use Git LFS to version reference results. These will appear as seemingly empty files containing URLs if you don't have Git LFS installed (optional, mainly useful for our system tests).

tutorials's Issues

FSI/flap_perp/OpenFOAM-deal.II case: Missing README

For this tutorial we have a very nice wiki page, which is linked in the main README file of the tutorials, but there is no README in the case.

This is especially important in the Deal.II tutorials, as we ask the user to copy the solver into the case directory.

Copying the one for cylinderFlap should be enough.

heat-exchaner: the mesh could be coarser (currently, downloading additional files is needed)

Although this is a more complicated scenario and it would be complicated to provide specifications, it would be good to have geometry files somewhere.

For historical reasons, we don't have access to the source geometry files anymore. Reconstructing the geometry or adapting the tutorial to a known geometry would be useful, so that if anyone wants to change one of the solvers, they can do it.

Note that the tutorial should not start from producing the meshes, but the user should be able to do this.

Todo:

• Add some geometry files (reconstruct or adapt the tutorial)
• Add short instructions on how to produce the meshes.

Convert Nutils CHT tutorial to use precice_future

The code: https://github.com/precice/tutorials/blob/master/CHT/flow-over-plate/buoyantPimpleFoam-nutils/Nutils/cht.py

The new bindings: https://github.com/precice/precice/tree/develop/src/precice/bindings/python_future

elastic-tube-1d: Allow to create plot in background/silent mode

Currently the python tube creates a plot for each frame of a video. However, these plots are quite "agressive". I mean that a new plot pops up for every frame. This is annoying, if you want to run the python tube in background in order to create a video, since you cannot silence the output.

Convergence issue in nearest-projection mapping in fenics-fenics HT case for complex domain

A convergence study was conducted for the tutorial HT/partitioned-heat/fenics-fenics with nearest-projection and nearest-neighbor mappings for a simple interface (linear edge interface parallel to Y-axis) and a complex interface (Circular interface bounded in a rectangular domain). The simple interface study shows good results of improvement from nearest-neighbor to nearest-projection. The complex domain is visualised as follow:

The convergence study results are as follows:

It is seen that there is no significant improvement in the error plot when nearest-projection mapping is used instead of nearest-neighbor. One possible explanation is the error induced due to the RBF interpolation strategy being used contributes significantly to the total error and hence masks the effects of an improved mapping. Further investigation needs to be done.

Tutorial with CalculiX: instructions for visualization

Todo:

• In the FSI with SU2 and CalculiX tutorial, information is missing on how to visualize the CalculiX results. I think that some short instructions would be useful.
• In the CHT with OpenFOAM and CalculiX tutorial, there is a short reference to use CGX or external tools. Some more elaborate instructions would be useful.

One could argue that a user should already know the solvers, but I think we can provide some first hints for users that want to use these as a starting point for a coupled simulation with other solvers.

Screen output format for the tutorials

In the OpenFOAM adapter, we distinguish the adapter output from the OpenFOAM output using the a prefix, as e.g.:

DICPCG:  Solving for p_rgh, Initial residual = 0.311219, Final residual = 9.37315e-09, No Iterations 215
diagonal:  Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 7.66604e-10, global = -6.21739e-10, cumulative = -1.45326e-07
ExecutionTime = 0.22 s  ClockTime = 0 s

---[preciceAdapter] [DEBUG] Writing coupling data...
---[preciceAdapter] [DEBUG] Advancing preCICE...
(0) 18:56:17 [impl::SolverInterfaceImpl]:378 in advance: it 2 of 200 | dt# 1 | t 0 of 1 | dt 0.01 | max dt 0.01 | ongoing yes | dt complete no | read-iteration-checkpoint | 
---[preciceAdapter] [DEBUG] Reading a checkpoint...

Beginning: OpenFOAM, then adapter, then preCICE, then again adapter.

As @uekerman mentioned in precice/openfoam-adapter#89:

Some cosmetics: we could use a formatting of the preCICE logging which is similar to ---[preciceAdapter], maybe ---[precice] (in the preCICE configs of the tutorials). I guess most important for the user is to distinguish OpenFOAM output from preCICE output (adapter + library).

You can simply configure this in the preCICE config at runtime. See the second example in the wiki. This, we could do for the tutorials. But no must.

I think that this is a good idea and would bring consistency in the tutorials. Two work packages:

• Use the ---[precice] in every tutorial's precice-config.xml (primary)
• Use the ---[preciceAdapter] (or even ---[preciceSOLVERNAMEAdapter]) in every adapter (secondary)

3D_Tube missing runFluid / runSolid

In most of the tutorial cases, we provide both an Allrun script (run all participants at once) and individual run scripts for each participant.

We are missing these scripts in the 3D_Tube case.

elastic-tube-1d: Missing documentation elements for visualization

The documentation and code for visualization of the PythonTube really need some polishing. Currently, it is really hard to understand how plots are created etc.

This is just a quick, unsorted collection of material:

• We can create VTK files with velocity and tube diameter. See output.py
• I do not know a nice way for using these VTK files in paraview. The VTK files are used in plotting here
• The script fluid.py allows us to create this plot. I do not think that this plot is really useful, but at least there exists some documentation on it here. A newer plot is now available and provides much more relevant information regarding results.
• We have a nice gif of the elastictube. However, it is not documented, how this gif was actually created. With some insider knowledge, it is possible to find the code here.

What would be nice:

• Merge the gif/video output from convergenceStudies into master
• Document: How do I create gif/video output? (replace this paragraph)
• Find out how to make use of the VTK output or drop it.

Parallel FEniCS test case fails

Hi,

I tried to run the parallel FEniCS test case. However, when building the adapter I ran into issues (see precice/fenics-adapter#39). I got the adapter to compile (I think at least), but now run into an error when running the test case.

I call

mpirun -n 2 python3 heat.py -d : -np 2 python3 heat.py -n

and get the following error message:

Traceback (most recent call last):
  File "heat.py", line 161, in <module>
    interpolation_strategy = fenicsadapter.core.ExactInterpolationExpression
AttributeError: module 'fenicsadapter.core' has no attribute 'ExactInterpolationExpression'
Traceback (most recent call last):
  File "heat.py", line 161, in <module>
    interpolation_strategy = fenicsadapter.core.ExactInterpolationExpression
AttributeError: module 'fenicsadapter.core' has no attribute 'ExactInterpolationExpression'
Traceback (most recent call last):
  File "heat.py", line 161, in <module>
    interpolation_strategy = fenicsadapter.core.ExactInterpolationExpression
AttributeError: module 'fenicsadapter.core' has no attribute 'ExactInterpolationExpression'
Traceback (most recent call last):
  File "heat.py", line 161, in <module>
    interpolation_strategy = fenicsadapter.core.ExactInterpolationExpression
AttributeError: module 'fenicsadapter.core' has no attribute 'ExactInterpolationExpression'

Does this mean that I did not properly compile the adapter or is there something else wrong?

Best,
Alex

Restructure/Reduce code/config duplication for tutorials using the same scenario

Example: For the flow-over-plate example we have multiple possible setups:

• FEniCS-OpenFOAM
• Nutils-OpenFOAM
• OpenFOAM-OpenFOAM

We see that OpenFOAM is used several times as a flow solver.

Currently, there are two main approaches to provide the necessary code:

• User copies OpenFOAM Fluid setup from elsewhere (user interaction necessary, errorprone; example: FEniCS-OpenFOAM)
• OpenFOAM Fluid setup is provided in tutorial (code duplication; example Nutils-OpenFOAM)

How can we organize our code in such a scenario without introducing code duplication or asking the user to copy code from elsewhere?

deal.II tutorials: update dimension requirement

Since precice/dealii-adapter@d206224, our deal.II adapted solver defaults to 2D instead of 3D. We need to explicitly state it in the documentation of each tutorial.

Use markActionFulfilled

Compatibility issue, see precice/precice#631

Explain configuration with comments in xml files

As the tutorials will be used primarily by new preCICE users, there should be some explanation of the setup directly inside the configuration files.

This is feedback from the Workshop 2020.

Nutils participant crash causes systemtest failure

The systemtest for nutils-of has stopped working recently. In the highlighted line 756 of this job log we can see that the Nutils participant launches the cht.py script from the Nutils tutorial and subsequently errors:

Attaching to nutils-adapter
nutils-adapter | Traceback (most recent call last):
nutils-adapter |   File "cht.py", line 3, in <module>
nutils-adapter |     import nutils, numpy, treelog
nutils-adapter |   File "/home/[secure]/nutils/nutils/__init__.py", line 37, in <module>
nutils-adapter |     from . import numeric, element, function, expression, mesh, topology, util, \
nutils-adapter |   File "/home/[secure]/nutils/nutils/element.py", line 31, in <module>
nutils-adapter |     from . import util, numpy, numeric, cache, transform, warnings, types, points, _
nutils-adapter |   File "/home/[secure]/nutils/nutils/cache.py", line 25, in <module>
nutils-adapter |     from . import types, log
nutils-adapter |   File "/home/[secure]/nutils/nutils/log.py", line 26, in <module>
nutils-adapter |     import builtins, itertools, treelog, contextlib, sys, inspect, distutils
nutils-adapter |   File "/home/[secure]/.local/lib/python3.5/site-packages/treelog/__init__.py", line 25, in <module>
nutils-adapter |     from . import iter, proto
nutils-adapter |   File "/home/[secure]/.local/lib/python3.5/site-packages/treelog/iter.py", line 16, in <module>
nutils-adapter |     class wrap(typing.Generic[T]):
nutils-adapter |   File "/home/[secure]/.local/lib/python3.5/site-packages/treelog/iter.py", line 49, in wrap
nutils-adapter |     def __exit__(self, exctype: typing.Optional[typing.Type[BaseException]], excvalue: typing.Optional[BaseException], tb: typing.Optional[types.TracebackType]) -> None:
nutils-adapter |   File "/usr/lib/python3.5/typing.py", line 649, in __getitem__
nutils-adapter |     return Union[arg, type(None)]
nutils-adapter |   File "/usr/lib/python3.5/typing.py", line 552, in __getitem__
nutils-adapter |     dict(self.__dict__), parameters, _root=True)
nutils-adapter |   File "/usr/lib/python3.5/typing.py", line 512, in __new__
nutils-adapter |     for t2 in all_params - {t1} if not isinstance(t2, TypeVar)):
nutils-adapter |   File "/usr/lib/python3.5/typing.py", line 512, in <genexpr>
nutils-adapter |     for t2 in all_params - {t1} if not isinstance(t2, TypeVar)):
nutils-adapter |   File "/usr/lib/python3.5/typing.py", line 1077, in __subclasscheck__
nutils-adapter |     if super().__subclasscheck__(cls):
nutils-adapter |   File "/usr/lib/python3.5/abc.py", line 225, in __subclasscheck__
nutils-adapter |     for scls in cls.__subclasses__():
nutils-adapter | TypeError: descriptor '__subclasses__' of 'type' object needs an argument

Following this message, the OpenFOAM participant fails to communicate with the crashed Nutils participant and terminates the test.

Missing file in FSI/cylinderFlap/OpenFOAM-CalculiX ?

Hello,

I tried to run the FSI/cylinderFlap/OpenFOAM-CalculiX but an error occured for the Solid solver as a file is missing :
*ERROR in readinput: cannot open file Solid/all.msh

I cloned the git repository and I am wondering if I made a mistake or if it is really a missing file in the repo?

FSI SU2-CalculiX tutorial: geometry specifications and files

I extracted the geometry specifications after visualizing the SU2 results, however it would be good to also have the geometry files and instructions somewhere. If a user is not familiar with SU2 or CalculiX but is developing a case using a different solver, they could use this as a starting point.

Note that the tutorial should not start from producing the meshes, but the user should be able to do this if needed. I think this would accelerate the development of other scenarios or adapters.

Todo:

• Update the geometry image: the flap is not at the center, it would be good to have dimensions and units.
• Upload the source geometry files or point to configuration files.
• Write some short instructions on producing the mesh from the geometry.

PETSC ERROR in cylinderFlap by Allrun_parallel

Dear developers,

Thanks for your nice code. I successfully tried FSI tutorial of flap_perp using Openfoam-adapter and Calculix in both serial and parallel.

But I tried the FSI tutorial of cylinderFlap using Allrun_parallel. But it gives me the following error info:

[1]PETSC ERROR: ------------------------------------------------------------------------
[1]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably memory access out of range
[1]PETSC ERROR: Try option -start_in_debugger or -on_error_attach_debugger
[1]PETSC ERROR: or see http://www.mcs.anl.gov/petsc/documentation/faq.html#valgrind
[1]PETSC ERROR: or try http://valgrind.org on GNU/linux and Apple Mac OS X to find memory corruption errors
[1]PETSC ERROR: configure using --with-debugging=yes, recompile, link, and run
[1]PETSC ERROR: to get more information on the crash.
[1]PETSC ERROR: User provided function() line 0 in unknown file

See details in this attached log file.
Fluid.log
Solid.log

Do you have any idea about this issue?

Thanks,
Tianqi

Fix checkpointing for FEniCS FSI tutorials

Only u_n is considered by the checkpointing. But we should also properly checkpoint v_n and a_n. There is already a prototype implementation on this branch (don't merge this branch, it has a different purpose!)

The most important part is

tutorials/FSI/cylinderFlap/OpenFOAM-FEniCS/Solid/cyl-flap.py

Lines 238 to 243 in b3b4985

	solve(A, u_np1.vector(), b_forces)
	a_np1 = project(update_acceleration(u_np1, u_n, v_n, a_n, ufl=False), V)
	v_np1 = project(update_velocity(a_np1, u_n, v_n, a_n, ufl=False), V)
	t, n, precice_timestep_complete, precice_dt, Forces_x, Forces_y = precice.advance(u_np1, (u_np1, v_np1, a_np1), (u_n, v_n, a_n), t, float(dt), n)

Segmentation fault from Solid participant

Hi @MakisH,

I am trying to use this system test in a docker (link). I am building a docker image with all needed software and than simulate, but the simulation fails:

Output of Allrun script:

Setting up the preCICE configuration file for a serial simulation
Preparing the Inner-Fluid participant...
Starting the Inner-Fluid participant...
Preparing the Outer-Fluid participant...
Starting the Outer-Fluid participant...
Starting the Solid participant...
Waiting for the participants to exit...
(you may run 'tail -f Inner-Fluid.log' in another terminal to check the progress)
./Allrun: line 62:   176 Segmentation fault      (core dumped) ${Solver3} -i ${Participant3}/solid -precice-participant ${Participant3} > ${Participant3}.log 2>&1

Something went wrong... See the log files for more.

Than i look in the Solid.log I find following message (dots denote more Output, to be exactly a table with the summary):

Run finished at Tue May 15 14:11:00 2018
Global runtime       = 159264ms / 159s
Number of processors = 1
# Rank: 0

....

[3ac372e390fb:00176] *** Process received signal ***
[3ac372e390fb:00176] Signal: Segmentation fault (11)
[3ac372e390fb:00176] Signal code: Address not mapped (1)
[3ac372e390fb:00176] Failing at address: (nil)
[3ac372e390fb:00176] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x354b0)[0x7f92306644b0]
[3ac372e390fb:00176] [ 1] /precice/build/last/libprecice.so(_ZN7precice4impl19SolverInterfaceImpl8finalizeEv+0x5ab)[0x7f922fd104ab]
[3ac372e390fb:00176] [ 2] /precice/build/last/libprecice.so(precicec_finalize+0x199)[0x7f922fd9f176]
[3ac372e390fb:00176] [ 3] ccx_preCICE[0x6052ce]
[3ac372e390fb:00176] [ 4] ccx_preCICE[0x6041b1]
[3ac372e390fb:00176] [ 5] ccx_preCICE[0x602de4]
[3ac372e390fb:00176] [ 6] ccx_preCICE[0x40fee8]
[3ac372e390fb:00176] [ 7] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f923064f830]
[3ac372e390fb:00176] [ 8] ccx_preCICE[0x408499]
[3ac372e390fb:00176] *** End of error message ***

Used flags in Makefile:

CFLAGS = -g -Wall -std=c++11 -O0 -fopenmp $(INCLUDES) -DARCH="Linux" -DSPOOLES -DARPACK -DMATRIXSTORAGE
FFLAGS = -g -Wall -O0 -fopenmp $(INCLUDES)

Versions of the used software:

OpenFOAM-adapter Version: 890ae8c834d59d9ea459fabc08ea23252dbf0bcf refs/heads/v2.12
CalculiX-adapter Version: 890ae8c834d59d9ea459fabc08ea23252dbf0bcf refs/heads/v2.12
tutorials Version: f19a8a563215320b570237c593e0c2a74d7dc356 refs/pull/1/head
preCICE Version: c957f625350bbdfcda497c4288e286884064861c refs/tags/v1.1.1
OpenFOAM version: 4.1
CalculiX version: 2.12
Ubuntu version: 16.04

What is wrong? How can I debug this? Looking forward to your reply.

Best regards,
Yakup

Inconsistent .gitignore among cases

In most cases, we don't have a .gitignore file, assuming that a developer would clean the result files (e.g. using Allclean) before commiting.

In other cases (e.g. tutorials/FSI/flap_perp/OpenFOAM-FEniCS/), we provide a .gitignore. In this specific case, the .gitignore is ignoring the complete case directories and then un-ignores specific files.

This inconsistency can lead in overseeing files when applying the same change in every tutorial.

A nice approach would be to have a global tutorials/.gitignore for the usual suspects (e.g. preCICE log files) and each tutorial could provide its own .gitignore for any special files.

Create data mapping tutorial with ASTE

We regularly face the issues that users have problems with understanding the mapping configuration and how well the mapping works, in particular for RBF data mapping.

On the other hand, ASTE already has some nice features to do mappings with artificial geometries (and a demo). The only step missing is to write a nice little tutorial around that (in the preCICE wiki) and explain how to compare different mapping algorithms.

elastic-tube-1d: Make matplotlib and vtk an optional dependency

The python tube requires matplotlib and vtk for plotting and output. Currently, these dependencies are mandatory due to the following line in FluidSolver.py:

https://github.com/precice/elastictube1d/blob/02d9e8f50c32343dcf6a38541323120a0230c453/python/FluidSolver.py#L8

Even users that do not want to do plotting or write output have to install matplotlib and vtk. We should try to make these dependencies optional.

Duplicate Allclean files

We currently duplicate a lot of code in our helper scripts. In particular the code in the Allclean is quite duplicate, leading us to apply the same changes again and again (most probably, inconsistently).

We could just have one directory tutorials/tools and inside there an Allclean that can be applied to any tutorial. Then, for every tutorial we could have a symbolic link to this file for easy access.

Update clean scripts to clean *events.json

The latest preCICE creates files such as precice-Fluid-events.json precice-Solid-events.json. We need to delete these as well.

elastic-tube-1d: Provide a requirements.txt for the Python version

This will make life easier for users and testers.

Rotate FSI flap_perp case

It is currectly a pseudo-2D case on y-z, we need it on x-y for consistency.

Some FSI tutorials are not working with OpenFOAM6

What's the problem?

I am using OpenFOAM6 on my machine and the tutorial cases tutorials/FSI/cylinderFlap/* do not work. I explicitly tested the case tutorials/FSI/cylinderFlap/OpenFOAM-FEniCS while checking #38. For the other cases I tried executing runFluid and it always resulted in an error thrown by OpenFOAM (OF), even before the coupling was initialized.

My proposed workaround

Commenting out some lines in Fluid/system/fvSolution does the trick and it works:

PIMPLE
{
    nCorrectors 2;
    nNonOrthogonalCorrectors 0;
    tolerance 1.0e-14;
    relTol 5e-3;
    pisoTol 1e-6;
    consistent  true;

    nOuterCorrectors 50;

    // residualControl
    // {
    //        U
    //    {
    //        tolerance 5e-5;
    //        relTol      0;
    //    }
    //    p
    //    {
   //         tolerance 5e-4;
   //         relTol      0;
   //     }
   // }
}

Note again: I only explicitly tested the case with OpenFOAM and FEniCS. For OpenFOAM and deal.II, OpenFOAM and CalculiX respectively, I only ran runFluid and with the changes mentioned above OpenFOAM does not exit with an error, but executes until coupling is initialized and it is waiting for the second participant.

What I already did

• The FEniCS test cases are working (until the very end) without changes on my machine with OF6 using the revision provided on master.
• I needed to apply some changed for the other cases (CalculiX, deal.II). Using the revision on branch https://github.com/precice/tutorials/tree/OpenFOAM6 the cases are working without changes, but I only validated until the coupling is initialized and OpenFOAM is waiting for the Solid solver. 7f3344b.

What should we do now?

The fix I am proposing above seems to work. However, there are some more things we should do in order to improve the compatibility of the tutorials with different version of OpenFOAM (bold for important ones and italics for less important):

• Check whether the proposed fix worsens the performance Especially the first few iterations are very expensive. This might be a property of the test case or the performance has been worsened by removing the residualControl. I am not an OpenFOAM expert and I did not compare with the performance using a different OpenFOAM version that accepts residualControl.
• Test tutorials and OF-adapter for different versions of OF. I think we should open this issue in https://github.com/precice/systemtests. Currently, we only test with OF4 (see here).
• Test cylinderFlap. Again, this is an issue for https://github.com/precice/systemtests. Currently, we only test flap_perp. Here, residualControl is not provided in fvSolution (see here). Therefore, I also did not observe any problems when running flap_perp under OF6 and I did not expect any problems to show up running cylinderFlap.
• follow up: there are quite some differences in the tolerances provided in fvSolution of the both cases. Why?
• automatically choose pimpleFoam or pimpleDyMFoam In Fluid/system/controlDict one has to manually choose the fitting solver. This straightforward, but still has to be done manually.

CHT ccx_preCICE never starts computing

Hi,
I'm trying to work through the CHT-tutorial. I'm using docker to realize the tutorial. You can find the Dockerfile (Dockerfile.of-ccx) here. Openfoam starts and finishes to compute (I set the endTime to 20.0), but ccx_preCICE starts and never ends. If I tail Solid.log, I get following output:

Read data 'Sink-Temperature-Inner-Fluid' found.
Read data 'Heat-Transfer-Coefficient-Inner-Fluid' found.
Write data 'Sink-Temperature-Solid' found.
Write data 'Heat-Transfer-Coefficient-Solid' found.
Read data 'Sink-Temperature-Outer-Fluid' found.
Read data 'Heat-Transfer-Coefficient-Outer-Fluid' found.
Write data 'Sink-Temperature-Solid' found.
Write data 'Heat-Transfer-Coefficient-Solid' found.
(0) 17:58:30 [impl::SolverInterfaceImpl]:213 in initialize: Setting up master communication to coupling partner/s

This happens in 'sequentiell' (./Allrun) and in 'parallel' (./Allrun_parllel). Also tried to start the simulation with 3 seperate terminals and manually typed commands, same outcome.

The setup:
OS: ubuntu 18.04
preCICE: 1.0.3
ccx: 2.12
ccx-adapter: 2.12
openfoam: 5.x-197d9d3bf20a
openfoam-adapter: commit 36852e081022b3d58c489643e8ac48a3b92a0fea

Can somebody help me?
Best regards.

Incorrect watchpoint definition in OpenFOAM-CalculiX [PETSc/FSI]

See https://travis-ci.org/github/precice/systemtests/jobs/701936383#L686.

Both participants are crashing with the following message:

calculix-adapter-solid    | ---[precice] ERROR:  Participant "Fluid" defines watchpoint "point1" for the received mesh "Solid, which is not allowed. Please move the watchpoint definition to the participant providing mesh "Solid".

Enforce consistency among tutorials

It would be nice to enforce particular structure of tutorials, so new system tests based on tutorials can be added easier and overall orientation around tutorials made simpler. For instance:

• Have different directories for input of different solvers with suitable names ( this is mostly done everywhere, apart from SU2-Calculix (see #36 ) )
• Have separate directories with the output of different solvers
• Have convention about the structure of the precice-config files. For instance consistent order of attributes in the m2n tag, so that it is easier to parse (for instance to change exchange directory when running with docker ).

flow over plate tutorial's Fluid cases differ

• Fluid folder for the OF-OF coupling: folder is called Fluid. Participant is called Fluid. Allrun script is provided in parent folder.
• Fluid folder for the OF-FE coupling does not exist, but has to be copied from OF-OF case: No Allrun or runFluid script is provided. User has to manually start the case.
• Fluid folder for the OF-Nutils coupling: folder is called OpenFOAM. Participant is called OpenFOAM. runFluid script is provided in OpenFOAM folder.

This inconsistency leads to problems, if for the OF-FE case the user does not copy the Fluid folder from the OF-OF case (what we suggest in the documentation), but from the OF-Nutils case (which is available in the tutorials).

Can we improve this situation by using the same structure for all cases? From my point of view the participant names should be consistent. Running via Allrun vs. runFluid vs. manually is not very critical, but could by achieved by changing the Allrun script to call independent runFluid and runSolid scripts.

Another solution would be to provide an independent Fluid folder in the FE-FE case. This will avoid mistakes, but I like it that the copy-paste approach currently very explicitly illustrates the idea of reusing an existing solver.

Use isTimeWindowComplete API function, if necessary

See precice/precice#619

Inappropriate setup for FSI OpenFOAM tutorials

During my work on precice/dealii-adapter#24, I struggled heavily with added mass instabilities. From the structural participant side, there is not really that much you can do to tackle this issue, since displacement and all its derivatives are zero in the beginning i.e. no inertia.
Choosing a different setup (fvSchemes/fvSolutions) in the Fluid participant solves the issue (at least in my case), improves it in any case.

Since these are official tutorials, we should provide a good setup, especially considering the instabilities in FSI cases. Many users probably just copy these configurations and I think there have already been some discussions on discourse with users, facing similar problems.

FSI with OpenFoam and CalculiX: specify Fluid Solver

The readme and runFluid script have no Comment on the Fluid Solver that the user should change for older OpenFOAM versions (that are stated as compatible in the readme). I think that should be mentioned somewhere in the readme.

Otherwise the runFluid script results in the following error that does not lead new users to the fix:

--> FOAM FATAL ERROR: 
Error in the preCICE adapter: 
There was a problem while configuring the adapter. See the log for details.e pointVectorField are
0()

    From function void adapterInfo(std::__cxx11::string, std::__cxx11::string)
    in file Utilities.C at line 31.

FOAM exiting

Looking for any time directories without results (e.g. stray functionObjectProperties files, see issue #26 on GitHub)...

The solution of changing the solver name is described in the Allrun sript though:

        echo "  ### WARNING ### Make sure to use the correct solver for your OpenFOAM version! (pimpleFoam for OpenFOAM v1806, OpenFOAM 6, or newer, vs pimpleDyMFoam for older) You may change this in your Fluid/system/controlDict file, if needed."

flap_perp/OpenFOAM-deal.II (linear) throws segmentation fault

I currently get:

$ ./runSolid -linear
---[precice]  This is preCICE version 2.0.2
---[precice]  Revision info: v2.0.2
---[precice]  Configuring preCICE with configuration: "precice-config.xml"
Triangulation:
	 Number of active cells: 54
	 Polynomial degree: 2
	 Number of degrees of freedom: 2,331
	 Output written to solution-0.vtk 

	 Number of coupling nodes:     237
---[precice]  Setting up master communication to coupling partner/s
---[precice]  Masters are connected
---[precice]  Setting up preliminary slaves communication to coupling partner/s
---[precice]  Receive global mesh Fluid-Mesh-Centers
---[precice]  Receive global mesh Fluid-Mesh-Nodes
---[precice]  Prepare partition for mesh Solid_mesh
---[precice]  Gather mesh Solid_mesh
---[precice]  Send global mesh Solid_mesh
---[precice]  Setting up slaves communication to coupling partner/s
---[precice]  Slaves are connected
---[precice]  Compute read mapping from mesh "Fluid-Mesh-Centers" to mesh "Solid_mesh".
---[precice]  Using tree-based preallocation for matrix C
---[precice]  Using tree-based preallocation for matrix A
---[precice]  Mapping Stress consistent from Fluid-Mesh-Centers (ID 0) to Solid_mesh (ID 2) for dimension 0) with polynomial set to separate
---[precice]  Mapping Stress consistent from Fluid-Mesh-Centers (ID 0) to Solid_mesh (ID 2) for dimension 1) with polynomial set to separate
---[precice]  Mapping Stress consistent from Fluid-Mesh-Centers (ID 0) to Solid_mesh (ID 2) for dimension 2) with polynomial set to separate
---[precice]  it 1 of 50 | dt# 1 | t 0 of 5 | dt 0.01 | max dt 0.01 | ongoing yes | dt complete no | write-iteration-checkpoint | 

Timestep 1 @ 0.010000s
	 Direct solver: 
	     No of iterations:	1
 	     Final residual:	0.000000
---[precice]  relative convergence measure: two-norm diff = 0, relative limit = 0, conv = true
---[precice]  relative convergence measure: two-norm diff = 0, relative limit = 0, conv = true
---[precice]  All converged
---[precice]  Time window completed
---[precice]  Performing first order extrapolation
---[precice]  Mapping Stress consistent from Fluid-Mesh-Centers (ID 0) to Solid_mesh (ID 2) for dimension 0) with polynomial set to separate
---[precice]  Mapping Stress consistent from Fluid-Mesh-Centers (ID 0) to Solid_mesh (ID 2) for dimension 1) with polynomial set to separate
---[precice]  Mapping Stress consistent from Fluid-Mesh-Centers (ID 0) to Solid_mesh (ID 2) for dimension 2) with polynomial set to separate
---[precice]  it 1 of 50 | dt# 2 | t 0.01 of 5 | dt 0.01 | max dt 0.01 | ongoing yes | dt complete yes | write-iteration-checkpoint | 

Timestep 2 @ 0.020000s
	 Direct solver: 
	     No of iterations:	1
 	     Final residual:	0.000000
---[precice]  relative convergence measure: two-norm diff = 0, relative limit = 0, conv = true
---[precice]  relative convergence measure: two-norm diff = 0, relative limit = 0, conv = true
---[precice]  All converged
[0]PETSC ERROR: ------------------------------------------------------------------------
[0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably memory access out of range

While the 2D case works as expected. Can anybody else reproduce this?

Create Tutorial for "Replay Mode"

CHT flow-over-plate with OpenFOAM and FEniCS/Nutils: compute heat flux from temperature

The heat flux computation of both approaches (OpenFOAM/FEniCS and OpenFOAM/Nutils) is currently different. Are both versions correct or is one of them wrong? In the end one consistent way form computing the flux would be desirable.

FASTEST adapter problems

Hi, I try to modify the adapter for FASTEST because our current adapter does not work with the extrapolation and the parallel coupling does not present advantages to the serial coupling. The setup of the meshes and initial configuration works well, but our coupling process is different from the adapter example, and I think that maybe it is the reason for my problems.

the original implementation is the following:

while (not simulationDone()){ // time loop
dt = beginTimeStep(); // e.g. compute adaptive dt
dt = min(precice_dt, dt);

    while (iterout<=fsiiterout) // fsi coupling

	computeTimeStep(dt); // the fluid calculations
	computeForces(forces);
	
	precice.writeBlockVectorData(forceID, vertexSize, vertexIDs, forces);

   		precice.readBlockVectorData(displID, vertexSize, vertexIDs, displacements);
	setDisplacements(displacements);

	if(precice.isActionRequired(cowic)){
		precice.fulfilledAction(cowic);
        }

        precice_dt = precice.advance(dt);

	precice.readBlockVectorData(displID, vertexSize, vertexIDs, displacements);
	setDisplacements(displacements);

	if(precice.isActionRequired(cowic)){
		precice.fulfilledAction(cowic);
        }
	if(precice.isActionRequired(coric)){ // timestep not converged
		precice.fulfilledAction(coric);
	}
	else{ // timestep converged
		endTimeStep(); // e.g. update variables, increment time
                 iterout = ifsiiterout  // out the fsi cycle
	}
 }

}

The principal differences are the order of the calling to the process, and in FASTEST we have an extra cycle to make the fsi coupling (because this was the way to work with mppci).

Do you think that it is necessary to modify in order to use the parallel coupling and the extrapolation?

I modified the adapter as the wiki example and I eliminated the 'while for the fsi coupling'. But now the time step increase with every fsi iteration. then my questions are:
Is it necessary to do the 'while fsi coupling' ?
Is it important to read the displacement before to calculate the fluid?

Calculix OpenFoam Flow Coupling

Hi,
How to run a flow (compressible and in-compressible) problem using OpenFoam and Calculix. I need to run https://github.com/precice/precice/wiki/FSI-tutorial this example case using OpenFoam and Calculix.

It seems like CHT solver only available for openfoam & calculix coupling?

Socket Communication error

Hello,

i have installed SU2 and Calculix as well as Precice with the corresponding modules. The testcases for precice run all of them as well as SU2 CFD simulation testcases and Calculix solver.

Running the FSI Tutorial results to a socket communication error.
Calculix.txt

Can anyone give me idea why it's not working?

Best regards

FSI with CalculiX requires CGX (can we get rid of it?)

For the FSI tutorials with OpenFOAM and CalculiX (and potentially other), we require that the user already has CGX installed. This is not very difficult (it is, I find, easier than CalculiX, there are even prebuilt binaries), but it still is one additional piece of software.

Can we already provide the case prepared, so that the user does not have to install CGX as well?

Systemtest nutils-OpenFOAM fails

Lately, the nutils-of test is crashing due to an error in the nutils participant:

nutils-adapter            | Traceback (most recent call last):
nutils-adapter            |   File "cht.py", line 132, in <module>
nutils-adapter            |     nutils.cli.run(main)
nutils-adapter            | AttributeError: module 'nutils' has no attribute 'cli'

whereby the error refers to the develop version of cht.py.

Notably, the systemtest currently always uses the newest version of nutils, and the first occurence of the error coincides with the release of nutils v6 and development start of nutils v7.

Related issue on systemtests: precice/systemtests#219

HT/FE-FE: Compute normal heat flux in a general way

tutorials/HT/partitioned-heat/fenics-fenics/heat.py

Lines 202 to 204 in bf13fc2

	flux_x, flux_y = flux.split()
	if domain_part is DomainPart.RIGHT:
	flux_x = -1 * flux_x

The code above is a hack for computing the normal heat flux (flux times normal) from the vector values heat flux flux. Obviously, this approach only works for the case with a vertical coupling interface. We should instead use the scalar product of flux and the face normal for flux computation.

FSI SU2-CalculiX tutorial: parallel version needed

At the end of the tutorial, it would be good to have a description, as well as ready-to-run configuration files for running the tutorial in parallel.

This could be a useful benchmark for debugging, especially when somedoby starts from the tutorial in order to build something else.

Todo:

• Provide a parallel version of the configuration file.
• Describe the changes in CalculiX.
• Decsribe the changes in SU2.

Reproduce results from Vynnycky for flow-over-plate tutorial

As described in [1], we currently cannot reproduce the results from the Vynnycky paper [2] with the flow-over-plate tutorial. Comparing the measurements of our simulation with the results from [2] gives the following plot:

The main conclusion from [1] is the following: Coupling buoyantPimpleFoam with laplacianFoam (OF-OF) gives similar results as coupling buoyantPimpleFoam with FEniCS (OF-FE). However, both results do not agree with the reference results from [2] (Vynnycky).

More details and possibly helpful scripts can be found here (e.g. case files, simulation parameters, plotting scripts).

The main open questions are the following:

How to choose the temperature of the plate and at the inflow?

There are no numbers given in [2]. However, the results strongly depend on the temperatures used. And they are not independend, as the non-dimensional parameter theta suggests.

How to choose boundary conditions and geometry?

The geometry used for obtaining the results from above is not in agreement with the geometry from the Vynnycky paper. A comparison of both geometries and boundary conditions being used is given in [1, sl. 17]. Refer to [1, sl. 20] for results using the actual geometry from [2]. However, even if we use the correct geometry, we do not obtain the reference solution.

References

[1] B. Rüth, P. Meisrimel, P. Birken, G. Chourdakis and B. Uekermann: Using FEniCS and OpenFOAM for the simulation of conjugate heat transfer in a partitioned fashion, In 90th GAMM Annual Meeting, 2019.
[2] Vynnycky, M., et al. (1998). Forced convection heat transfer from a flat plate: the conjugate problem.

elastic-tube-1d: Python version needs considerably more iterations than C++ version

Observation by @fsimonis (precice/precice#657 (comment)):

1D-ElasticTube Python runs in serial, ~20x slower than C++ on my system.

This looks like there is an bug in the python tube (or at least something is not implemented in the optimal way). The number of iterations needed by the python elastic tube is much higher than for the C++ version. We should try to find the reason for the difference in performance.

sys command from pre-compiled cgx waiting for user input

For the OF-Calculix tutorial flap_perp it happens that if we download the pre-compiled cgx from Calculix page, the binary is precompiled with the flag ALLOW_SYS_FLAG 0; therefore, it requires user input for executing the system commands (this is so to avoid a catastrophe if the fbd file is evil) and therefore the execution of the solid stage is paused indefinitely. I think it could be useful to make clear in the tutorials that to accept the execution of every future 'sys'
command it necessary to add "ALLOW_SYS" in the .cgx file in the $HOME directory.

Restructure 2D/3D tutorials

We currently have the following structure in subfolder FSI:

│   ├── 3D_Tube
│   │   └── OpenFOAM-CalculiX
│   ├── cylinderFlap
│   │   ├── OpenFOAM-CalculiX
│   │   ├── OpenFOAM-deal.II
│   │   └── OpenFOAM-FEniCS
│   ├── cylinderFlap_2D
│   │   └── OpenFOAM-deal.II
│   ├── flap_perp
│   │   ├── OpenFOAM-CalculiX
│   │   ├── OpenFOAM-deal.II
│   │   ├── OpenFOAM-FEniCS
│   │   └── SU2-CalculiX
│   └── flap_perp_2D
│   └── OpenFOAM-deal.II

Wouldn't this be better?

│ ├── 3D_Tube
│ │ └── OpenFOAM-CalculiX
│ ├── cylinderFlap
│ │ ├── OpenFOAM-CalculiX
│ │ ├── OpenFOAM-deal.II_2D
│ │ ├── OpenFOAM-deal.II_3D
│ │ └── OpenFOAM-FEniCS
│ ├── flap_perp
│ │ ├── OpenFOAM-CalculiX
│ │ ├── OpenFOAM-deal.II_2D
│ │ ├── OpenFOAM-deal.II_3D
│ │ ├── OpenFOAM-FEniCS
│ │ └── SU2-CalculiX

Rename post-processing to acceleration

We renamed the post-processing configuration tags to acceleration in precice/precice#482.

We have to update the configuration files of the tutorials. Fix is prepared in #60