EPIC: Componentization of PyFluent

[seanpearsonuk]

Theme IV — Componentization of PyFluent

This issue addresses a long-standing idea: to componentize PyFluent so that its core layers are modular and interchangeable.

Motivation

Currently, PyFluent’s client layer uses Fluent’s gRPC interface. We would like to introduce more flexibility here:

• Swap communication backends — for example, replacing the gRPC client layer with a REST client layer, without affecting higher-level PyFluent modules.
• Use PyFluent as a lightweight process controller — e.g., exposing only APIs for launching, monitoring, and terminating solver processes.
• Enable cross-product reuse — allowing other solvers or products to integrate into a common Python platform using PyFluent’s architecture as a foundation.

Architectural Implications

To achieve this, we’ll need to:

• Decouple PyFluent from flobject, the current Python base class underpinning Fluent’s Settings API object types.
  • flobject is too Fluent-specific to serve as a general base.
  • At the .proto level, however, the Settings API is generic and reusable, which is encouraging.
• Adopt or develop a more generic framework to replace flobject, ideally one that:
  • supports static attribute encapsulation (avoiding redundant API calls),
  • and can serve as a common base for other solvers and service layers.

Goals

• Define a component boundary for PyFluent’s transport/client layer.
• Demonstrate that PyFluent can run transparently over REST or gRPC.
• Prepare the framework for multi-solver integration within a shared Python ecosystem.