Add interfaces to allow integration of PyFluent and PySystemCoupling

[ochernuk]

📝 Description of the feature

The motivation is to integrate PyFluent and PySystemCoupling in such a way that PySystemCoupling can orchestrate a co-simulation involving one or more PyFluent solver instances, leveraging the existing connection between Fluent and System Coupling. In order to do that, changes are needed in both PyFluent and PySystemCoupling repositories. PySystemCoupling should be able to receive a handle to the PyFluent solver (session) object and to:

• issue queries via a generic interface to get the System Coupling-specific setup information related to this participant:
  • Regions involved in System Coupling analysis (and their properties, such as topology, etc.)
  • Variables involved in System Coupling analysis (and their properties, such as tensor type, etc.)
  • Whether the Fluent analysis is steady or transient
• invoke commands to establish connection between Fluent and System Coupling and to perform a coupled solve
  • Some of these commands will need to be called asynchronously (perhaps on a separate thread)

It would be preferrable to avoid introducing dependencies between PyFluent and PySystemCoupling and instead to just have PyFluent provide a generic interface ("duck-typing") to PySystemCoupling to perform the above operations.

A corresponding issue will be tracked within the PySystemCoupling repository.

💡 Steps for implementing the feature

The proposal is:

1. Add a member to the ansys.fluent.core.Solver class of type ansys.fluent.core.SystemCoupling and provide access to it, e.g sc = solver.system_coupling
2. The SystemCoupling class will have the following public interfaces: a. get_variables() -> list b. get_regions() -> list c. get_analysis_type() -> str d. syc_connect(host : str, port : int, name : str) e. syc_solve()
3. Internally, SystemCoupling class will have a handle to the Solver object to access to the following functionality: a. To get the list of regions and variables, SystemCoupling will call solver.file.export.sc_def_file_settings.write_sc_file to produce the .scp (XML) file, and will read the file and parse it to fill in the regions and variables data structures. For that, it will need to use xml.etree.ElementTree package. b. To connect to System Coupling, issue sysc-connect-parallel scheme command c. To solve the coupled analysis, issue (sc-init-solve) scheme command

🔗 Useful links and references

Corresponding issue in the PySystemCoupling repository: https://github.com/pyansys/pysystem-coupling/issues/148

[dnwillia]

Oleg, random thought, I wonder if the integration classes with the solver libraries could be contained in a separate repo that is optionally installed? So, introduce pysystemcoupling-participants or something like that and we put all the dependent code there... or we could have a package per participant: pysysc-aedt, psysc-fluent, ... Customers would then install the solver specific packages they need for the coupling solve they need. This way both the core solver and syc libraries still remain unpolluted with each others dependencies and the solver core libraries don't have to contain system coupling specific details either. Not sure if that helps.

[ochernuk]

Hi @dnwillia, I agree that we do not want to introduce dependencies between the packages, and so the suggestion to use duck-typing would avoid those. It does, however, mean that some System Coupling specific details would be added into PyFluent.

Adding a separate pysysc-fluent package would work, though it would be less streamlined. In addition to having to install a separate package, it would probably mean that instead of interacting directly with the PyFluent session, the user would have to put the actual PyFluent session into some kind of a wrapper object and pass that to PySystemCoupling instead. However, if it's not desirable to add this extension to PyFluent, we can go with something like that. There is an example that was written as a proof-of-concept for this, maybe we just make it public and leave it at that.

[dnwillia-work]

I'm definitely not against the general proposal but my motivation in suggesting what I did was just keeping the fluent core library free of anything that is not related to Fluent.

Maybe the thing to do is write down how we would like the interfacing to look in a single workflow example with APDL and Fluent? It might be best to push up a PR to the PyFluent and PyMAPDL repos that makes the actual changes, along with an example which we can have a look at.

[ochernuk]

I would like to start with a Fluent-Fluent coupling example (see MAPDL note below). In this example, suppose we want to couple upstream and downstream Fluent systems. Hopefully one can see how this can be adjusted to couple with other solvers too, to do FSI for example.

import ansys.fluent.core as pyfluent
import ansys.systemcoupling.core as pysyc

upstream_fluid = pyfluent.launch_fluent()
# setup upstream fluid
# ...

downstream_fluid = pyfluent.launch_fluent()
# setup downstream fluid
# ...

syc = pysyc.launch()

up_name = syc.setup.add_participant(session = upstream_fluid)
down_name = syc.setup.add_participant(session = downstream_fluid)

interfaceName = syc.setup.add_interface(
  side_one_participant = up_name, side_one_regions = [“outlet"],
  side_two_participant = down_name, side_two_regions = [“inlet"])

syc.setup.add_flow_boundary_data_transfers(interface = interfaceName)

syc.setup.solution_control.minimum_iterations = 2
syc.setup.solution_control.maximum_iterations = 100

# other coupling setup (e.g. stabilization options)
# ...

syc.solve() # may want to do this asynchronously

# post-process
# ...

They key is to pass in the PyFluent session object into the add_participant command. PySystemCoupling would keep the handle to the session and later use it during the syc.solve() command. To make this happen, it does require adding a small amount of System Coupling specific code into PyFluent repo, but there are no new dependencies. I've put up a PR as an example of how it can be achieved:

https://github.com/ansys/pyfluent/pull/1620

To me it seems that the primary benefits of this approach are that it does not require installing additional packages and also that the amount of code is limited so I'm not sure creating a separate repository is justified (I don't anticipate additional functionality being added besides what's in that PR).

Regarding MAPDL, we first need to adjust how MAPDL and System Coupling interact (namely, ability to connect to System Coupling after MAPDL session has started) before we can make the change at PySystemCoupling-PyMAPDL level.

[ochernuk]

The pull request is ready for review: https://github.com/ansys/pyfluent/pull/1620

I've avoided scheme-eval calls as requested. I also added a version check to make sure this enhancement is only activated when 24.1 or later Fluent is used.

For now, PyFluent is relying on writing/reading of the temporary "fluent.scp" files to parse the setup information and pass it to PySystemCoupling. Addressing this would require additional changes inside Fluent so if that is ok, I would like to defer addressing this until later.

The corresponding changes on the PySystemCoupling side have been merged: https://github.com/ansys/pysystem-coupling/pull/177

@dnwillia-work @seanpearsonuk would you mind taking another look please?