Model solver name and operation as data properties #38

uekerman · 2025-03-04T10:03:54Z

Closes #36

Current suggestions

name, not precice_data_name as property name: "data" is covered in the object name and "precice" should be clear enough (it is also mesh_name, not precice_mesh_name)
solver_name, not adapter_name as property name: It is a name given by the solver, not the adapter if I understood the situation the right way

Also have a look at the descriptions in the schema. These will be our documentation.

Some examples

In JSON with all options:

{
  "participant_name": "Fluid",
  "precice_config_file_name": "../precice-config.xml",
  "interfaces": [
    {
      "mesh_name": "Fluid-Mesh",
      "write_data": [
        {
          "name": "Force",
          "solver_name": "f0",
          "operation": "blob"
        },
        {
          "name": "Heat-Flux",
          "solver_name": "T",
          "operation": "gradient"
        }
      ],
      "location": "volumeCenters",
      "is_received": false
    }
  ]
}

In YAML with only required options:

participant_name: Fluid
precice_config_file_name: ../precice-config.xml
interfaces:
  - mesh_name: Fluid-Mesh
    write_data:
      - name: Force

To further test the schema, I can always recommend testing with the Meta Configurator.

Review

@tapegoji @BenjaminRodenberg @mathiskelm @IshaanDesai @vidulejs @MakisH @dabele: Does this cover your requirements?
Any more example names we could add?
@Logende We could probably remove some duplication between read data and write data in the schema now, right? (Feel free to directly push to this branch)

MakisH · 2025-03-04T14:30:35Z

adapter-config-schema/preatcs.json

+                    "Velocity",
+                    "Temperature",
+                    "Heat-Flux",
+                    "Force1",


Is this something we want to give as an example and, hence, encourage it?
What was the inspiration for this example in the first place (I know it was introduced earlier)?

@tapegoji @BenjaminRodenberg @mathiskelm @IshaanDesai @vidulejs @MakisH @dabele: Does this cover your requirements?

Yes, this will do for my side.

I envision transferring Joule-Heat from Elmer to preCICE in some of the applications for Volume to Volume coupling. If we can give example for volume-to-volume coupling, it might be useful.

MakisH

* `name`, not `precice_data_name` as property name: "data" is covered in the object name and "precice" should be clear enough (it is also `mesh_name`, not `precice_mesh_name`)

Sounds clear, especially since it is the first (required) field.

* `solver_name`, not `adapter_name` as property name: It is a name given by the solver, not the adapter if I understood the situation the right way

Correct, good point.

For the example: why blob as operation?

This is as discussed, so I guess it would cover all the use cases we had in mind when proposing this distinction.

IshaanDesai · 2025-03-05T16:09:34Z

The proposed schema covers the existing requirements 👍

vidulejs · 2025-03-05T16:12:19Z

I agree with your suggestions and would just like to say a few words from my perspective.

Having a separate name and solver_name is indispensable for a 'general read-write module' in the OpenFOAM-adapter. We already have a specific config for the Fluid-Fluid module, where nameAlpha can be specified in case of a multiphase solver. Analogously in combustion solvers the species mass fractions have different unique names. And I know there are some discrepancies in field names between OF solvers.

As for the operation property, I think it is useful to have something like this. Passing an additional parameter allows to extend adapters in the future if needed. Based on the operation, the adapter calls some method of the solver (or preCICE or the adapter). In the case of OF and surface coupling I need to have the surface-normal-gradient for Neumann coupling. But I imagine there are other use cases as well. For example, multiply by a constant, convert to a different unit or calculate some derived quantity.

Logende · 2025-03-06T14:21:32Z

