openfoam-adapter
openfoam-adapter copied to clipboard
precice
Duplicate coupling nodes at processor interfaces for faceNodes
When running cases in parallel and a distributed interface, we currently have duplicated definition of interface nodes at processor boundaries across the coupling interface. The duplication occurs for the location faceNodes as well as . As a consequence, we cannot compute any RBF mappings in cases where the mapping is generated from the (distributed) OpenFOAM side (we had similar issues in our quasi 2D mappings). However, for faceCentersfaceNodes this won't be relevant at the moment since we only map consistent data across the faceNodes interface and the mapping needs to be executed on the other participant. As a remedy, one could choose a nearest-neighbor mapping (I guess nearest-projection works as well) or avoid the partitioning of the interface in OpenFOAM. Resolving the issue here will probably fix #40 as well/ the error is probably the same.
I was actually too fast here. The issue occurs only for the location faceNodes and I visualized the wrong meshes here (both refer to the faceNodes). In the end, I was able to successfully run my case in parallel. @MakisH should we keep it here as a low priority issue or directly close it. As described above, we currently don't have any affected cases for faceNodes.
That was also my expectation and I am not sure if we should consider this a preCICE, adapter, or OpenFOAM issue.
Could you please add a note in the adapter documentation? I guess it does make sense for 3D cases (e.g. a valve), where the domain boundary cuts the interface. I would expect this to be a relatively common issue in practice.
Could you please add a note in the adapter documentation? I guess it does make sense for 3D cases (e.g. a valve), where the domain boundary cuts the interface. I would expect this to be a relatively common issue in practice.
Are you sure? It might confuse user. Even the 3D valve would not be affected since for the 'node related' fields, i.e. displacement, the mapping is build on the solid mesh so that the duplication in the fluid mesh doesn't lead to any problems. Or am I missing something?
Let's maybe look at it the other way around: under which situation did you observe the problem? What real-world scenario would trigger it?
It's more your setup than the actual scenario. You might have a relevant duplication in case you use a 3D CHT case with nearst-projection mapping. But I guess the nearest-projection mapping doesn't care about it (similar to the NN mapping). So, there is no relevant case at the moment. A relevant case would be if we start writing 'Displacements', i.e. using a solid solver in OpenFOAM. Is this relevant?
A relevant case would be if we start writing 'Displacements', i.e. using a solid solver in OpenFOAM. Is this relevant?
Actually, there are people doing this, even if OpenFOAM is not widely used for structure simulations. See, e.g. #121 (and there have been 1-2 other preCICE users in the past).
I would still prefer to keep this corner case documented. A short entry at the bottom of the configuration page and a link to this issue would not harm.