Model solver data names in adapter schema

[uekerman]

For some solvers, it seems that the current write_data_names and read_data_names are not sufficient. On top, another name field is needed to identify the data field within the solver.

Option A: Specify solver name in config

{
  "participant_name": "Fluid",
  "precice_config_file_name": "../precice-config.xml",
  "interfaces": [
    {
      "mesh_name": "Fluid-Mesh",
      "write_data": [
        {
         "name": "Temperature"
         "solver_name": "temp"
        },
        {
         "name": "Velocity"
         "solver_name": "v"
        }
      ],
      "read_data": [
        {
         "name": "Heat-Flux"
         "solver_name": "flux"
        }
      ]
    }
  ]
}

solver_name could be optional.

Option B: Hard-code solver name in adapter

This is how we currently handle things in the OpenFOAM adapter, for example.

if read_data_name.starts_with("Temperature"):
    solver_name = "temp"

Connected issues, PRs, and examples:

• DuMuX: Configure the adapter with a YAML or JSON configuration file dumux-adapter#40 @mathiskelm @IshaanDesai
• Elmer: Improve usability w.r.t Elmer vs. preCICE data names elmer-adapter#6 @tapegoji @BenjaminRodenberg
• OpenFOAM: General Read Write module openfoam-adapter#346 @vidulejs @MakisH
• ISSM: https://git.rwth-aachen.de/terrabyte-dnn2sim/issm-precice/-/blob/main/examples/ex1/data/issm-precice.yaml?ref_type=heads @dabele

[vidulejs]

Hi, I was just about to write up this issue. Actually, there is one more thing I want to add / discuss (let me know if I should open a different issue for this). Namely, the adapterDataType or adapterDataOperationentry in this example preciceDict. The general read-write module for OpenFOAM might require this entry, to determine whether I want to write the value or the gradient, i.e., surface normal gradient for boundary patches.

interfaces
{
  Interface1
  {
    mesh              Fluid-Mesh;
    locations         faceCenters; // faceNodes | volumeCenters;
    connectivity      false; // true;
    patches           (interface);
    // cellSets          (all);

    readData
    ( 
      {
        preciceDataName       Temperature;  // preCICE data name
        adapterDataName       T;            // OF field name
        adapterDataType       value;        // ['value' | 'gradient']
      }
    );

    writeData
    (
      {
        preciceDataName       Heat-Flux;
        adapterDataName       T;
        adapterDataType       gradient;
      }
    );
  };
};

Alternatively, we can infer the operation from the preciceDataName, for example, by appending some string like -Gradient.

Why is this needed?

For example, a mixed boundary condition (and other derived BCs) requires both the value and the surface normal derivative. OpenFOAM provides methods to get or set either of them: refValue() and refGrad().

Heat flux is not a separate field in OpenFOAM, but it is in preCICE. Right now it's hard coded, because we know that Heat-Flux corresponds to the surface normal gradient of temperature times conductivity.

std::size_t preciceAdapter::CHT::HeatFlux::write(double* buffer, bool meshConnectivity, const unsigned int dim)
{
    int bufferIndex = 0;

    for (uint j = 0; j < patchIDs_.size(); j++)
    {
        int patchID = patchIDs_.at(j);

        const scalarField gradientPatch(
            (T_->boundaryField()[patchID])
                .snGrad());
   // [...]

[MakisH]

If we distinguish between:

• preciceDataName (required)
• adapterDataName (optional?)
• adapterDataType (optional)
• adapterDataOperation (optional)

then these would be generic and useful fields we could reuse in other adapters, no?

Probably the adapterDataType and adapterDataOperation would not be defined consistently across adapters, but for the adapters that need something like this, we provide a specific way to do provide this information.

I have the feeling that if we had this information, our adapters could also be simplified, as some of the hard-coded cases would be offloaded to the user (or the config generator).

[uekerman]

@MakisH adapterDataType == adapterDataOperation or am I getting this wrong?

[MakisH]

@MakisH adapterDataType == adapterDataOperation or am I getting this wrong?

Yes, these could be the same. The operation could be a value, gradient, or something more elaborate, like the name of a function to call. We could then process this in if statements and act accordingly.

[tapegoji]

I personally, like idea A to specify in the config file rather than hard-coding it. Elmer adapter then can be designed to be variable agnostic and let the translation happen in the .xml config file.

[IshaanDesai]

I am tending towards option A rather than B. We would need something like this for adapters of commercial software too.

[BenjaminRodenberg]

Is there not a very similar situation for meshes as well?

In the OpenFOAM there is a 1-to-1 connection between Interface1 and Fluid-Mesh. Interface1 looks to me like an OpenFOAM adapter implementation detail while Fluid-Mesh is the name coming from the preCICE configuration.

interfaces
{
  Interface1
  {
    mesh              Fluid-Mesh;
    ...
  };
};

should become

interfaces
(
  {
    preciceMeshName   Fluid-Mesh;
    adapterMeshName   Interface1;
    ...
  };
);

(I'm not sure if I'm using the different kinds of brackets correctly but I'm assuming (...) is a set or list while {...} is a dictionary)

[uekerman]

IIRC, "Interface1" is a name that is actually never used in the OpenFOAM adapter.

We currently have in the schema:

"patches": {
  "type": "array",
  "description": "List of mesh or geometry patches (boundary or volume) to locate the interface.",
  "items": {
    "type": "string",
    "minLength": 1
  },
  "minItems": 1
},
"location": {
  "type": "string",
  "description": "Further specification of mesh locations",
  "minLength": 1,
  "examples": [
    "faceCenters",
    "volumeCenters",
    "faceNodes",
    "nodes"
  ]
}

"patches" and "location" came originally from the OpenFOAM adapter, but are general IMO.
"patches" are typically not names, but some sort of IDs coming from a meshing tool. "location" is some further description that the adapter needs to decide what to do with the mesh.

[MakisH]

The first implementation of the configuration of the OpenFOAM adapter was in YAML, where we had something like:

interfaces:
- mesh: Fluid-Mesh
  patches: [interface]
  write-date: Temperature
  read-data: Heat-Flux

as already used in other adapters at the time. YAML offers lists, and that's why we used that.

We then converted the format to a dictionary (precice/openfoam-adapter#105), that defines a list of dictionaries as interfaces. The related restriction from that PR description:

Dictionaries always need a name, but for the different interfaces (e.g. Interface1, Interface2) it can be arbitrary and is not used anywhere.

I am not aware of examples where the name of the dictionary is actually used or how it could be read. I think it might even have some strict naming rules. @vidulejs could you please do some research on this?

I agree that the Interface1 looks odd, but I would also argue that it is a different thing and should not necessarily be coupled. It just happens that we assume "one interface means one preCICE mesh".