You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think we will still need the information about the part about the coupling interface here -- even if the user also provides the labels in the adapter code. Otherwise the information which data "lives" on which mesh would be lost.
We would need to extend the API of the adapter to accept a label indicating the data we want to read or write and the corresponding mesh. We would get the following API calls for the Dirichlet participant:
We can only create_coupling_expression if we know for which read_function_space, i.e. must provide 'Temperature'.
For read_data and write_data providing Dirichlet-Mesh and Temperature/Heat-Flux is not strictly necessary in this case. But imagine we have Temperature1 and Temperature2 or Temperature on Dirichlet-Mesh1 and on Dirichlet-Mesh2.
update_coupling_expression should be able to get all the required information from coupling_expression
Note: There is definitely a possibility for some redesign to simplify the user interface, e.g. by calling directly coupling_expression.read_data(dt). Thinking about point sources we could also introduce a point_source = precice.create_coupling_point_sources('Dirichlet-Mesh', 'Temperature'). But I think this is bringing us quite far away from the original issue. Let's implement the feature first and then try to come up with an improved interface (if necessary) later.
This issue was already adressed for the fenics-adapter precice/fenics-adapter#65. Allow the user to initialise the adapter also with dictionaries of different data or functionspaces could be a good solution, as described by @IshaanDesai in precice/fenics-adapter#65 (comment).
The text was updated successfully, but these errors were encountered: