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.
* Refactor: add MACOSX_BUNDLE option to qt_add_executable in multiple CMakeLists.txt files
* #14045 macOS: Guard std::stacktrace usage and skip ucontext on Apple platforms
* #14045 macOS: Guard std::ispanstream with std::istringstream fallback
* #14045 macOS: Add vcpkg overlay triplets for osx and exclude grpc on osx
* #14045 macOS: CMake macOS build support and openzgy OpenMP-disable patch
* #14045 CI: Add macOS build workflow
* #14045 macOS: Use feature-test macros to detect <stacktrace> and <spanstream>
* #14045 macOS: Make MAX_STIMPLAN_LAYERS constexpr to fix arm64 link error
* #14045 CI: Ship README-macOS.txt with artifact to document Gatekeeper workaround
* #14045 CI: Pin macOS runner to macos-14 and set deployment target to 14.0
* #14045 CI: Move macOS runner to macos-15 and fix README step on configure failure
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.
The existing FAULTDIST result always considered every fault in the main
grid. Users with many faults need to compute distance fields against a
named subset, so this adds a Fault Distance Results collection under
each view's Faults node. Each entry holds a multiselect of faults and a
name (FAULTDIST1, FAULTDIST2, ...) and publishes the result into the
Generated cell-result category.
The per-cell BVH-based distance loop was extracted from
RigFaultDistanceResultCalculator into a reusable utility that accepts
the subset of faults to include; the original all-faults entry point
delegates to the same utility and keeps the static-native FAULTDIST
behavior unchanged.
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.
Well disks are flat, zero-thickness discs drawn at a fixed elevation above each
well head. When the disks of different wells overlap horizontally they end up
coplanar at the same depth and z-fight.
Offset each disk along Z by a small per-well amount derived from the stable
resultWellIndex(), scaled by arrowLength so the spacing tracks the disk scale and
view zoom. Coincident disks fan out into a readable vertical stack instead of
fighting.
On project reload the simulation well disks were not drawn until the user
toggled the Simulation Wells visibility. Two load-ordering issues caused this:
scaleWellDisks() ran before synchronizeWellsWithResults() had populated the
wells list, so it iterated an empty collection. It also bailed out early on the
transient m_showWellDisks aggregate (disableIO), which is only synced from the
restored per-well states when the property panel is built.
Move scaleWellDisks() after synchronizeWellsWithResults(), and sync the
visibility checkbox state at the start of scaleWellDisks() so the disks are
scaled and marked valid before the first display-model build.
Normalize disk radius over all wells instead of only the currently
visible ones. Computing the min/max range over visible wells only made
one well's disk radius depend on whether unrelated wells were filtered
out, so toggling a range filter on one well changed another well's disk.
Fixes#14083.
The well list driving schedule generation originates from a
std::set<RimWellPath*>, so it was ordered by pointer address and the
per-well keyword records (WELSPECS, COMPDAT, COMPLUMP, MSW keywords, well
control) came out in a non-deterministic order that only looked sorted by
coincidence.
Sort the well list once by the deck export name in generateSchedule, so
every per-well keyword is emitted in a stable, well-name-sorted order,
matching the convention already used by the file-based completion export.
Schedule-level keywords (GRUPTREE, RPTRST, TUNING) are left untouched.
buildKeyword placed every user-supplied item into a single DeckRecord,
so multi-record keywords such as TUNING (3 records, each terminated by
its own '/') were emitted with only one record/slash and rejected by the
simulator.
Distribute items across the keyword's records using the OPM ParserKeyword
schema: each item is matched to the record that defines it. Every record
is emitted (empty records are written as a bare '/') so the schema's
record structure is preserved, and items unknown to the schema are now
reported via a warning. Single-record keywords keep their previous
behaviour, including appending non-schema items after the canonical
block.
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.
WELSEGS and COMPSEGS carry a per-well header record followed by that
well's segment records, so segments from different wells cannot share a
single header. Commit 6ef024c merged records of the same keyword across
wells, which is invalid for these two keywords.
Accumulate WELSEGS and COMPSEGS as separate per-well blocks in a
dedicated container and serialise each block individually, while the
remaining keywords (WELSPECS, COMPDAT, WSEGVALV, WSEGAICD, well-control
and schedule keywords) continue to merge. Emission preserves the
existing priority ordering.
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.
* Agent docs: Recommend cmake --build over ninja when sharing build/ with Visual Studio
* Disable Create Well Target Mapping for grid ensembles with individual grids
* Move RimSummaryCaseMainCollection context menu items into appendMenuItems override
* Reorganize import menus: split per-window, group submenus, rename actions, add Import/Export icons
* Show icons on "New Statistics Case" and "New Grid Case Group" menu actions
* Rename grid/summary import submenus to "More" and use the import icon
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.
The schedule generator previously concatenated full keyword blocks
(`KEYWORD ... /\n/\n`) — one per well — producing verbose output where
each WELSPECS / COMPDAT / WCONHIST / WELSEGS / COMPSEGS / etc. block
appeared once per contributing well. Eclipse keywords are designed to
hold multiple records under a single header; the per-well repetition is
syntactically valid but bloats the file and obscures intent.
Switch `RicScheduleDataGenerator` to accumulate
`std::map<QString, Opm::DeckKeyword>` instead of raw concatenated text.
Each per-well helper now returns an `Opm::DeckKeyword`, and a new
`mergeKeyword` primitive appends its records into the accumulator entry,
creating the entry from the helper's keyword on first encounter. At
emission time each accumulated keyword is serialised once.
To support this, `RifEventKeywordFormatter` is split: each `format*`
QString function now wraps a corresponding `build*` function that
returns `std::optional<Opm::DeckKeyword>`. `RimWellEventKeyword` and
`RimKeywordEvent` expose a parallel `generateDeckKeyword` accessor.
The text-scraping `extractKeywordName` helper becomes dead code and is
removed.
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.
`add_well_keyword_event` previously emitted items in `keyword_data` dict
insertion order. Eclipse keywords such as WCONHIST are positional, so a
non-canonical order silently corrupted the simulator input.
`RifEventKeywordFormatter::formatKeyword` now walks the OPM
`ParserRecord` schema and emits items in canonical order, inserting
`1*` defaults for intermediate gaps and dropping trailing unspecified
items. Items that are not part of the keyword schema (e.g. mnemonic-list
keywords like RPTRST/RPTSCHED) are appended after the canonical block in
caller-supplied order to preserve existing behaviour.
Fixes#14065.
Adds a collection-level checkbox in the simulation well "Visibility"
group that hides wells which are not open at the current time step.
Mirrors the existing "Wells Through Visible Cells Only" sibling toggle
in placement, default (off), and contour-map gating.
The frame-aware predicates isWellPipeVisible, isWellSpheresVisible,
isWellValvesVisible and isWellDiskVisible now short-circuit to false
when the toggle is on and RigSimWellData::isOpen(frameIndex) is false,
placed before the active-intersection bypass so the user's filter is
not overridden.
Fixes#13913
Production disks were drawn for wells that the visible-cells filter
hides, because RimSimWellInView::isWellDiskVisible() never consulted
the showWellsIntersectingVisibleCells toggle.
Add a frameIndex parameter and the same active-intersection / visible-
cells filter logic that isWellPipeVisible already uses, and update the
two call sites to pass the current frame.
* 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.
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 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.
Changing the time step filter combo box crashed when the plot had no
available time steps: filteredTimeStepIndices returned an empty vector
and .back() invoked undefined behaviour. Skip the m_timeStep assignment
when either allDateTimes or filteredTimeStepIndices is empty.
Fixes#14006.
The case-level RimDataFilterCollection lacked an equivalent of
RimEclipsePropertyFilterCollection::loadAndInitializePropertyFilters, so a
saved FORMATION_NAMES selection had its value preserved on reload but no
category options list to render against. The selection only appeared after
the user toggled the filter, which routes through fieldChangedByUi and
rebuilds the category cache. Add loadAndInitializeFilters and invoke it
from RimEclipseView::onLoadDataAndUpdate, once openReservoirCase has loaded
the grid and active formation names.
* Completions: Apply perforation cell filter to COMPDAT and MSW export
* PerforationInterval: Limit Cell Filter dropdown to case-level filters
* PerforationInterval: Prefix Cell Filter entries with case name when multiple cases
* Completions: Use std::format for cell filter suppression log messages
Adds a new HUD label in the upper-left of the 3D view that reads
"Filter : <name(s)>" whenever a cell, property, or per-view data
filter is active. The label is hidden when nothing is enabled.
Names are joined per the source collection's AND/OR combine mode, and
contributions from different collections are concatenated with ", ".
On Eclipse views the unified RimFilterInViewCollection is used as the
single anchor; GeoMech views aggregate cell and GeoMech property
filters directly.
When the user toggles "Show Curve" off, updateCurvePresentation runs
updateCurveVisibility, which detaches and deletes m_plotCurve, before
calling updateCurveAppearance. The override in RimWellFlowRateCurve
dereferenced m_plotCurve unconditionally and crashed. Match the null
guard already present in RimPlotCurve::updateCurveAppearance.
Fixes#14011.
Nested Qt event processing during toolbar clearing can trigger
performUpdate while the visible-index-to-position mapping is out of
sync with the current visible plot widgets. The lookup lambda in
alignAxis previously asserted on a miss, calling abort() which the
SIGABRT handler reported as a crash. Return std::optional and skip
widgets without a mapping entry instead, matching the defensive
null-pointer style used elsewhere in this file.
Fixes#14008.
The CVF_ASSERT on the wellPathGeometry pointer aborted release builds
before the existing null check could return gracefully. A well path
without resolved geometry is a valid state, so drop the assert and let
the early return handle it.
Fixes#14010.
Three fixes from PR review on the data-filters refactor.
RimDataFilterInViewCollection::syncWithSource: avoid double-free on
project load when m_sourceCollection has not yet resolved. The first
pass deletes orphan wrappers but leaves them in the local snapshot;
the null-source branch then deleted them again. Replace the second
deletion with deleteChildren() on the wrapper field.
RimDataFilterInViewCollection::setSourceCollection: disconnect from
the previous source's filtersChanged signal before reassigning, so
edits to a previously-bound case no longer trigger spurious geometry
regen on this view.
RimEclipsePropertyFilter::fieldChangedByUi: always emit
triggerFilterChanged() after updating bounds and related fields.
Otherwise, when the property filter lives inside a combined filter
under a per-view RimEclipsePropertyFilterCollection, the combined
parent's auto-derived display name was never recomputed.