PyFluent 2026: Planning Themes — An Open Discussion

[seanpearsonuk]

🧭 PyFluent 2026: Planning Themes

This thread is to collect high-level planning themes for PyFluent development in calendar year 2026.
These are early thoughts meant to seed discussion — please comment, refine, and challenge as needed.

---

I. Agentic AI Platform

The objective is extend the present work to encompass fully autonomous agentic workflows. This is covered in #4614.

---

II. Data Extraction Performance

Currently, solution data arrays are extracted from the Fluent solver via the cortex gRPC server.
We need to benchmark the performance of this architecture, identify bottlenecks, and design + implement improvements.

---

III. Intuitive PyFluent API

We’ve made excellent progress here — but there’s always room to go further.

• Type safety: VariableDescriptors could encode whether they apply to scalars or vectors, allowing generalized type-checking at field-data extraction interfaces.
• Completeness: Audit the VariableCatalog for completeness and fill gaps.
• Meshing usability: Continue mapping of the meshing workflow data-model naming and types to our user-friendly API surface.
• Settings API overhaul: This remains too inconsistent and under-documented.
  • Assign ownership of API sections to ACE team members for design review, documentation improvement, and example coverage.
  • Build a repeatable process for identifying and addressing problem areas.

---

💬 Discussion Prompts

• Are these themes aligned with where we should focus our 2026 efforts?
• Which of these should be highest priority?
• What other strategic themes should we consider?

---

[seanpearsonuk]

Theme IV — Componentization of PyFluent

This theme addresses a long-standing idea: to componentize PyFluent so that its core layers are modular and interchangeable. The details can be found in #4618.

[seanpearsonuk]

@mainakk @prmukherj @hpohekar @mkundu1
@raph-luc @h-krishnan @dnwillia-work @lagacep-ans @gyeole @ansjschuetz
@cj-hodgson @millerj97 @Gobot1234
@PyPablo @sravanansys @abhishekchitwar @rploconnor @MohammedAnsys @PySRG
@tejalprabhu01
@ochernuk @iboyd-ansys

[seanpearsonuk]

@dpons-ansys

[Gobot1234]

In terms of enhancements to pyfluent I would really like to see 100% type coverage. I think this would really help to improve the developer experience for standalone (until pyconsole gets type checking) but would also cut down the number of bugs.

[mkundu1]

Define a component boundary for PyFluent’s transport/client layer.

A good test/sub-goal for this is to be able to use the default sessions within Fluent PyConsole without importing gRPC, SSL and other related dependencies. We've also faced issues few times in the past due to mismatch of some of these dependency versions between Fluent and PyFluent/Python.

[hpohekar]

Let’s aim for 100% test coverage to ensure maximum code reliability and maintainability. This will help us identify potential issues early, improve confidence in deployments, and uphold a high standard of software quality.

[prmukherj]

Yes, sounds good.

[raph-luc]

I would advise against chasing 100% code line coverage. It does not mean there are no bugs, it is rather misleading and not a very good metric. Having some code coverage (say more than 80% is commonly used), is okay. I think it is far more important to think about code paths and cyclomatic complexity, than specific numbers of code line coverage.

If we are looking to improve testing in PyFluent, I would say we can look into options such as mutation testing. For Python one option seems to be https://mutatest.readthedocs.io/en/latest/. I haven't used this yet, but it is something that might be worth trying out

[seanpearsonuk]

Shall we finally take the gRPC bull by the horns in 2026? Do all the things we need to do to get it fully release-ready?

[prmukherj]

I agree with this. Let's start it early on only and decide based on the status, mid-way.

[seanpearsonuk]

We have a detailed plan for this written down outside of GitHub, which I can share.

[raph-luc]

@seanpearsonuk what are you referring to, here? Do you mean in relation to Theme 4, and showing that PyFluent can work through the Rest interface as well?

[seanpearsonuk]

@raph-luc My original comment here is separate from Theme IV. The plan alluded to centres around everything that needs to be done in terms of updating and documenting the proto interface itself.

[seanpearsonuk]

Some of the items in this discussion contain detailed sub-items. We should create full issues for those which we only reference from here. We can follow up on that in general discussions next week.

[raph-luc]

3. Enhance PyFluent / Fluent Robustness

• Strengthen the end-to-end architecture for reliability and transparency.
• Complete missing Settings API elements that block key workflows (high urgency).
• Improve quality and coverage of the Settings API and its documentation.

This is almost entirely server-side work, and not necessarily PyFluent, right? And yes, I can definitely see there is a lot of work that needs to be done there.

I would say this would probably be the highest priority and the most relevant part of the "Agentic" theme. Should this be its own theme? This is definitely important far beyond just agentic LLMs

[raph-luc]

Also, it looks to me like there is significant overlap in the theme list here between theme III and theme I item 3. I think could take I.3 out of there and make it part of theme III, revising theme III to be perhaps about "PyFluent and Fluent Settings API improvements", or something similar

