Model non-existant read and write directions in schema

[uekerman]

Sometimes, read or write data does not exist. For instance, for uni-directional coupling or if multiple meshes are used.
How should we model such situations in the schema?

Option 1: Empty arrays

read_data_names is an empty array.

{
  "participant_name": "Fluid",
  "precice_config_file_name": "../precice-config.xml",
  "interfaces": [
    {
      "mesh_name": "Fluid-Mesh",
      "patches": [
        "interface"
      ],
      "location": "faceCenters",
      "read_data_names": [
      ],
      "write_data_names": [
        "Temperature"
      ]
    }
  ]
}

Option 2: Leave array out

read_data_names does not exist.

{
  "participant_name": "Fluid",
  "precice_config_file_name": "../precice-config.xml",
  "interfaces": [
    {
      "mesh_name": "Fluid-Mesh",
      "patches": [
        "interface"
      ],
      "location": "faceCenters",
      "write_data_names": [
        "Temperature"
      ]
    }
  ]
}

Remarks

• The OpenFOAM adapter currently follows option 1, but this should not be a technical restriction from OpenFOAM, or is it? @MakisH
• Pro option 1: More explicit. We can make both fields (read and write) required.
• Pro option 2: Shorter. Also more intuitive? Clearer to generate? (there will presumably be no data connection in the topology description)
• Allowing both options could be dangerous as this would then require that all adapters need to be able to handle both situations.

[MakisH]

* The OpenFOAM adapter currently follows option 1, but this should not be a technical restriction from OpenFOAM, or is it? [@MakisH](https://github.com/MakisH)

Apparently, this is not a technical restriction (anymore?), and I modified the adapter to support both: precice/openfoam-adapter#348

Allowing both options could be dangerous as this would then require that all adapters need to be able to handle both situations.

I would ask for a specific one of the options, but not forbid supporting both (which I guess you are not suggesting anyway).

I think that option 2 (omitted) would be the more intuitive, given what we are used to in other contexts.

[uekerman]

I would ask for a specific one of the options, but not forbid supporting both (which I guess you are not suggesting anyway).

Not exactly. I think it would be better to forbid the other one in the schema. Otherwise, we get interoperability issues. Imagine converting the config of an OpenFOAM case to another solver. Of course, an adapter could still support the other variant as deprecated.

[MakisH]

But then this also gets annoying when one is experimenting with different options. For example, in the fluid-fluid coupling studies, we often had to toggle which fields we read and write. Having to constantly enable/disable a list because it ends up being empty sounds loosely-motivated to me. As a user, I would expect an empty list to be the same as an omitted list.

We could give warnings in the validation step that this might not work with all adapters.

[uekerman]

Having to constantly enable/disable a list because it ends up being empty sounds loosely-motivated to me. As a user, I would expect an empty list to be the same as an omitted list.

I see the point. If a GUI is used, this could still be one click only.

We could give warnings in the validation step that this might not work with all adapters.

I am not sure if JSON schema supports such warnings.

@Logende What is your view on this? This must be a common problem in configurations, right?

[Logende]

Most user-friendly will definitely be supporting both options. Question is only if this is feasable.

And for adapter-developers, it would be useful to have a preCICE API function to load an adapter config from a JSON/YAML according to the new schema.

[BenjaminRodenberg]

My main argument against option two: I would not like to force somebody to provide a keyword even if no argument for this keyword is provided. Example: API of matplotlib.pyplot.plot. Imagine you have to write keyword=None for every keyword you do not want to use.

I'm fine with users following option two if they have a good reason but I would not like to force anybody to follow this path.

[uekerman]

Most user-friendly will definitely be supporting both options. Question is only if this is feasible.

@MakisH reported that it was rather trivial to support both in the OpenFOAM adapter. Thinking about it again, I believe that this should be the case for most adapters.

And for adapter-developers, it would be useful to have a preCICE API function to load an adapter config from a JSON/YAML according to the new schema.

True, but sth for a different issue. Main technical problem: It is not trivial to implement such a returned complex configuration object similarly in all our bindings (C, Fortran, ...). What I could imagine currently is a Python-only solution.