Using preCICE with non-Euclidean geometry

Using preCICE
1

We are investigating whether preCICE can couple our shallow water hydrodynamics solver to a wave simulator. Both of these models support either meshes with cartesian x/y positions or meshes with spherical longitude/latitude positions. The current coupler uses the Earth Systems Modeling Framework (ESMF) to regrid between the two grids, which has options for spherical (default) or cartesian coordinate systems. In our first test setup, we use preCICE’s volume coupling for the cartesian situation.

  1. We are under the impression that preCICE does not support non-cartesian coordinate systems, is that correct? Or is there a preCICE remapping method that does not assume an underlying Euclidean geometry?
  2. To solve this issue, do we need to convert the coordinates in both adapters by embedding the sphere in 3D (x,y,z) coordinates? Which remapping methods would we be able to use?
2

We have worked on a similar problem setup. However, as we are still waiting for our preprint to be published, we cannot link that yet. Will provide an update when it becomes available.

Yes, that is also our understanding. Non-cartesian coordinate systems can also be mapped, but will not receive any special treatment, thus accuracy at the poles and mesh “seam” location will likely degrade.

Yes, exactly. Towards the 3D embedding we utilized the PROJ lib ( PROJ ), as it was simple to set up and highly performant. Afterwards, all 3D remapping methods should be usable (nearest-neighbor-types, nearest-projection, rbf-types)

Using nearest-neighbor should be a good first test. Something in the lines of:

<mapping:nearest-neighbor direction="read" from="SWE" to="Wave" constraint="consistent"/>

Nearest-projection, should achieve better results, but is more troublesome to set up. For this, connectivity information (faces/edges) on the source mesh must be made available.

<mapping:nearest-projection direction="read" from="SWE" to="Wave" constraint="consistent"/>

RBF should have the highest accuracy when the mapped quantities are “smooth” enough functions. If not, then performance should be similar to nearest-projection. However, it does not require connectivity information. A generally well performing option, should be rbf-pum-direct.

<mapping:rbf-pum-direct relative-overlap="0.15" vertices-per-cluster="50" constraint="consistent" direction="read" from="SWE" polynomial="separate" to="Wave" project-to-input="1">
      <basis-function:compact-polynomial-c6 support-radius="RADIUS"/>
</mapping:rbf-pum-direct>

RADIUS might need to be fine tuned, but should work if it has 5 to 10 or more cell lengths.

I’ll gladly answer further follow up questions.

3 Likes
3

Thank you, it is encouraging to hear that it works for your setup! We already use PROJ in parts of our project, so that was also our prime candidate for these coordinate transformations.

We tried out the linear-cell-interpolation for our first cartesian coordinates, for which we specified the 2D mesh connectivity using triangles. I understand from the documentation that 3D requires tetrahedra for that. Perhaps it is as simple as extending all triangles with the center of the sphere to create a set of tetrahedra, but it may break some of the conservative constraints if some of the quantities end up at the center.

It’s interesting that radial basis functions do not require the grid connectivity, we should look into that

4

Based on our understanding, only volumetric 3D coupling requires tetrahedra, i.e., the domain also contains coupling vertices in the inner region of the mesh. For your case, assuming coupling data only exists on the surface of the ellipsoid, surface connectivity should be sufficient.

5

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.

6

preprint is on arXiv: [2512.10724] Evaluation of preCICE (version 3.3.0) in an Earth System Model Regridding Benchmark now :blush:

3 Likes
7

And now also on EGUsphere, where everyone can start or join a discussion.

1 Like