[seanpearsonuk]

Thanks @raph-luc . I totally agree that much of the gRPC work is server-side and not strictly PyFluent. That said, I think the key here is that themes are about user-facing value, not about where the work physically sits.

The purpose of the themes is to identify cohesive, user-meaningful areas of investment. Each theme will inevitably pull in work from multiple layers (PyFluent, server, proto definitions, documentation, etc.). The technical boundaries will always overlap, and that’s fine but what matters is that the theme tells a clear story about why we’re doing the work.

We also want to keep the number of themes relatively small, both to help the team stay focused and to keep external messaging clean and coherent. If two themes appear to overlap, it probably means the underlying user benefit is closely related, and we can consolidate or reposition as needed.

I agree there’s a natural connection between the Settings API work (Theme III) and parts of I.3. It may make sense to fold those together under a unified “PyFluent & Fluent Settings API improvements” theme.

[raph-luc]

Are the themes and points in any order of importance? Looking at these right now, if I was to attempt to rank them based on my personal opinion (and just to see what you guys are thinking as well), from most important to least important:

• I.3 Enhance PyFluent / Fluent Robustness
• III Intuitive PyFluent API
• IV Componentization of PyFluent
• II Data Extraction Performance - I imagine this might be heavily influenced by the work for theme IV
• I.1 and I.2 Agentic AI Platform - considering how things are going right now, I believe having LLMs work well with PyFluent in the long term will rely mostly on the maturity of PyFluent and the Settings API, and will not necessarily require targeted work for LLMs

Thinking aloud: I am realizing now that most of the points under "I.1 Make PyFluent Architecture Agentic-Ready" would certainly also be useful outside of LLM usage. I am thinking it might also be useful to give it more prominence as well, making that its own theme? LLM applicability of that work would be an extra benefit and extra motivation, but it something that should be done regardless

[seanpearsonuk]

They're not in order of importance and that decision is not solely ours either.

[raph-luc]

Sandboxing: Explore pseudo-sandboxing (shadow state validation in Python) as a longer-term enhancement.

I don't understand what this is trying to say. Can you elaborate or provide any examples where this is relevant in PyFluent?

I understand what variable shadowing is. But validation of it, and sandboxing? Do you mean just trying to clarify when shadowing/local scoping is occurring, and perhaps fixing it so there is no shadowing anymore, to avoid confusion?

[seanpearsonuk]

@raph-luc I have simpified the language in #4615. I hope this helps.

[raph-luc]

That is an interesting feature, and yeah the additional description definitely helps, thanks.

[ochernuk]

@seanpearsonuk that all sounds good; obviously, Theme IV is interesting to us and if you create a common architectural foundation that System Coupling can re-use, that would be of interest. Would the backend server still be a gRPC server? @iboyd-ansys this is good to keep in mind.

Theme II, is also kind of interesting, for transfer of solution data arrays. I wonder if Python's multiprocessing.shared_memory module (for the case where PyFluent and Fluent are all local) could be useful for this?

[seanpearsonuk]

Would the backend server still be a gRPC server?

The refactored architecture would support both gRPC and REST servers. Of course, at the moment the client is tied to gRPC whereas Fluent has both options.

Python's multiprocessing.shared_memory

We have that solution in mind in general terms for local connections though I am unfamiliar with the Python module myself (others in the group may be familiar with it).

[PyPablo]

@seanpearsonuk I think the points cover well what should be the priorities. I though dont see any reference to improving documentation. I very regularly keep receiving feedback from adopting customers stating that the documentation is not intuitive and lacks completion. We should target at making it simpler to follow up for non-experts, and target is steady completion.

Regarding the points, II is a very interesting topic that has a number of open questions, especially when transfer data in parallel from server to client.

[seanpearsonuk]

@PyPablo We should look into this so that the API reference might become more intuitive. (Refers to Disco API comment).

[seanpearsonuk]

Has he created a GitHub issue? This does not look like a documentation issue. The framework might be missing some pre-validation of arguments. (Refers to save_picture comment).

[PyPablo]

dont know the failure, but if you provide the file_name, as stated in the doc, it works fine. The point is that those class args seem to be confusing because many newcomers don't know the difference between class and attribute

[seanpearsonuk]

@PyPablo I see what you mean, now. save_picture is a class and has construction arguments. This documentation is not inaccurate.

[seanpearsonuk]

dont know the failure, but if you provide the file_name, as stated in the doc, it works fine. The point is that those class args seem to be confusing because many newcomers don't know the difference between class and attribute

@PyPablo We’re definitely open to improving the documentation. At the same time, we also need to use standard Python terminology, otherwise the documentation risks becoming confusing in a different way. The goal is to explain things clearly without replacing correct terms with new ones that could cause misunderstandings.