Just out: Release v2.4.0 · precice/precice · GitHub
As usual, we fixed quite a few bugs. We mention an important fix below. This alone should already be incentive enough to upgrade … but, of course, we also have a few new handy features:
New export variants
The export functionality now supports many more data formats:
<export:csv />
(new) (Add CSV exporter by fsimonis · Pull Request #1144 · precice/precice · GitHub)<export:vtp />
(new) (VTP exporter by fsimonis · Pull Request #1137 · precice/precice · GitHub)<export:vtu />
(new) (Add VTU exporter by fsimonis · Pull Request #1136 · precice/precice · GitHub)<export:vtk />
The csv data, you can for example import to any Python script with pandas:
def loadParallelCSV(name):
import glob, pandas
return pandas.concat([pandas.read_csv(name, sep=";") for name in glob.glob(f"{name}_*.csv")], ignore_index=True)
def loadParallelCSVSeries(name)
import re, glob, pandas
l = [(re.search("dt(\d+)_", s).group(1), s) for s in glob.glob(f"{name}.dt*_*.csv")]
retrun pandas.concat([pandas.read_csv(file, sep=";").assign(dt=dt) for dt, file in l], ignore_index=True)
pointData = loadParallelCSV("A-ExporterTwo.dt1")
pointDataSeries = loadParallelCSVSeries("A-ExporterTwo")
Introducing precice-tools
We renamed binprecice
to precice-tools
(the old name is still usable till preCICE v3.0) and added some additional functionality:
precice-tools check precice-config.xml
… lets you check the correctness of a given configuration file (Configuration Checker by fsimonis · Pull Request #1132 · precice/precice · GitHub).precice-tools version
… prints the version of the used preCICE library. (Add tooling API by fsimonis · Pull Request #1122 · precice/precice · GitHub)
Building
We added a few small details that should make your and our lives easier:
- New CMake options
PRECICE_RELEASE_WITH_DEBUG_LOG
,PRECICE_RELEASE_WITH_ASSERTIONS
, andPRECICE_RELEASE_WITH_TRACE_LOG
to switch on Debug logging, assertions, and Trace logging, respectively when in Release mode (all CMake options). This is useful for debugging preCICE with larger test cases, especially when dealing with connectivity . - A pkg-config file for using preCICE directly from the build directory. (Add pkg-config file for binary directory by fsimonis · Pull Request #1238 · precice/precice · GitHub) – very handy for adapter developers who rely on pkg-config and develop versions of preCICE. Simply add the build directory to the
PKG_CONFIG_PATH
environment variable after setting upLD_LIBRARY_PATH
.
We also added tooling shortcuts to CMake, which simplify contributing:
make doxygen
: Generate doxygen documentationmake format
: Format the codebase (requires local install of the correct version of clang-format)make soucesIndex
: Update the CMake source indexmake changelog
: Add changelog entry using the GitHub PR number
Dependencies
With the new Ubuntu LTS release 22.04, we drop the support of the oldest LTS, namely Ubuntu 18.04 LTS, making Ubuntu 20.04 LTS the new baseline. This means, preCICE now requires Boost version 1.71.0
and CMake version 3.16.3
(Lift baseline from Ubuntu 18.04 LTS to 20.04 LTS by fsimonis · Pull Request #1259 · precice/precice · GitHub). We are now actively investigating a possible move to C++17.
Nearest-neighbor gradient mapping (still experimental)
We added a new mapping method nearest-neighbor-gradient
(Added API Methods for writing the gradient data needed for Nearest Neighbor Gradient Mapping by ariguiba · Pull Request #1169 · precice/precice · GitHub), which was implemented, tested, and documented as part of the bachelor’s thesis of @ariguiba. Users can now give gradients of data to preCICE and get a second-order mapping method this way.
writeScalarGradientData(int dataID, int valueIndex, const double* gradientValues)
Compared to the nearest-projection
mapping, no connectivity is required (but gradient data). First tests with ASTE showed very promising results. See all new API methods and a full code example.
Time interpolation (still experimental)
Time interpolation is a topic we are working on since longer, see for example the paper on quasi-Newton waveform iteration from last year:
Rüth, B., Uekermann, B., Mehl, M., Birken, P., Monge, A. and Bungartz, H.J., 2021. Quasi‐Newton waveform iteration for partitioned surface‐coupled multiphysics applications. International Journal for Numerical Methods in Engineering, 122(19), pp.5236-5257. https://doi.org/10.1002/nme.6443
We now merged and released a first larger chunk of functionality. We now have linear interpolation in time, but still restricted to parallel-implicit coupling.
Switch it on:
<solver-interface experimental="true" ... >
...
<participant name="FluidSolver">
<use-mesh name="FluidMesh" provide="yes"/>
<write-data name="Forces" mesh="MyMesh"/>
<read-data name="Displacements" mesh="FluidMesh" waveform-order="1"/>
</participant>
...
</solver-interface>
… and then read data whereever (in time) you want:
void readBlockVectorData(int dataID, int size, const int* valueIndices,
double relativeReadTime, double* values) const;
Everything is still experimental – use with care. To find out more and stay up to date, have a look at the full documentation
Julia bindings
Probably worth mentioning, we recently also added bindings for Julia: GitHub - precice/PreCICE.jl: Julia language bindings for preCICE . We also added them to the Julia General Package Registry so that they should be easy to install. To test the bindings, you could then run the example solverdummy code.
Bug in socket communication
We finally discovered the root course of a rare and difficult to reproduce bug in the sockets communication back-end. A race condition in the send queue led to crashes in send-intensive situations. This was observed in cases that explicitly enable the gather-scatter algorithm in communications using: <m2n:sockets enforce-gather-scatter="true" ... />
. Furthermore, this could be observable in uni-directional coupling, especially if the sending participant finishes time-windows faster than the receiving participant.
Even more
-
We added
support-radius
as additional configuration option for Gaussian RBF mapping configuration (https://github.com/precice/precice/pull/1163). -
We are slowly working towards supporting multiple instances of
SolverInterface
at the same time. We are not there yet, but fixed many relevant problems. See project overview. -
We, finally, got rid of the master and slave nomenclature. In the code base, we now distinguish between one primary and many secondary ranks. The geometric filters accordingly are called
on-primary-rank
andon-secondary-ranks
. The intra-participant communication (previously master communication) can now be configured like this:<participant name="MySolver"> ... <intra-comm:sockets/> ... </participant>
When do I need an intra-participant communication?
Of course, all previous configuration options are still supported till preCICE v3.0
-
Retirement: We deprecated the API functions
mapWriteDataFrom
andmapReadDataTo
and will retire them with preCICE v3.0. More deprecations are currently discussed. Feel free to comment under:
We definitely forgot something in this list, but anyway, enough reasons to upgrade right now!