Skip to content

14001 python discrete grid property#14034

Open
kriben wants to merge 6 commits into
devfrom
14001-python-discrete-grid-property
Open

14001 python discrete grid property#14034
kriben wants to merge 6 commits into
devfrom
14001-python-discrete-grid-property

Conversation

@kriben
Copy link
Copy Markdown
Collaborator

@kriben kriben commented May 22, 2026

Fixes #14001.

Copy link
Copy Markdown
Member

@magnesj magnesj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some clang-format fixes to be applied before merge

@kriben kriben force-pushed the 14001-python-discrete-grid-property branch from d0f1753 to 2df2b42 Compare May 22, 2026 12:24
kriben added 6 commits May 22, 2026 14:59
…ategory mapping

Add the inverse APIs to the existing discrete-property setters:

- case.property_data_type(property_type, property_name) returns "FLOAT" or
  "INTEGER", matching the data_type flag passed to set_active_cell_property
  / set_grid_property.
- case.discrete_property_category_names(property_name) and
  case.discrete_property_category_colors(property_name) return the
  {int: str} mappings previously bound via
  set_discrete_property_category_names, or empty dicts when nothing is bound.

Implemented as PdmObjectMethods on RimEclipseCase and
RimColorLegendCollection so the bindings surface automatically through
generated_classes.py.
The auto-generated stub returns a DataContainerString, forcing call
sites to use .values[0]. Add a hand-written wrapper on Reservoir
(which both EclipseCase and the other reservoir types inherit from)
that unwraps the single-value container and returns the typed
PropertyDataType so a caller can simply write

    case.property_data_type(...) == rips.PropertyDataType.INTEGER

Update the round-trip tests to use the cleaner form.
Replace the hand-written PropertyDataType wrapper with first-class enum
return support in the code generator. Scriptable methods that derive
from the new caf::PdmEnumObjectMethod<T> template return a typed enum
value across the gRPC boundary; the Python generator emits a StrEnum
class with the texts pulled from the underlying caf::AppEnum<T> and
wraps the call site so callers receive `EnumClass(value)` directly.

caf::PdmDataContainerEnum is the small PdmObject the framework uses to
carry the enum text on the wire (single scriptable QString field).
RimcEclipseCase_propertyDataType becomes declarative: implement
executeEnum() returning the typed RiaDefines::ResultDataType and pick a
returnEnumScriptName() — the base handles serialization and reports
the four AppEnum members (UNKNOWN, FLOAT, DOUBLE, INTEGER) to the
generator.

Drop the hand-written PropertyDataType in enums.py — the generated one
in resinsight_classes is wire-equivalent and now the single source of
truth.
…xample

Show how property_data_type, discrete_property_category_names, and
discrete_property_category_colors round-trip the values just written by
set_active_cell_property + set_discrete_property_category_names.
…pertyType

Consolidate the hand-written PropertyType / NNCPropertyType enums in
enums.py into the auto-generated StrEnum classes that already exist in
generated_classes.py. enums.py and all its imports are removed.

The auto-generated class for caf::AppEnum<RiaDefines::ResultCatType>
was named "ResultType" because the existing scriptable m_resultType
fields used keyword "ResultType". Switch those fields to
CAF_PDM_InitScriptableFieldWithScriptKeywordNoDefault, keeping the XML
keyword "ResultType" (so project files still load) but exposing the
script keyword as "PropertyType". The generator now emits a single
PropertyType StrEnum that:

- matches the proto PropertyType for setters (FLOAT/INTEGER aside, the
  members callers actually use are identical),
- gains ALLAN_DIAGRAMS that the C++ side already knew about,
- loses the proto-only REMOVED/UNDEFINED sentinels (unused in any
  Python caller).

rips.NNCPropertyType was exported but unreferenced anywhere — dropped.

Updated Python callers:
- rips.ResultType.X -> rips.PropertyType.X across examples and tests.
- result_type= kwarg / .result_type attribute -> property_type /
  .property_type (the script keyword change renamed those everywhere
  the affected PdmObject fields are accessed from Python).
- view.apply_cell_result's hand-written wrapper now takes property_type
  instead of result_type and forwards via cell_result.property_type.

All 271 Python tests pass, ruff and clang-format clean.
Replace QString + setFromText parsing with typed
caf::PdmField<caf::AppEnum<...>> for m_propertyType and m_porosityModel
on RimcEclipseCase_propertyDataType. The script keywords stay
"PropertyType" / "PorosityModel" so the Python parameter names are
unchanged (property_type, porosity_model), and the auto-generated
StrEnum classes are now PropertyType and PorosityModelType (typed
annotations on the call site).

Register caf::AppEnum<RiaDefines::PorosityModelType> -> "PorosityModelType"
alongside the existing ResultCatType override so PorosityModelType's
auto-generated class name is stable regardless of which field the
generator visits first.

executeEnum() drops the setFromText parsing and the "Invalid property
type / porosity model" branches — the values now flow through typed
already, so an invalid enum text cannot reach the method body.
@kriben kriben force-pushed the 14001-python-discrete-grid-property branch from 2df2b42 to 8652849 Compare May 22, 2026 12:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

python: Improve API for discrete grid property

2 participants