Strategy for removing scheme-eval

[seanpearsonuk]

A. What is it?
Scheme-eval is currently a Fluent gRPC service and is exposed as an object under PyFluent session objects. It's also used in some Ansys internal products. It allows execution of arbitrary scheme code, including functions and other symbols exposed by Fluent. That exposure seems to be unconstrained.

B. Rationale for removing scheme-eval
Scheme-eval will not form part of the Fluent API because:

1. it makes Fluent vulnerable to attack
2. it opens up Fluent for "improper use"
3. the Fluent Scheme layer cannot easily be removed or changed if exposed through an API
4. it presents an interface that cannot be reimplemented without Fluent. That's not viable in the context of Fluent componentization for cloud enablement

C. How is it used?
PyFluent depends on scheme-eval in two ways:

1. The PyFluent implementation uses it wherever there is no suitable alternative API:

• fluent_connection.py:
  • data-valid?
  • Fluent connection is passing an object that executes data-valid? into FieldData so we should add data_valid to FieldInfo/Data API in Fluent instead. I will add an issue (New FieldData/Info methods to take the load off scheme eval #1646). Another issue FluentConnection is doing all this coordination and more, which is not its job (FluentConnection class has multiple responsibilities and muddled interface #1645).
  • cx-solver-mode?
  • need to know the mode when connecting to server inside launch_fluent. That needs to be an API method that's available in both modes
  • exit-server
  • called during cleanup on exit. Needs to be an A method. Perhaps we will have a very basic Fluent API for managing the general service: exit_server, get_fluent_mode, ...
• journaling.py
  • api-start-python-journal
  • api-stop-python-journal
  • maybe these are part of the same basic Fluent API
• post_helper.py
  • client-inquire-cell-vector-functions
  • units/get-pretty-wb-units-from-dimension
  • domain-name
  • get-phase-domains
  • 'units
  • %fill-render-info
  • units/inquire-label-scale-offset-for-quantity
  • The things these are being used to implement are get_vector_fields, get_field_unit, _get_phases only for create_surface_on_server, _field_unit_quantity for create_surface_on_server and get_field_unit, _fluent_unit_info only for create_surface_on_server. Therefore, create_surface_on_server and get_field_unit and get_vector_fields are the needed services, which can be added to the existing FieldInfo/Data interfaces. I will add an issue for that
• settings.py
  • has-fnmatch-wild-card?
  • This can be done on the Python client-side - it's just using Python embedded in Scheme. I will add a specific issue for this.
• rpvars.py
  • rpgetvar
  • rpsetvar
  • cx-send 'rp-variables
  • exposure of rpvars also falls into the category of B.3 and B.4 above. Note that it was added only because we were aware that developers were home-brewing their own versions of the service. We could proceed with a staged removal of this rpvars service:
    i. deprecate client-side service. It is commented and documented as such already but we should make that more formal and log a warning on usage
    ii. move the client-side service behind a server-side API, keeping it deprecated
    iii. eventually remove the server-side API

2. It's exposed by the library and can be used as follows:

• calling some Scheme functions formally documented by Ansys. These can be considered valid usage in terms of the functionality being accessed. They imply the need to extend the remote API for at least a subset of these functions. N.b. that has already been done for meshing mode
• calling some undocumented functions. These calls are less likely to be considered valid usage. We don't need to do anything about these at the point that scheme-eval is eliminated - we would simply wait for specific requests for functionality. We have no obligation to second-guess what is currently being done

D. Staging the removal

1. Remove all scheme-eval usage from the PyFluent implementation
2. Add a deprecation warning message for all external usage. N.b. we have to do D.1 first, or else users will get hit with confusing warning messages (unless we wrap the calls from the implementation such that logging is silenced)
3. Remove scheme-eval from PyFluent

E. Implied new and extended APIs

1. A general purpose fluent API including get_mode, exit_server, start_journal, stop_journal (General-purpose Fluent service #1647)
2. New methods in FieldInfo/Data as detailed in section C (New FieldData/Info methods to take the load off scheme eval #1646)
3. Suitable distribution of documented functions, currently in Scheme format, in new or existing APIs, only accepting them where appropriate (APIs to cover deprecated scheme functions #1648)

[zouki-dev]

Interesting ! When can we expect the scheme-eval to be removed ?

I keep getting this error half of the time : Fluent Launch string: C:\Program Files\ANSYS Inc\v231\fluent\ntbin\win64\fluent.exe 3ddp -t16 -sifile="C:\Users\ARD\AppData\Local\Temp\serverinfo-hjm8a5e3.txt" -nm -hidden

[seanpearsonuk]

@zouki-dev
Interesting ! When can we expect the scheme-eval to be removed ?
I would hope within about one year.

[cons013]

As of version 26.0 is it still supported? I get an error when I run something as simple as

solver.scheme_eval.exec("(define testvar 2)")

The error is:

grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with: status = StatusCode.UNKNOWN details = "Error Occurred!" debug_error_string = "UNKNOWN:Error received from peer {created_time:"2024-11-28T16:25:40.388741069+00:00", grpc_status:2, grpc_message:"Error Occurred!"}"

Any help would be greatly appreciated, as there are some actual scheme commands I would like to run

[mkundu1]

@cons013 Please try this:

solver.scheme_eval.scheme_eval("(define testvar 2)")

Scheme eval examples - https://fluent.docs.pyansys.com/version/stable/user_guide/legacy/scheme.html