Support multiple read/write fields about fenics-adapter HOT 4 OPEN

This issue has been mentioned on preCICE Forum on Discourse. There might be relevant details there:

https://precice.discourse.group/t/how-to-couple-multiple-datas-into-fenics/1070/2

from fenics-adapter.

How many different fields would we want to support? Something like def initialize(self, coupling_subdomain, mesh, read_function, read_function2, write_function, write_function2, dimension=2): where we support a fixed amount of fields (here 2 for write and read each) or something like def initialize(self, coupling_subdomain, mesh, read_function_list, write_function_list, dimension=2): where we could support as many read/write fields as we have entries in the read/write function lists?

from fenics-adapter.

How many different fields would we want to support? Something like def initialize(self, coupling_subdomain, mesh, read_function, read_function2, write_function, write_function2, dimension=2): where we support a fixed amount of fields (here 2 for write and read each) or something like def initialize(self, coupling_subdomain, mesh, read_function_list, write_function_list, dimension=2): where we could support as many read/write fields as we have entries in the read/write function lists?

Definitely option two. I don't have a good idea at the moment how we could get the interface right. I think it would be good to still give a user that just wants to provide a single read and/or write function to directly provide the function: initialize(..., my_read_function, my_write_function), not initialize(..., [my_read_function], [my_write_function]).

It might also be a good idea to think about using a dictionary instead of a list, because this would reduce the possibility to mix up write and read functions. For prototyping this idea, we can use the multiple-perpendicular-flaps tutorial. This might look like

initialize(..., {'Displacement-Upstream': write_function_1, 'Displacement-Downstream': write_function_2}, {'Stress-Upstream': read_function_1, 'Stress-Downstream': read_function_2})

Another important point: How would the corresponding adapter config look like? If we follow the dictionary approach, we might even entirely remove write_data_name and read_data_name there, because they are not needed anymore, if the user has to provide them anyway to identify the read/write functions.

from fenics-adapter.

I would also agree that option 2 where an arbitrary number of read and write fields are supported is the way to go. Have a dictionary where the keys are the names of the data and the values are the corresponding functions sounds like a good idea right now. I would suggest keeping the write_data_name and read_data_name fields in the adapter configuration for now as we can use these fields to check if the user has actually provided the correct names in the dictionary.

A bigger question is whether we should work on the design of this feature in the fenics-adapter or the fenicsx-adapter. In theory we would need this implementation in both the adapters, and I estimate that the function touched in this implementation are more on the user side (that is they are in fenicsprecice.py). But let us be careful to plan something which is doable for @PhilipHildebrand.

from fenics-adapter.