new_summary_plot() with an ensemble and an address string created an empty
plot. The address filters were applied to an empty list of summary cases, and
no curve sets were created. Use the summary cases of the ensemble, and make
sure the summary addresses are created before the address filters are applied.
Add example script showing how to create summary plots for an ensemble.
COMMENT is accepted on all keywords and is stored on the event instead of
being passed as keyword data, so it is not part of the item names reported
by opm-common. The validation error listed only the opm-common items, giving
no hint that COMMENT is allowed when a user mistyped it as COMMENTS.
Append COMMENT to the list of valid item names in the error message. Only the
diagnostic is affected, COMMENT is still handled as event metadata.
GenerateSchedule gains an AdditionalDates parameter (ISO date strings). The dates are merged, deduplicated and sorted with the event dates and each becomes a DATES keyword even when no events fall on it, ensuring a summary report at that date in Eclipse/Flow. They are deliberately not filtered by the last applied timestamp.
The ORIONEVENTS 2.0 format gains a top-level REPORT <date-expr> directive (date variables and day arithmetic supported). Parsed dates are collected on OrionDocument.report_dates and surfaced by the applier as sorted ISO strings on ApplyReport.report_dates, ready to pass to generate_schedule_text(additional_dates=...).
Add a typed FILTER declaration to the ORIONEVENTS 2.0 grammar, e.g.
FILTER POROPERM = "PORO > 0.4 AND PERMX > 100.0". A PERFORATION event
references it with FILTER=POROPERM or supplies an inline quoted
expression. When applied, each used filter is materialized as a
case-level combined data filter (one property filter per term, one-sided
inclusive bounds, AND/OR combine mode) and attached to the perforation.
Unqualified result names are searched in STATIC_NATIVE, DYNAMIC_NATIVE
then GENERATED results; a TYPE. qualifier restricts the search. Missing
results raise before any event is applied. apply_orion_document gains an
optional case= parameter defaulting to the project's first case.
RimWellEventPerf carries a RimCellFilter ptr-field with scriptable
AddFilter/cell_filter methods, and the filter is copied onto the
RimPerforationInterval when the timeline materializes completions.
Remove 95 cvf include lines that the including file does not use. Found by
extracting the symbols declared by every VizFwk header, including symbols they
re-export, and flagging includes where none of those symbols appear anywhere in
the file. Each removal is verified by a full build.
Most of them are cvfVector3.h and cvfObject.h, left behind as the files they
were once needed by changed.
pch.h is left untouched. It includes cvfObject.h and cvfVector3.h on purpose, so
that the files using the precompiled header do not have to.
Note that a clean build after removing an include does not prove the include was
unnecessary, only that the declarations still arrive some other way. That path
can differ between platforms and with RESINSIGHT_ENABLE_UNITY_BUILD, so this
needs a CI round on Linux as well.
* #14411 Enforce name uniqueness for surfaces, polygons and folders
Names must be unique among siblings sharing the same parent folder. Items in different folders may keep identical names, and comparison is case sensitive.
Siblings are the objects held by the same caf::PdmChildArrayField. Items and folders live in two distinct child arrays in caf::PdmNestedCollection, so a folder and an item may share a name under the same parent.
The Python API gets an OnNameConflict flag on AddFolder, CreatePolygon, ImportSurface and NewRegularSurface, supporting FAIL (default), AUTO_RENAME and OVERWRITE. NewSurface is left out, as grid case surfaces derive their tree label from the case and K index and carry no name of their own.
The sign of the projected formation direction vector flips with the fracture
direction normal, which follows the well drilling direction, while the fracture
azimuth defining the dip rotation in RimFracture::transformMatrix() is only
defined mod 180 degrees. Canonicalize the formation direction against the
fracture azimuth direction before computing the dip, so a positive dip means
the formation descends toward the azimuth direction.
Restore std::abs() in calculateFormationDipFromHorizontal() so the StimPlan
model formation dip (BedDipDeg in the Asymmetric FRK export) keeps the
non-negative convention from #8877.
Address review feedback on #14199: deleting and recreating the legend left
views bound to the old legend pointing at a deleted object. Add
RimColorLegendCollection::updateColorLegend and a matching UpdateColorLegend
scriptable method that mutate the existing custom legend (name and items) so
referring views keep their binding and are notified once. A new legend is only
created when none is registered for the result or the registered legend is a
standard legend.
set_discrete_property_category_names now performs a single atomic call instead
of delete + create + per-item appends. The empty-dict removal path still uses
DeleteColorLegend.
When a new Fault Distance defaults to all faults, the ResInsight-generated
undefined grid faults were ticked by default. Add RimFaultInView::isGeneratedFault
and filter these faults out of the default selection in both the UI feature and
the Python command. An explicit fault selection is still honored.
Carries the "Fault Distance" rename through to the C++ class names, file
names, PDM/scriptable keywords and the Python API (add_fault_distance,
class FaultDistance). The RicNewFaultDistanceResultFeature command class
keeps its name.
Add an align_columns option to schedule generation. When enabled, each
keyword is serialized with a '--'-prefixed column-header comment and data
rows right-aligned into fixed-width columns, instead of the compact default
form. The default output is unchanged.
A new RimKeywordFactory::deckKeywordToAlignedString introspects the OPM deck
model and renders each item in its own column (consecutive defaults are not
collapsed into 'N*'). The flag is threaded through RicScheduleDataGenerator
and exposed on the GenerateSchedule scriptable method as align_columns in the
Python generate_schedule_text wrapper.
Reparent RimFaultDistanceResultCollection so it is owned directly by
RimEclipseView instead of RimFaultInViewCollection, and show it as a
top-level node next to the Faults node in the project tree.
RimFaultDistanceResult::calculateValueOptions now reaches the fault list
through the view (the fault collection is a sibling rather than an
ancestor after the move). RicNewFaultDistanceResultFeature resolves the
view from the selection and takes both the distance collection and the
all-faults fallback from it.
The scriptable API moves with the collection: add_fault_distance_result
is now exposed on RimEclipseView (view.add_fault_distance_result(...))
via the new RimcEclipseView, replacing RimcFaultInViewCollection.
Expose the new RimFaultDistanceResult facility to Python by marking the
relevant PDM classes and fields scriptable. RimEclipseView's
m_faultCollection, RimFaultInViewCollection, RimFaultInView,
RimFaultDistanceResult, and RimFaultDistanceResultCollection are now
scriptable, so faults can be enumerated from Python via
view.fault_collection().faults().
A new Rimc method add_fault_distance_result on RimFaultInViewCollection
takes a name and a list of fault objects, creates the result
(auto-numbered FAULTDIST<n> when the name is empty), and returns the
new RimFaultDistanceResult. An empty fault list falls back to every
fault in the view, matching the static-native FAULTDIST behaviour.
Add a Python test exercising both a subset call and a parity check
that asserts the all-faults result matches the existing static-native
FAULTDIST cell-for-cell.
Some commercial simulators reject a DATES keyword whose value equals the
simulation start date. The earliest event date is, by construction, that start
date, so generate_schedule_text now emits it as a comment line (e.g.
"-- Date: 1 JAN 2024") instead of a DATES keyword by default.
The new first_date_as_comment parameter (default True) threads from the Python
wrapper through the GenerateSchedule scriptable method into
RicScheduleDataGenerator. Only the first/earliest date is affected; later dates
are always emitted as DATES keywords. Pass first_date_as_comment=False to
restore the previous behavior.
Add a completion_number parameter to the add_perf_event Python API
(AddPerfEvent scriptable method) and a matching field on
RimWellEventPerf. When a timeline perforation event is materialised into
a RimPerforationInterval, a non-zero completion number is copied across,
so it flows through the existing completion-data path onto
RigCompletionData.
The schedule generator now emits COMPLUMP alongside COMPDAT: COMPDAT
generation is folded into generateCompletionsForWell, which computes the
completion data once and builds both keywords from it via the existing
RimKeywordFactory::complumpKeyword (added in #13273). COMPLUMP only
produces records for perforations that have a completion number and is
merged across wells like COMPDAT.
Replace the include_welsegs / include_compsegs boolean flags on the
schedule-generation API with a list of wells (export_msw_for_wells) that
gates the multi-segment-well keywords. WSEGVALV and WSEGAICD are now gated
the same way as WELSEGS and COMPSEGS: all four are emitted only for wells
present in the list. An empty list (the default) suppresses MSW export for
all wells, while COMPDAT and well-control keywords are unaffected.
C++: RicScheduleDataGenerator takes a std::set<const RimWellPath*> mswWells
and generateMswForWell early-returns for wells not in the set.
RimcWellEventTimeline_generateSchedule replaces the two bool fields with a
scriptable PdmPtrArrayField<RimWellPath*>, resolved via
ptrReferencedObjectsByType().
Python: generate_schedule_text / generate_schedule expose
export_msw_for_wells (List[WellPath]) instead of the boolean flags. Updates
the well_event_schedule example and adds regression tests covering the
empty-list default, per-well selection, and WSEGVALV/WSEGAICD gating.
Replace the integer eclipse_case_id parameter on
RimcWellEventTimeline_generateSchedule with a
caf::PdmPtrField<RimEclipseCase*>. The execute() method no longer needs
to walk the project tree and look up the case by ID — the gRPC layer
resolves the object pointer for us.
generate_schedule_text passes the Eclipse case object through to the
underlying generate_schedule call, matching how add_perf_event /
add_well_keyword_event already take a WellPath object rather than an
ID.
Add include_welsegs and include_compsegs flags (default True, preserving
current behaviour) to the schedule-generation API. Plumbed through
RimcWellEventTimeline_generateSchedule -> RicScheduleDataGenerator ->
generateMswForWell, gating only the WELSEGS / COMPSEGS merge calls.
WSEGVALV and WSEGAICD are unaffected.
Python: generate_schedule_text gains include_welsegs / include_compsegs
keyword arguments that forward to generate_schedule. Callers wanting
control-only / well-header-only schedule updates can now suppress the
verbose MSW table blocks.
Schedule-level keywords whose OPM ParserRecord is a single ALL-sized item
(RPTRST, RPTSCHED, ...) are not positional — they take a free-form list
of mnemonic tokens like `BASIC=2 DEN ROCKC NORST=1`. Previously each
`keyword_data` entry became its own DeckItem, and OPM emitted them
either as truncated positional values or as a quoted, space-collapsed
single string.
Detect that schema shape in `RifEventKeywordFormatter::formatKeyword`
and pack the user's entries into one RawString DeckItem of mnemonic
tokens: `KEY` for FLAG items, `KEY=VALUE` otherwise.
To distinguish flag mnemonics (`DEN`) from `KEY=1`-style entries, add a
new `FLAG` value to `RimWellEventKeywordItem::ItemType` plumbed end to
end (Python -> GRPC -> Rimc -> storage -> formatter). The Python API
now maps `bool True` to FLAG and silently drops `bool False`.
For positional keywords (WCONHIST etc.) FLAG items have no value to
emit and are rendered as default markers ("1*").
A `rawStringItem` helper is added to `RifOpmDeckTools` so the
mnemonic-list path can produce DeckItems whose OPM output is not
quoted.
* CMake: Remove dead CODE_HEADER_FILES variable
* CMake: Remove dead COMMAND_CODE_HEADER_FILES and COMMAND_MOC_SOURCE_FILES
* CMake: Remove dead MOC_SOURCE_FILES and FORM_FILES_CPP references
* CMake: Remove dead HEADER_FILES reference
* CMake: Delete unused CustomPCH.cmake superseded by target_precompile_headers
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.
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.
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.
Adds case.filtered_cells(filter, time_step, grid_index) which applies any
RimCellFilter to an Eclipse case and returns a per-cell 0/1 mask. The mask
length and ordering match case.grid_property(..., grid_index), so callers
can combine the two vectors element-wise.
Implemented as a scriptable Rimc method (PdmVoidObjectMethod) on
RimEclipseCase that writes the mask via the existing key-value store, with
a thin Python wrapper mirroring the visible_cells() pattern. No proto or
gRPC service changes.
Lets a script attach a cell filter to a RimPerforationInterval as a
typed reference so subsequent work can gate completion-export
connections by the filter's cell mask. Pure metadata in this commit:
no consumer of RimPerforationInterval is modified, the field exists
purely as an API surface.
Add a non-scriptable caf::PdmPtrField<RimCellFilter*> m_cellFilter to
RimPerforationInterval with public cellFilter()/setCellFilter()
accessors and a "Cell Filter" group in the property panel between the
existing geometry/flow group and the Date Settings group. The field is
deliberately non-scriptable: a scriptable PdmPtrField round-trips in
Python as an opaque "ClassName:0xADDR" string rather than a resolved
object, defeating the point. Two CAF object methods on
RimcPerforationInterval expose the relationship:
- AddFilter (perf.add_filter(filter)) sets the pointer; replaces any
existing filter (single filter per perforation).
- cell_filter (perf.cell_filter()) resolves to the referenced
RimCellFilter object on read, mirroring the valve.template() pattern.
Composition stays in RimCombinedFilter: a script that wants AND/OR
across multiple filters attaches a combined filter as the single
filter on the perforation.
The Python example in PythonExamples builds a case-level AND combined
filter (PERMX 100..20000 AND K=5..10), creates a modeled well path
with two perforation intervals, and shares the same filter between
them. test_perforation_filter.py covers single-set, replace-on-second-
add, and shared-pointer round-trips.
Combined filters used to always show whatever literal string the user
passed in (or the default "Combined Filter"). For programmatic creation
without a name, that string never reflected the children, leaving the
case-level "Data Filters" tree row stale when child bounds changed.
Add an m_autoDeriveName flag (default true) to RimCombinedFilter. When
on, the display name is recomputed on every relevant change — addFilter,
removeFilter, onChildAdded, onChildFilterChanged, and combineMode
toggle — by joining children's name() with " AND " / " OR ". The flag
flips to false the first time the user renames the filter via the UI
property panel or via Python (combined.user_description = "..."),
preserving any explicitly typed name verbatim from then on.
Two child-creation paths needed an extra triggerFilterChanged() so the
combined parent recomputes after the child's final name is set:
addPropertyFilterToCombinedFilter (setDefaults updates name without a
signal) and RimcCombinedFilter_addRangeFilter (Rimc applies user
params after addNewFilter).
The Rimc factory passes setAutoDeriveName(false) only when a name is
supplied. The Python example demonstrates both modes side by side, and
test_combined_filter.py adds three cases: named filter preserves its
name, auto-derived filter tracks bound mutations, and Python rename
locks the auto-derived filter.
Expose the case-level RimDataFilterCollection (introduced for
case-shared cell filters) to Python so scripts can build combined
filters with property-filter and IJK-range children without going
through a view.
Scriptable surface:
- RimEclipseCase.m_dataFilterCollection -> case.data_filter_collection()
- RimDataFilterCollection (object + Filters child array) -> filters()
- RimEclipsePropertyFilter (object + m_lowerBound + m_upperBound) ->
pf.lower_bound, pf.upper_bound
- RimCellRangeFilter (object + start_index_{i,j,k}, cell_count_{i,j,k})
New CAF object methods under ProjectDataModelCommands/:
- RimcDataFilterCollection: add_combined_filter(name, combine_mode)
- RimcCombinedFilter: add_property_filter(result_variable, result_type)
and add_range_filter(name, start_{i,j,k}, cell_count_{i,j,k}).
Bounds are not part of add_property_filter because the Python class
generator emits a bare nan literal as the default for double fields
initialised to quiet_NaN, which fails to import. Bounds are set via
the now-scriptable lower_bound/upper_bound fields after creation,
matching the update() pattern used elsewhere in the API.
RicEclipsePropertyFilterFeatureImpl::addPropertyFilterToCombinedFilter
now returns the new RimEclipsePropertyFilter* so the CAF method can
hand it back to Python. setDefaults is relaxed to be view-tolerant:
case-level filters have no Rim3dView ancestor and the eclipse case is
already wired by RimEclipsePropertyFilter::setCase via the owning
collection's onItemsChanged hook.
End-to-end coverage in tests/test_combined_filter.py: round-trip
create, mode toggle, property-filter add/mutate, range-filter
add/mutate. Example script in PythonExamples builds an AND combined
filter that gates PERMX between 100 and 20000 against a K=5..10
slice.
Replace the dynamic_cast dispatch in RimPolygonCollection::loadData() with a
virtual loadData() on RimPolygonContainer. The base recurses through
subCollections; RimPolygonFile overrides to load file data. The folder
RimPolygonCollection no longer needs its own loadData().
Move RimPolygonFile::canAddSubCollection() and RimPolygonInView::sourceItem()
implementations from headers to .cpp.
Simplify std::unexpected calls in RimcNestedCollectionBase by removing
redundant explicit QString construction.
Port RimSurfaceCollection, RimPolygonCollection and the polygon-in-view
side onto the new caf::PdmNestedCollection framework, replacing the
per-class folder plumbing (m_subCollections field, topmost-folder flag,
add/remove/find sub-collection, factory, "new folder" command) with the
shared base.
- RimSurfaceCollection and RimPolygonCollection now derive from
caf::PdmNestedCollection. Each constructor uses the generic folder
icon and exposes a static createTopmost() that marks the top instance
and applies the branded domain icon; RimOilField calls the factory.
- RimPolygonInViewCollection uses the new RimNestedMirrorCollectionInView
helper, and a new RimPolygonContainer carries the source-side polygon
link.
- RicNewSurfaceCollectionFeature is removed; the generic
RicNewNestedCollectionFeature drives the "Add Folder" action against
both collections.
- Update callers (RimAnnotationCollection, RimEnsembleSurface, polygon
command features) and the scripting wrapper (RimcSurfaceCollection),
plus the Python add-folder binding and polygon test.
Generalise the per-domain "Add Folder" command and the scripting-side
add-folder method so they work against any container that exposes
caf::PdmNestedCollectionBase.
- RicNewNestedCollectionFeature: command feature that walks the
selected PdmObject up to the nearest PdmNestedCollectionBase ancestor
and calls addNewSubCollection(). Hidden via canAddSubCollection() for
leaf containers.
- RimcNestedCollectionBase: scripting wrapper exposing the same
add-sub-collection action through the Python interface, so generated
Python bindings get the operation for free on every derived class.
Neither is wired to a concrete collection yet; the per-domain features
remain in place until the migration commit replaces them.
Expose well logs attached to a well path through the Python API. A new
`well_path.well_logs()` returns the list of well logs, and each
`WellLog` gains `channel_names()` and `well_log_data()` for reading
channel names, measured depth, optional TVD MSL/RKB, and channel
values.
The read methods are registered on the abstract `RimWellLog` base
class and use the common `RigWellLogData` interface so they work for
imported, LAS and OSDU well logs alike.
Expose RimColorLegendCollection and RimColorLegend to Python via
CAF_PDM_OBJECT_METHOD entries that let callers create a legend, append
category items with a hex-string color, bind a legend to a (case,
resultName) pair and delete that binding.
Scriptable fields on RimColorLegend and RimColorLegendItem make the
created objects inspectable from Python.
The (case, resultName) binding interface in RimColorLegendCollection,
RimRegularLegendConfig and RimEclipseCellColors now takes a const RimCase*
instead of a case id, matching the caller patterns and avoiding ambiguity
when multiple cases share an id domain.
Replace the monolithic RigNonUniformRefinement class with a proper
polymorphic hierarchy: RigRefinement (abstract base), RigNoRefinement
(identity), RigUniformRefinement (O(1) uniform), and
RigNonUniformRefinement (per-cell custom fractions).
Ownership uses std::unique_ptr<RigRefinement>, consumers receive
const RigRefinement&. This eliminates the misleading class name,
removes effectiveRefinement() indirection, and gives each refinement
mode an appropriately optimized implementation.
Kristian Bendiksen
Jørgen Herje
Magne Sjaastad
Jon Jenssen
kriben