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.

Sign up for GitHub

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

Jump to bottom

Decouple preCICE and solver in adapter via proxy #2003

Open
fsimonis opened this issue Apr 16, 2024 · 5 comments
Open

Decouple preCICE and solver in adapter via proxy #2003

fsimonis opened this issue Apr 16, 2024 · 5 comments
Labels
enhancement A new feature, a new functionality of preCICE (from user perspective)

Comments

@fsimonis
Copy link
Member

Please describe the problem you are trying to solve.

We repeatedly have issues with "systems" that ship their own libraries. These can conflict with the libraries used to build preCICE. Examples are:

Describe the solution you propose.

Decouple the preCICE library from the solver via a proxy server.
The proxy links to/uses preCICE and accepts commands via a REST API.

This way, the solver is decoupled from preCICE. There are no library conflicts between the two. The only dependency, the adapter adds to the solver is a sockets library and some format parser.

sequenceDiagram
    Adapter->> Proxy: POST /create, { "name" : name, "config": config }
    Proxy->> preCICE: Participant(name, config)
    preCICE-->>-Proxy: ( )
    Proxy-->>-Adapter: 200 OK

    Adapter->> Proxy: POST /setMesh, {"name" : mesh, "coordinates" : coords}
    Proxy->> preCICE: setMesh(name, coords)
    preCICE-->>-Proxy: ( )
    Proxy-->>-Adapter: 200 OK

    Adapter->> Proxy: POST /writeData, {"mesh" : mesh, "data": data, "indices": indices, "values": values}
    Proxy->> preCICE: writeData(mesh, data, indices, values)
    preCICE-->>-Proxy: ( )
    Proxy-->>-Adapter: 200 OK

    Adapter->> Proxy: POST /initialize, {}
    Proxy->> preCICE: initialize()
    preCICE-->>-Proxy: Error Message
    Proxy-->>-Adapter: 409 Conflict, {Message}
Loading

The downsides:

  • Performance not needing further explanation
  • Unclear how to handle parallel participants
  • Requires REST API which in turns requires some kind of bindings to different languages.
  • There are essentially two bindings per language. One that directly uses preCICE and one that uses the proxy.

Describe alternatives you've considered

Theoretically, preCICE is already decoupled from other solvers using TCP/IP connections.
preCICE can be built against the solver-provided libraries. Different preCICE builds of the same preCICE version should be compatible. However, this is extremely fragile.

Further context

This is by no means a feature request. This issue purely exists for the sake of documentation and discussion.
@fsimonis fsimonis added the enhancement A new feature, a new functionality of preCICE (from user perspective) label Apr 16, 2024
@MakisH
Copy link
Member

MakisH commented Jun 27, 2024

I understand the problem, but I think that it is not that prominent, and such a solution would only introduce more problems. But a very interesting idea, for sure.

We have already done some work in making the binaries more isolated, and I think we should continue thinking in this direction.

@fsimonis
Copy link
Member Author

fsimonis commented Jun 27, 2024 •
edited
Loading

such a solution would only introduce more problems

If you are in a situation where a closed-source code links to an ancient version of one of our dependencies such as Boost, and you cannot patch preCICE to work with this dependency or you run into ODR violations as you don't know the exact configuration of the dependency, then one of your last options is to do something like this.

In this case, it may be a worthy price to pay.
Of course, this would be a maintenance burden.

Alternative would be to write files and wrap the whole executable with a preCICE adapter, which may be a way more practicable approach to this.

@MakisH
Copy link
Member

MakisH commented Jun 27, 2024

Ah, now I understand that you mean this as an additional feature, not redesigning the whole API. In that case, yes, why not (besides the effort to develop and maintain).

This means that a closed-source code would already be coupled with preCICE, and we would only change the API implementation to support upgrading. I don't know of any such case at the moment.

@fsimonis
Copy link
Member Author

Ah, now I understand that you mean this as an additional feature, not redesigning the whole API. In that case, yes, why not (besides the effort to develop and maintain).

I see this issue primary as "documentation of consideration". We know that in some situation, direct coupling with preCICE is extremely hard. Using such a proxy could be an option to implement this.

This means that a closed-source code would already be coupled with preCICE, and we would only change the API implementation to support upgrading. I don't know of any such case at the moment.

The premise of this issue is that it is not possible to couple the closed-source code due to conflicts of dependencies or similar. Hence, an adapter could be planned, but not implemented. Coupling to the REST-API would be the first possible step to implementing a coupling with preCICE.

Looking at the sequence diagram in OP, the adapter and the proxy are running in different processes and communicate via a TCP connection.

@MakisH
Copy link
Member

MakisH commented Jul 2, 2024

I understand the technical aspects. But I still see a lot of "could", "maybe", and "what if" in this discussion.

Good to document the idea anyway, who knows what future brings. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement A new feature, a new functionality of preCICE (from user perspective)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@MakisH @fsimonis