Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support multiple read/write fields #65

Open
BenjaminRodenberg opened this issue Jan 30, 2020 · 4 comments
Open

Support multiple read/write fields #65

BenjaminRodenberg opened this issue Jan 30, 2020 · 4 comments
Labels
enhancement New feature or request help wanted Extra attention is needed student
Milestone

Comments

@BenjaminRodenberg
Copy link
Member

BenjaminRodenberg commented Jan 30, 2020

Currently we initialize only a single read and a single write field:

def initialize(self, coupling_subdomain, mesh, read_function, write_function, dimension=2):

For some applications we need more than one.

@BenjaminRodenberg BenjaminRodenberg added the enhancement New feature or request label Jan 30, 2020
@IshaanDesai IshaanDesai added help wanted Extra attention is needed student labels Apr 19, 2021
@precice-bot
Copy link

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

@PhilipHildebrand
Copy link

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?

@BenjaminRodenberg
Copy link
Member Author

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.

@IshaanDesai
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed student
Projects
None yet
Development

No branches or pull requests

4 participants