“Two friends walk into a (virtual) bar:
– How do you know that exactly six months have passed since the last time we met?
– I know because 
(drum rolls) a new preCICE release is out!”
preCICE v2.2.0 is here, it is fresh, it comes with new features and many bug fixes, and it is easy to upgrade! Let’s have a look at some highlights.
1. New features
1.1. Multiple mappings to and from a mesh
There are cases when you may want to read/write data from one mesh to multiple meshes, such as in this topic by @ajaust. This is an example configuration:
<mesh name="MeshB">
<use-data name="Pressure" />
</mesh>
<mesh name="MeshATop">
<use-data name="Pressure" />
</mesh>
<mesh name="MeshABottom">
<use-data name="Pressure" />
</mesh>
<participant name="A">
<use-mesh name="MeshATop" provide="yes"/>
<use-mesh name="MeshABottom" provide="yes"/>
<use-mesh name="MeshB" from="B"/>
<read-data name="Pressure" mesh="MeshATop"/>
<read-data name="Pressure" mesh="MeshABottom"/>
<mapping:nearest-neighbor direction="read" from="MeshB"
to="MeshATop" constraint="consistent" />
<mapping:nearest-neighbor direction="read" from="MeshB"
to="MeshABottom" constraint="consistent" />
</participant>
Note here the two mapping with from="MeshB". Previously, this would lead to an error. This functionality is now supported, allowing for an arbitrary number of mappings to/from a single mesh.
For more details, see PR #849.
1.2. Watch integral
You may already know that you can set watchpoints to track values on the preCICE coupling meshes.
You can now also set watch integrals, which allow to track integral values. Common use cases could be:
- Determining the total force on a geometry in an FSI simulation.
- Determining the flow rate for a fluid-fluid coupling.
When no mesh connectivity is given, the watch integral is simply the sum of all values on the respective mesh. When mesh connectivity is given, the watch integral is the sum weighted by the area. There is an option to switch of the weighting if not required (e.g. for force values).
For more details, look at the documentation and at PR #881.
2. Maintainability and compatibility
2.1. Updated dependency support and C++14
We do our best to keep preCICE easy to work with older systems, even if this means we cannot use all the language features we dream of. At the same time, we pledge to support the latest versions of all our dependencies.
Boost Geometry raised their C++ standard requirement to C++14 in Boost 1.75, so we (finally) had a good reason to move from C++11 to C++14 as well. We already started by formally (and in C++14 way) [[deprecated]]-ing some old API methods, so if you see such a compile-time warning, please follow the suggestions and update your adapters. We want to use more C++14 features in next releases to make the codebase more maintainable, but the important part is that the compiler requirements do not change much for you.
This should also make preCICE work again by default with the latest dependencies on Spack and Arch Linux.
2.2. Better support for MPI implementations
We fixed a few issues with MPI, particularly affecting the Intel MPI and more. For one, we don’t see any strange behavior when using MPICH. Read more in PR #944 and issue #746.
2.3. First release to fully support macOS, with Windows coming next
We did a lot of progress on supporting more platforms. Even if you are only using Linux, this journey is important because it makes us discover improvements that can make preCICE more maintainable and which would give more freedom to our users to choose their operating systems.
This is the first release to fully support macOS. Since our macOS users are very few, any feedback (even just positive) from you would be very valuable. 
Simply reply to this post. By the way, getting preCICE via Spack also works on macOS.
Next step for us is to support Windows natively. Again, your help and feedback here is very welcome. And by the way, have you seen that @rafal added a preCICE package to the MinGW msys2 repository? For those of you using WSL, this also already works.
3. Bugfixes and other improvements
3.1. Residual-sum preconditioner
When using the residual-sum preconditioner, it was previously possible to run into the following error:
A sub-vector in the residual-sum preconditioner became numerically zero
This occurred in scenarios where the output of at least one solver was unchanged between two successive iterations. Now, in the case where one or all sub-vectors are zero, the preconditioner scaling factors are no longer calculated, and the scaling factors from the previous iteration are simply used. For the very first iteration, the scaling factors are initialized to 1.0.
3.2. Better PETSc finding
PETSc generates a pkgconfig file and recommends this approach to packages using PETSc. We have now reworked the logic of finding PETSc, making the installation method on large HPC systems even easier and more robust.
3.3. More
As always, we fixed several less and more important bugs and additionally:
- We improved some error messages, especially for accelerated data in implicit coupling.
- The XML configuration reference now contains detailed explanations of tags and attributes.
For a more complete list of changes, have a look at the changelog.
By the way, did you already notice our redesigned website? We still have some corners to paint and some new furniture to fit, so more on that later. We will definitely want to hear from you also about that in our upcoming preCICE Workshop 2021.
