I understand that there is a “global data” functionality, which enables non-mesh data communication between participants.
However, I’m wondering if it’s possible to exchange initialization data before creating the coupling meshes, since their construction depends on this initial data. While I could manually write this data into the respective input files, that approach would be tedious and should only be a last resort.
Makis
April 9, 2025, 6:39am
2
@Ya_Squall this is something in our radar since longer, but currently still open:
opened 09:19AM - 22 Nov 18 UTC
enhancement
low priority
For several applications users asked about sending global data, meaning data tha… t is not associated to a mesh. Examples:
* Angles between coordinate systems (CAMRAD-CFD)
* Global background pressure (fluid-acoustic coupling)
* Others that I forgot
Note: We have previously referred to this kind of data as meta data. In the end, I am not too happy with this expression as it let to confusion (exchanging strings, integers etc.). What I had in mind are physical values, thus floating point values only.
# User perspective
## Configuration
```xml
<solver-interface dimensions="2">
<data:scalar name="ClassicalMeshData"/>
<global-data:scalar name="GlobalData1"/>
<global-data:vector name="GlobalData2"/>
<mesh name="MeshName">
<use-data name="ClassicalMeshData"/>
</mesh>
<participant name="SolverName">
<use-mesh name="MeshName" provide="yes"/>
<write-data name="ClassicalMeshData" mesh="MeshName"/>
<write-data name="GlobalData1"/>
<read-data name="GlobalData2"/>
</participant>
<coupling-scheme:parallel-implicit>
<participants first="SolverName" second="..."/>
...
<exchange data="ClassicalMeshData" mesh="MeshName" from="SolverName" to="..."/>
<exchange data="GlobalData1" from="SolverName" to="..."/>
<exchange data="GlobalData2" from="..." to="SolverName"/>
...
<post-processing:IQN-ILS>
<data name="ClassicalMeshData" mesh="MeshName"/>
<data name="GlobalData1"/>
...
</post-processing:IQN-ILS>
</coupling-scheme:parallel-implicit>
```
## API
```c++
int getDataID ( const std::string& dataName ); // use same function name if possible
void setGlobalDataSize (
int dataID,
int size,
int* globalDataIDs );
// similar functions for reading and for scalar data
void writeGlobalVectorData (
int dataID,
int size,
int* globalDataIDs,
double* values );
```
I am not sure if we can avoid having sth like the above `setGlobalDataSize`. If we make this data structure completely dynamic, undefined behavior can appear. For instance, what happens if within one subcycled timestep two different sizes are given? Which one will be used? I currently also don't see a use-case where a completely dynamic size would be necessary (which does not mean that there isn't).
## Communication behavior
* Writing should be allowed on any rank. If data is written on multiple ranks, preCICE checks for consistency.
* On every reading rank, the same data is available
# Developer perspective
## Communication
* Gather on all writing ranks to master and check for consistency. This cannot be a debug-only feature, since we need to figure out either way on which rank data was written
* Send from master to master and broadcast
## WIP: Data structures and random thoughts
* New class `GlobalData` (in which package?? `mesh` would obviously lead to misunderstandings, probably a new package is needed)
* Do we need a `GlobalDataContext`? Maybe not
* Participant gets `_writeGlobalDataContexts` and `_readGlobalDataContexts` (or directly `_readGlobalDatas` or similar)
* How do we treat global data in `CouplingData`? New similar data structure? This has consequences in `_sendData` in `BaseCouplingScheme`
* How do we distinguish between the two send operations, normal m2n send and global data send in `M2N`, compare how sending the timestep size is currently handled
We have had a first approach to implement this, but the codebase has diverged since, but we wanted to revisit it at some point.
What would your use case be?
Mesh-free data exchange during the preCICE initialization stage (i.e., not during the call to advance) is extremely valuable, offering users significant flexibility in designing the coupling interface. In my case, coupling OpenFOAM with HOS, both parties require preliminary information from one another before configuring the coupling mesh. For OpenFOAM, this information includes the number of HOS grid nodes in the x and y directions, as well as the overall HOS domain size. On the HOS side, the necessary data comprises the boundBox of the embedded OpenFOAM domains.