Alternative suggested by @BenjaminRodenberg: instead of having read and write data as a list, make it a dictionary (see #18 (comment)).

This would look like this:

in the figure, read_data uses the old array structure and write data the new dict structure.

What do you think about it? @uekerman

The schema with both using a dict:

  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "metaConfigurator": {
    "aiExportFormats": {
      "OpenFOAM": "https://github.com/precice/tutorials/blob/develop/perpendicular-flap/fluid-openfoam/system/preciceDict",
      "ISSM": "https://github.com/precice/preeco-orga/blob/main/adapter-config-schema/export-formats/issm-example.yaml"
    }
  },
  "title": "preCICE Adapter and Tooling Configuration Schema (preATCS)",
  "description": "A JSON schema for configurations of adapters and tools within the preCICE ecosystem. Use the schema for validation and LLM-based auto-conversion to other configuration languages (e.g., OpenFOAM dictionary or YAML). The schema is developed as part of the preECO standardization, see https://precice.discourse.group/t/shape-the-future-of-the-precice-ecosystem-the-preeco-project/2019.",
  "properties": {
    "participant_name": {
      "type": "string",
      "description": "Name of the participant.",
      "examples": [
        "Fluid",
        "Solid",
        "Fluid-Left"
      ],
      "minLength": 1,
      "pattern": "^[A-Z][a-zA-Z0-9-]*$"
    },
    "precice_config_file_name": {
      "type": "string",
      "description": "Path to the preCICE configuration file relative to the current working directory of the coupled solver.",
      "default": "../precice-config.xml",
      "minLength": 1,
      "pattern": "^/?(?:\\.\\./)*([a-zA-Z0-9]+(-[a-zA-Z0-9]+)*/)*[a-zA-Z0-9]+(-[a-zA-Z0-9]+)*\\.xml$"
    },
    "interfaces": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "mesh_name": {
            "type": "string",
            "description": "Name of the mesh associated with this interface.",
            "examples": [
              "Fluid-Mesh",
              "Solid-Mesh",
              "Fluid-Upstream-Mesh",
              "Fluid-Upstream-Mesh-Centers",
              "Fluid-Upstream-Mesh-Nodes"
            ],
            "minLength": 6,
            "pattern": "^[A-Z][a-zA-Z0-9]*(?:-[A-Z][a-zA-Z0-9]*)*-Mesh(?:-[A-Z][a-zA-Z0-9]*)*$"
          },
          "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"
            ]
          },
          "write_data": {
            "type": "object",
            "description": "List of data fields to be written to this mesh.",
            "minProperties": 1,
            "additionalProperties": {
              "type": "object",
              "$ref": "#/$defs/precice_data"
            }
          },
          "read_data": {
            "type": "object",
            "minProperties": 1,
            "description": "List of data fields to be read from this mesh.",
            "additionalProperties": {
              "type": "object",
              "$ref": "#/$defs/precice_data"
            }
          },
          "is_received": {
            "type": "boolean",
            "description": "Whether mesh is received from another participant for (direct) API access or not (i.e. provided)."
          }
        },
        "required": [
          "mesh_name"
        ],
        "if": {
          "properties": {
            "is_received": {
              "const": true
            }
          }
        },
        "then": {
          "not": {
            "required": [
              "location"
            ]
          }
        }
      },
      "minItems": 1
    }
  },
  "required": [
    "participant_name",
    "precice_config_file_name",
    "interfaces"
  ],
  "$defs": {
    "precice_data": {
      "type": "object",
      "properties": {
        "solver_name": {
          "type": "string",
          "description": "Name of the data as used by the solver (optional).",
          "examples": [
            "temp",
            "T"
          ],
          "minLength": 1
        },
        "operation": {
          "type": "string",
          "description": "Operation applied by the adapter on the data (optional).",
          "examples": [
            "value",
            "gradient"
          ],
          "minLength": 1
        }
      }
    }
  }
}

Note that then the user will no longer get suggestions for the read data or write data names.

uekerman · 2025-03-07T09:37:15Z

Alternative suggested by @BenjaminRodenberg: instead of having read and write data as a list, make it a dictionary (see #18 (comment)).
Note that then the user will no longer get suggestions for the read data or write data names.

This would indeed be a drawback. Similarly, we cannot check against a pattern, right?

How would it look like if we don't specify solver_name nor operation?

"Force": {}

?

Logende · 2025-03-08T21:06:51Z

Alternative suggested by @BenjaminRodenberg: instead of having read and write data as a list, make it a dictionary (see #18 (comment)).
Note that then the user will no longer get suggestions for the read data or write data names.

This would indeed be a drawback. Similarly, we cannot check against a pattern, right?

How would it look like if we don't specify solver_name nor operation?
"Force": {}
?

Yes it would look like this.
Regarding patterns: there is some way using patternProperties instead of additionalProperties but I have not fully figured it out yet. Will try it again soon.

Convert read and write data to objects

48e5cf3

uekerman self-assigned this Mar 4, 2025

uekerman added the schema Related to the adapter config schema label Mar 4, 2025

MakisH reviewed Mar 4, 2025

View reviewed changes

MakisH approved these changes Mar 4, 2025

View reviewed changes

Logende added 2 commits March 6, 2025 12:02

remove duplication

3f634fe

small fix

f7dda20

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Model solver name and operation as data properties #38

Model solver name and operation as data properties #38

uekerman commented Mar 4, 2025

MakisH Mar 4, 2025

tapegoji Mar 4, 2025

MakisH left a comment

IshaanDesai commented Mar 5, 2025

vidulejs commented Mar 5, 2025

Logende commented Mar 6, 2025

uekerman commented Mar 7, 2025

Logende commented Mar 8, 2025

Model solver name and operation as data properties #38

Are you sure you want to change the base?

Model solver name and operation as data properties #38

Conversation

uekerman commented Mar 4, 2025

Current suggestions

Some examples

Review

MakisH Mar 4, 2025

Choose a reason for hiding this comment

tapegoji Mar 4, 2025

Choose a reason for hiding this comment

MakisH left a comment

Choose a reason for hiding this comment

IshaanDesai commented Mar 5, 2025

vidulejs commented Mar 5, 2025

Logende commented Mar 6, 2025

uekerman commented Mar 7, 2025

Logende commented Mar 8, 2025