Passing internal mesh values to boundaries during volume coupling

Hello everybody,

my current question is related to my previous question (asked here: Passing face values during volume coupling ), since it is already closed I cannot continue in that thread though. Here is a visualization of my setup:

In the accepted answer, M2 writes all of the internal domain values to M1. How can I make M2 only pass values close to the boundaries of M1 to the patches of M1, so that I can use these as boundary conditions in M1? Note that I do not have boundaries in M2 close to the patches of M1. Do I have to define baffles in M2 from which I can interpolate the face values (and thereby the boundary conditions) or is there a simpler way to do this with preCICE?

Thank you for your help,

Dennis

Part of the reason why I was seeing issues was that in my simulations M1 only covered one cell of M2, increasing the domain size makes things better. It seems that the values are being passed to the boundaries now, strangely though, the values of my alpha field are only being passed to a single face per patch in M1. Could this have something to do with the interface locations being volumeCenters in M2?

What data mapping are you using? Could you export your meshes? I could imagine that looking at the actual vertices could help understanding the situation.

Thank you, this tool is very cool.

I am using nearest neighbor mapping, from the volumeCenters of M2 to the faceCenters of M1. For the alpha it is in fact only one nearest neighbor that was being mapped to due to the conservative tag I had included. When I change it to the consistent tag, the boundary is uniform, however now the M1 is getting negative alpha values. Do you know what the reason for this could be? Could the projection be an issue? Since I am passing values from within M2, (I assume) I have to use volumeCenters, but I cannot define connectivity for this, which is why I can’t move to a higher order projection method.

But I see now that even if I don’t pass the alphas and only couple the pressure, my pressure gets a strange checkerboard pattern on the internal mesh, which I assume comes from the nearest neighbor mapping.

Is it possible that only nearest-neighbor mapping is allowed for the Openfoam.org versions? I cannot do nearest-projection on boundaries.

Can’t answer the OpenFOAM question. @Makis ?
But concerning the rest, could you please upload your exports? That would help me understanding the situation.

So basically I have the following setup:

The big spheres are the volumeCenters from my macroscopic domain (M2), the values of which are nearest-neighbor mapped to the little spheres, which are faceCenters that represent the boundaries of my mesoscopic domain (M1). Coupling the simulation works in the sense that both participants run, however my internal pressure field gets a type of checkerboard pattern:

This also does not seem consistent with the boundary conditions:

Do you know what the reason for this can be? Note that for testing purposes the equations im solving on both M1 and M2 are simply Darcys law.

So, what I see:

  • The NN mapping seems to do what it should.
  • The boundary conditions also look correct.
  • The pressure you compute does not show a checkerboard pattern (that would be a mesh-dependent numerical oscillation), but not what one would expect from the boundary values.

How do you enforce the pressure boundary condition? All in all, it does not seem to be a “coupling problem”, but an issue with how you use the pressure values you read. So, more an OpenFOAM question?

Could you upload your OpenFOAM case or parts of it?

Yeah, I agree that its not a coupling issue, but more likely related to the boundary conditions. I tried to replicate similar pressure differences in my solver (only without the coupling) and get issues as well: I think its because for very small pressure differences, as I have in the images above, the pressure drop caused by the Darcy terms is also extremely small, which is difficult for the solver to handle (not entirely sure why I get the cross pattern during the coupling though). So it does not seem to be a preCICE related issue. Thank you for your help though!

If I understand this correctly, it sounds like a bug in the adapter (or a configuration issue in defining the patches). But the follow-up pictures show that all faces of the patch are updated. Is this issue still happening?

For the future reader, you are using some version of this modified adapter for OpenFOAM 6: GitHub - precice/openfoam-org-adapter at OpenFOAM6 · GitHub (please correct me/add details).

Nearest neighbor and RBF mappings are supported for all fields. Nearest-projection mappings are (in all versions of the adapter) restricted to specific fields and exchange direction. But I assume you don’t need/use NP mapping in this case.

Any further observations would be nice to see and might help.