14001 python discrete grid property#14034
Open
kriben wants to merge 6 commits into
Open
Conversation
magnesj
approved these changes
May 22, 2026
Member
magnesj
left a comment
There was a problem hiding this comment.
Some clang-format fixes to be applied before merge
d0f1753 to
2df2b42
Compare
…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.
2df2b42 to
8652849
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #14001.