Model field type for matching to adapter internals

[MakisH]

In the OpenFOAM and CalculiX adapters, and maybe in more, we currently have the following workflow (based on the heat-exchanger tutorial:

1. In the adapter configuration file, read a dataName with value Sink-Temperature-Solid.
2. Internally, assume that anything that starts with Sink-Temperature* matches to an adapter object of type Sink-Temperature.
3. Call readData/writeData with the same name as configured.

There are three different entities we need to track to not make any assumptions:

a) Data known to preCICE: Sink-Temperature-Solid
b) The code path in the adapter to handle this type of data: Class SinkTemperature
c) The variable used by the solver: not something defined in this case, closest would be T, as this is the object we modify (in a non-straight-forward way)

With the solver-name (#38), we touched upon (c). The operation (also #38) also assumes that the adapter can directly operate on the specific object.

The (b) is still based on an assumption.

This already affects the OpenFOAM, CalculiX, OpenRadioss and maybe more adapters. Therefore, I think we need to define a standard name for such an option.

In YAML:

participant_name: Fluid
precice_config_file_name: ../precice-config.xml
interfaces:
  - mesh_name: Fluid-Mesh
    write_data:
      - name: Sink-Temperature-Solid
        type: Sink-Temperature

This would be an alternative definition to the solver-name & operation combination. @uekerman @vidulejs what do you think?

[uekerman]

First thought: This sounds like an implementation detail. Job of the adapter is to convert between Sink-Temperature-Solid and T. I think I don't understand yet why the intermediate object SinkTemperature is needed. Could you elaborate?

[MakisH]

The intermediate object SinkTemperature is needed because there is no such field directly available in the OpenFOAM solver: instead, we convert it to a temperature value (as you point out is the job of the adapter). Maybe a better example here would be the heat flux:

https://github.com/precice/openfoam-adapter/blob/develop/CHT/HeatFlux.C#L74L104

Since there is no such object, what value should the solver-name have? Use the same for both?

I see the difference between the name of the field and the type of it. For example, in a two-phase flow, we could have a T.air and a T.fluid, both of type Temperature.

[MakisH]

More context:

• We previously discussed solver_name and operation in Model solver data names in adapter schema #36 and Model solver name and operation as data properties #38
• Current description of solver_name: Name of the data as used by the solver (optional). This would still be useful instead of the custom name parameters.
• Current description of operation: Operation applied by the adapter on the data (optional), with examples value and gradient.
• The discussion mainly revolved around the OpenFOAM adapter. @vidulejs introduced a few examples, including this one for heat flux. Looking at it again, I think that this example will not work as-is, because when reading, we also need to divide with a different conductivity.
• Important context: The OpenFOAM adapter aims to do such conversions automatically. Some other adapters (e.g., DuMux) are delegating the operation to the user, who writes the respective code. For those adapters, a solver_name or operation are not used.

Discussing with @uekerman, the best way forward would probably be to define additional operations (e.g., heat-flux). Probably independent of the solver_name (which is anyway optional), the adapter should match an operation: heat-flux to a call to the HeatFlux constructor.

[MakisH]

An example could be:

    readData
    (
      Heat-Flux1
      {
      	name         Heat-Flux;
      	operation    heat-flux;
      }
    );

@vidulejs does this make sense?

Maybe an action here could be to extend the examples of the operation to include custom operations: scaling, foo(), heat-flux could be some. I assume one could apply a specific function as well.

[vidulejs]

solver_name
I am not sure about this. I'm not sure the mapping to the adapter object should happen in the operation field. Instead I think solver_name could be abstracted to encompass both the adapter objects and the solver objects. Otherwise the operation is specific to that adapter or else has to be made compatible for all adapters?

operation
I think operation should be something more general, like Makis suggested, the scaling (multiplication), gradient or even some user-definable compound arithmetic function. In that case if we have a fixed heat transfer coeffcient, we could do like operation kappa*(gradient); to obtain the same result as heat-flux. But this would cause additional implementation complexity in all adapters. If we introduce additional operations and they have to be implemented on the adapter side, then it will turn messy really quick. I think this is actually the job of the Python actions.

I think it's the responsibility of the user to understand what is being coupled and the physics of it, they have to understand that the gradient of temperature is not exactly heat flux.

For now the operation gradient; is not even fully implemented, but it is required to implement it on the adapter side to deal with the specific numerics, i.e., we cannot just do the finite difference for gradient on the preCICE level.