Data mapping for 3D volume coupling

Trying to achieve a volume coupling between solver A (in-house code) and B (from OpenFOAM). Data is mapped from A to B as follows:

<participant name="B">
       ... ...
       <mapping:*** direction="read" from="A-mesh" to="B-Mesh" constraint="consistent" />
</participant>

<participant name="A">
        ... ...
</participant>

Here the A-mesh is a 3D cubic in shape and meshed by a non-uniform structured grid, as shown below:


A part of the vertices have been filtered out by precice since they have no influence on the mapping.
And the B-mesh is like below:

When they are put together (blue A, gray B):

Simulation runs smoothly use “nearest-neighbor”, but when trying rbf I get the error like (changing support-radius won’t help):

[fdgs04-ws:70686] [17] terminate called after throwing an instance of 'precice::Error'
  what():  The interpolation matrix of the RBF mapping from mesh "A-Mesh" to mesh "B-Mesh" is not invertable. This means that the mapping problem is not well-posed. Please check if your coupling meshes are correct (e.g. no vertices are duplicated) or reconfigure your basis-function (e.g. reduce the support-radius).

Could you please advise how to solve this? If using RBF in my volume coupling case is not easy, I would also like to try the “linear-cell-interpolation”. But now I will have to provide the mesh connectivity for A-mesh if I’m correct. Could you please adivse me how to do this? The online help documents cover defining the 2D connectivity but 3D. Thanks a lot!

To add up, the in-house solver A can only provide the IDs and coordinates of the vertices. No native mesh connectivity (such as faces, cells) is available.

managed to build the tetrahedral connectivity for A-mesh, compilation passed with no issue, but received a link error:

this line:
CALL precicef_set_tetrahedron(mName, tetVert(1), tetVert(2), tetVert(3), tetVert(4), 20)
undefined reference to `precicef_set_tetrahedron_'

Have checked the Fortran binding interface file precice.f90 the subroutine is there:

    subroutine precicef_set_tetrahedron(meshName, firstVertexID, secondVertexID, &
      &                                 thirdVertexID, fourthVertexID, &
      &                                 meshNameLength) &
      &  bind(c, name='precicef_set_tetrahedron_')

      use, intrinsic :: iso_c_binding
      character(kind=c_char), dimension(*) :: meshName
      integer(kind=c_int) :: firstVertexID
      integer(kind=c_int) :: secondVertexID
      integer(kind=c_int) :: thirdVertexID
      integer(kind=c_int) :: fourthVertexID
      integer(kind=c_int), value :: meshNameLength
    end subroutine precicef_set_tetrahedron

Why is this error?

Found out that only the bulk versions of these functions are available in the PreCICE v3.1.2.

1 Like

Wondering why have to define the 3D volume connectivity using tetrahedrons. Using hexahedrons can reduce significantly the complexities of the peocess.

That’s true, but reliably handling the complexity in preCICE is also tricky. Read more in this issue:

You don’t need the solver to provide mesh connectivity already. This is what preCICE constructs for you, if you pass it some IDs and coordinates. Read more in the respective documentation page:

Thanks, from what I understand, for some mappings(such as linear-cell-interpolation), I don’t have to provide the hierarchical elements such as edges, but still need to define the list of tetrahedrons for my own mesh and pass it to PreCICE. Please correct me if I’m wrong.

Whenever the documentation is not enough, you might find more insights in the integration tests (search for the API method or the configuration tag that you want in the code, under the tests/ folder). For example:

Yes, if possible, please use preCICE v3, and always the latest one. It should be trivial to upgrade as long as you stay in the same major version (e.g., from v3.1.2 to the upcoming v3.2.0), since we use semantic versioning. For upgrading between major versions, we publish detailed porting guides.

This changed from v2 to v3: Previously, you had to define edges to be able to define triangles. Now, you can (actually, you have to) define triangles directly from vertices.

I hope I answered everything already open.

How did you change the support radius configuration? Do you have an idea of how many vertices you cover within the support radius configuration? Do you have any way to assure that vertices are unique within your global domain (i.e. also across ranks)?

I have already built up 3D tetrahedral connectivity for my A-mesh and invoked the configure function as follows:

CALL precicef_set_mesh_tetrahedra(mName, numberOfTetra, ids(:), 20)

The function call finished with no error message. But during execution, I received the following warning msg from participant B:

---[precice] WARNING: 3D Mesh "A-Mesh" does not contain tetrahedra, edges or triangles. Linear cell interpolation falls back to nearest-neighbor mapping.

What might be the problem? Thanks.

Can you upload the respective code (at least till that point) and the respective logs?

There’s a bug in constructing the tetra list. Now everything’s good and linear-cell-interpolation is working fine.

Dear developers,

Now the 3D volume coupling with tetrahedral connectivity runs and seems no error. But still got the following warnings in the log file, please advise if there’s something wrong? How should I understand the meaning of the fallback statistics? Thanks.

---[precice] e[0m Linear Cell Interpolation is used, but some points from HOS-Relaxation-Mesh1 don't lie in the domain defined by the tetrahedra. These points have been projected on the domain boundary. This could come from non-matching discrete geometries or erroneous connectivity information.If distances seem too large, please check your mesh. The fallback statistics are: min:4.42015e-07 max:0.0101352 avg: 0.00160332 var: 2.35432e-06 cnt: 16220 
---[precice] e[36mWARNING: e[0m 1124955 of 1588040 vertices of mesh HOS-Relaxation-Mesh1 have been filtered out since they have no influence on the mapping.

Here’s the exported mesh: (gray mesh with tetrahedrons : from mesh, blue dots: to mesh). I wonder why some tetrahedrons are missing on the from mesh, is it due to the filtering of PreCICE when building the mapping?