PyFluent: Evolving Towards an Intuitive CFD Experience

sean.pearson@a… | 07.31.2025

Fluent is one of the world’s most powerful and widely used CFD solvers. PyFluent builds on that foundation, offering a modern Python interface to Fluent’s simulation capabilities. But this isn’t just about adding Python syntax — it’s about transforming how users interact with Fluent.

The PyFluent project is evolving to meet the expectations of today’s developers: intuitive, object-oriented interfaces that are powerful, discoverable, and consistent. This article walks through how PyFluent has evolved, the design principles driving those changes, and what that means for users today.

Challenges of Legacy Interfaces

The early Fluent interfaces were powerful but cryptic. TUI commands and Scheme scripting exposed the full range of capabilities — but required expert knowledge, painstaking memorization, and offered little room for error.

Even when PyFluent was introduced, early versions still carried some baggage from those interfaces. Though the settings API was already a significant shift away from TUI commands, it still leaned heavily on raw strings and long attribute chains, making some workflows harder than they needed to be.

The Evolution of PyFluent

Over time, PyFluent has evolved from simply providing a Pythonic gateway to Fluent, to providing a genuinely intuitive developer experience. We can think of this evolution in three major phases:

1. Legacy Fluent Interfaces

  • Powerful but fragmented, cryptic, and undisciplined
  • No shared naming, poor discoverability, trial-and-error usage

2. Nascent PyFluent (Early Versions)

  • Well-documented, discoverable, modern, powerful API
  • But still string-based settings and deep object hierarchies that limited discoverability

3. Transcendent PyFluent (Recent Versions)

  • Stronger typing (enums, physical units, descriptors)
  • Direct access to setting classes, context management
  • A much more intuitive design that’s fully introspectable, discoverable, and Pythonic

Reimagining the Interface

Direct Access and Scoped Usage

Modern PyFluent introduces direct access to key Fluent settings classes — no more navigating nested hierarchies. For instance, you can now instantiate Viscous() or VelocityInlet("hot-inlet") directly.

Additionally, PyFluent supports context managers for session scoping, allowing developers to write cleaner, more intentional code:

with using(solver):
    viscous = Viscous()
    viscous.model = viscous.model.K_EPSILON

This pattern makes PyFluent easier to learn and less error-prone, particularly in larger applications where managing session context is critical.

Replacing Strings with Objects

Modern Python developers expect more than a command pipe. They expect autocompletion, validation, discoverability, and above all, predictability. That meant pushing past wrappers and embracing real, object-driven APIs.

Wherever possible, PyFluent now replaces raw strings with expressive, type-safe alternatives:

  • A viscous model is no longer passed as "k-epsilon" — it's an enum: viscous.model.K_EPSILON (in Fluent 2026R1 onwards)
  • A location isn’t always just a string name — it can be a reusable, discoverable location object
  • A physical value with units doesn't have to be passed as "300 [K]" — it’s constructed with a Quantity object, ensuring correctness and clarity
  • A field name doesn’t have to be a fragile string like "pressure" — it can be passed as a variable descriptor such as VariableCatalog.PRESSURE, enabling consistent and reusable references across multiple Fluent APIs, even when those APIs use different naming conventions internally

These patterns apply across the board — not just in the Settings API — offering a more coherent and fluent interface throughout.

A More Intuitive Workflow

Let’s walk through a simple example using the modern PyFluent API.

Here’s a baseline configuration using the traditional approach:

solver.settings.setup.models.viscous.model = "k-epsilon"

Straightforward — but prone to typos and reliant on memorizing string literals. With improved typing, the same task becomes safer and more discoverable:

viscous = solver.settings.setup.models.viscous
viscous.model = viscous.model.K_EPSILON

This isn't just a style change. It provides validation, IDE support, and a smoother developer experience — replacing guesswork with guidance.

Now let’s take this a step further. PyFluent allows direct access to settings objects and supports context managers for scoping session usage cleanly. This eliminates the need to thread the session object through every API call.

with using(solver):
    viscous = Viscous() 
    viscous.model = viscous.model.K_EPSILON

These improvements make your code clearer and your intent more explicit.

Let’s look at another example — specifying a location for a field reduction. Previously, you’d pass a string to indicate the region:

pressure_sum = reduction.sum(
    expression="AbsolutePressure",
    locations=["hot-inlet"],
    weight="Area"
)

With the updated API, you can pass actual location objects instead of relying on fragile string names:

with using(solver):
    hot_inlet = VelocityInlet("hot-inlet")
    pressure_sum = reduction.sum(
        expression="AbsolutePressure",
        locations=[hot_inlet],
        weight="Area"
    )

This not only improves safety, but also enables reuse and introspection. And it doesn’t stop there. The weight argument is now an enum, and field names can use variable descriptors — giving you a fully typed, expressive API:

with using(solver):
    hot_inlet = VelocityInlet("hot-inlet")
    pressure_sum = reduction.sum(
        expression=VariableCatalog.ABSOLUTE_PRESSURE,
        locations=[hot_inlet],
        weight=reduction.weight.AREA
    )

These aren’t isolated improvements — they reflect a broad pattern across PyFluent: better typing, smarter defaults, and APIs that guide you rather than trip you up.

Why It Matters

These changes aren’t just about aesthetics. They’re about enabling faster, safer, and more confident development. By reducing friction and increasing clarity, PyFluent empowers users to focus on what matters: building better simulations.

This evolution is ongoing — and it’s shaped by real usage and real feedback. PyFluent isn’t just an interface to Fluent. It’s becoming the intuitive language of Fluent itself.

About the Author

Sean Pearson, PhD Sean earned his PhD in theoretical physics in 1996 and has been with Ansys (now part of Synopsys) since 2007. Sean has led the development of PyFluent since its inception and spearheads other key projects within the organization. He also plays a key role in shaping the direction of Ansys’s Python ecosystem across multiple solvers, and is a champion for modern, Pythonic APIs and simulation accessibility.

Learn More

Connect with Ansys