Epic: Package the PyAnsys settings framework

[seanpearsonuk]

The client-side settings framework used in PyFluent supports PyFluent's interaction with Fluent settings through the settings API and its hierarchy of settings objects. The framework is sufficiently generic in concept that it can be repurposed to facilitate rapid construction of client libraries for a variety of products and services.

The anticipated benefits of commoditizing the settings framework include rapid client library development even in inexperienced teams, higher quality due to a single, centralized maintenance operation, and - above all - a uniformity across (some of) the PyAnsys developer experience.

The success of this project will be boosted by the efforts of early adopters that will help to shape the solution and also prove the concept. Those intended earliest adopters will be:

• The Fluent data model applications, including meshing workflow (and later the Fluent workspaces). Integration at the level of the underlying data model infrastructure itself will be sufficient to cover all those applications in one go
• PyCFX
  The PyCFX and PyFluent teams are already working closely together.

In its broadest definition, the settings framework currently consists of the following components:

1. Settings service proto files - the definition of the Settings gRPC interface
2. Python gRPC interface package built from the proto file
3. The SettingsService class, which is a proxy to the gRPC stub
4. The hierarchy of generic API classes defined in flobject.py. These abstract base classes provide a uniform Python interface for interacting with settings objects, and encapsulate the interaction with the SettingsService through a purely abstract dependency
5. (WIP) Mixin classes that represent the settings aspects of session objects. The mixin exposes the roo-level settings objects so that inheriting from such a mixin automatically exposes the settings tree through the session objects. The mixins are built as part of the codegen (see below)
6. An automatic code generation module that builds concrete Python classes based on the static content of the product or service's API. The codegen tool connects via a running instance of the product or service and pulls the full static information directly from the API.

In order to ease the transition from a Fluent solver solution to a fully flexible framework, the following steps are anticipated:

1. Settings proto. The definition of the Settings service shall be minimal and complete, the changes for which have already been achieved in Fluent 2024R2 development. This is the minimal service:

service Settings {

/* Static info about objects (type, children, commands, arguments,
object-type) in a recursive manner. */
rpc GetStaticInfo(GetStaticInfoRequest) returns (GetStaticInfoResponse);

/* Get the value of a path */
rpc GetVar(GetVarRequest) returns (GetVarResponse);

/* Set the value of a path */
rpc SetVar(SetVarRequest) returns (SetVarResponse);

/* Create a new object */
rpc Create(CreateRequest) returns (CreateResponse);

/* Execute a command */
rpc ExecuteCommand(ExecuteCommandRequest) returns (ExecuteCommandResponse);

/* Execute a query */
rpc ExecuteQuery(ExecuteQueryRequest) returns (ExecuteQueryResponse);

/* Attribute access */
rpc GetAttrs(GetAttrsRequest) returns (GetAttrsResponse);
}

The transition was achieved simply by implementing higher level methods (e.g., Rename) in terms of lower level ones. The new, minimal interface is anticipated to reduce barriers to implementing settings-API-compliant server code due to having fewer explicit gRPC methods to implement, and means that the service supports clients more flexibly.

2. Python gRPC interface package: no changes anticipated.

3. The SettingsService class. This currently has some dependencies of concern:

• SchemeEval. Only used to query if a name has a wildcard. Instead we can just pass in a callable and default its result to False. Additionally, we can also implement the function client side for Fluent (surely?). And then, finally, the has_wildcard method does not really belong in this service. Instead it could be a standard extension in flobject.py.
• ErrorState. Object to indicate the error state of the connected Fluent client. This might not be very relevant for this service, so this could be an optional dependency.

4. The hierarchy of generic API classes defined in flobject.py. This must only function as an extensible framework, and should exclude any application-specific assumptions.
   a. For instance, it should not contain any hard-coded Fluent names. We have already taken a step towards separating out Fluent names by defining them as constants within an flobject class:

class _InlineConstants:
    is_active = "active?"
    is_read_only = "read-only?"
    default_value = "default"
    min = "min"
    max = "max"
    user_creatable = "user-creatable?"
    allowed_values = "allowed-values"

Next, we shall move that class to a separate module, and each framework user shall define its own labels.

b. It shall not instantiate a PyFluent logger
c. We have methods to_scheme_keys and to_python_keys. We shall name the former to be more general. Are these methods actually transforming anything?
d. Eliminate all incidental mentions of Fluent and just use more general naming/wording

5. Mixins. Should already be generic

6. Codegen. At the end of the settingsgen.py, we have this partly Fluent-solver-specific sequence

    from ansys.fluent.core.launcher.launcher import launch_fluent

    session = launch_fluent()
    sinfo = session._settings_service.get_static_info()
    session.exit()
    cls = flobject.get_cls("", sinfo, version=version)
    api_tree = {}
    _populate_hash_dict("", sinfo, cls, api_tree)
    _populate_classes(parent_dir)
    _populate_init(parent_dir, sinfo)
    return {"<solver_session>": api_tree}

sinfo is the abstract static info. We can add flexibility to this code by allowing applications to provide their own launch functions, but applications should also simply be able to provide their own static info provider. Then, static info could be allowed to static-schema-based, for instance.

EDIT (21/03/2024): As part of this epic, we can incorporate @h-krishnan's new infrastructure to populate autogenerated classes with static attributes. CC: @mkundu1

N.b. I want to use task lists here but I'm excluded (https://docs.github.com/en/issues/managing-your-tasks-with-tasklists/creating-a-tasklist)

[pyansys-automation]

Hello @seanpearsonuk!
This issue has been open for over a year and has had no updates in the past 8 months. If it is still relevant, please provide an update. Otherwise, consider closing it to help keep the issue tracker clean.

If this issue needs to remain open, please comment below with @pyansys-automation never close issue to prevent it from being automatically closed.

If you want this repository to be excluded from this automated maintenance process, please let us know by filling in the opt-out request form.