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 coupling subdomains #7

Open
MakisH opened this issue Oct 22, 2018 · 3 comments
Open

Support multiple coupling subdomains #7

MakisH opened this issue Oct 22, 2018 · 3 comments
Milestone

Comments

@MakisH
Copy link
Member

MakisH commented Oct 22, 2018

def configure(self, participant, precice_config_file, mesh, write_data, read_data):
self._solver_name = participant
self._interface = PySolverInterface.PySolverInterface(self._solver_name, 0, 1)
self._interface.configure(precice_config_file)
self._dimensions = self._interface.getDimensions()
self._mesh_name = mesh
self._write_data_name = write_data
self._read_data_name = read_data

By having the configure() directly inside the Adapter class, we assume that the adapter can only work with one coupling interface. By separating the adapter class (that also handles the time control etc) from the interface itself, we could support multiple coupling interfaces (for example, for Fluid-Solid-Fluid coupling, as in the shell-and-tubes heat exchanger tutorial).

Then, the configure() method would not be called in the adapter itself, but in each coupling interface. The same for the methods to read/write data etc.

@BenjaminRodenberg
Copy link
Member

The intended use of the adapter is one interface. In certain situations more than one interface might be needed, but I don't really see the need for this feature now. As a workaround I can imagine that creating two instances of the adapter object might even be sufficient. From a developer's perspective this is also the preferred solution, since supporting N coupling interfaces in the adapter would make the code considerably more complicated for an edge case.

I will close this issue. Feel free to reopen it or comment. Especially related:

  • Do you have a use case for the fenics adapter with several coupling interfaces?
  • Does the approach mentioned above (creating two instances of the adapter) work?

@MakisH
Copy link
Member Author

MakisH commented Apr 20, 2021

Going with "only supporting one interface" is perfectly fine, it is a design decision.

Do you have a use case for the fenics adapter with several coupling interfaces?

Use cases I can think of:

  • Heat exchanger (one solid, two fluids)
  • Separating membrane (one solid, two fluids)
  • Beams connected (multiple solids)
  • (if you add support for flows) FSI with two flaps (one fluid, two solids)

Does the approach mentioned above (creating two instances of the adapter) work?

I don't know anything about the FEniCS adapter code, but in the OpenFOAM adapter we have it like this and it works.

@BenjaminRodenberg BenjaminRodenberg changed the title Support multiple coupling interfaces Support multiple coupling subdomains Apr 20, 2021
@BenjaminRodenberg
Copy link
Member

I totally misunderstood the issue. We are talking about coupling_subdomains, not about what we call the interface in the adapter:

coupling_subdomain : Object of class dolfin.cpp.mesh.SubDomain
SubDomain of mesh which is the physical coupling boundary.

self._interface = precice.Interface(self._config.get_participant_name(), self._config.get_config_file_name(),

This is, of course, a totally valid use-case. We already have several tutorials dealing with this and I can also imagine extending the fenics adapter into this direction, if needed.

note: Naming with interface vs. subdomain is in some places inconsistent and confusing. I will open a PR in a moment to clean this up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants