Expose enums attribute for discoverability and error prevention

[seanpearsonuk]

Summary

I propose enhancing the developer experience in PyFluent by exposing enumerated (fixed) values for settings as programmatic constants on each relevant settings object. This would allow users to write code like:

viscous.model = viscous.model.LAMINAR

rather than relying on fragile string literals:

viscous.model = "laminar"

Motivation

Currently, users must assign string literals to Fluent settings, which:

• Is error-prone (e.g., typos like "lamimar" go uncaught until runtime)
• Reduces IDE support (no autocomplete or inline documentation for allowed values)
• Limits discoverability (users must check allowed_values())

These issues are particularly relevant in large, complex hierarchies where many settings support constrained value sets.

While allowed_values() is already available at runtime, it serves a dynamic and validation-oriented purpose rather than providing a developer-friendly interface.

Proposed Solution

I propose adding enumerations to relevant setting nodes, which would expose fixed enumerations in a programmatic, discoverable, and IDE-friendly way:

viscous.model.LAMINAR

This syntax offers:

• Strong discoverability (via autocomplete)
• No ambiguity (clear intent to reference a defined value)
• Minimal user effort (just one extra dot from the string version)
• Safety from naming clashes: using uppercase for enumerated constants

I consider this design suitable not just as an interim improvement, but as a durable solution.

Rejected Alternatives

1. Method-based selectors

viscous.model.select_laminar()

• Adds many additional methods, bloating the API
• Less composable
• Harder to document and extend

2. Module-level enums

from pyfluent.enums import ViscousModel
viscous.model = ViscousModel.LAMINAR

• Separates the enum from its usage context
• Not discoverable unless the user already knows where to look
• Adoption will be low

3. options attribute

viscous.model.options.LAMINAR

• Higher risk of naming conflict

Next Steps

• Identify all settings with fixed (non-fully-dynamic) enumerations
• Provide in static metadata
• Generate the enumeration based on these allowed values

[seanpearsonuk]

Discussion with team:

• dropping the enums object
• one idea from @mkundu1: possibility of viscous.model.laminar.set_in_parent()