Reuse RimColorLegendCollection::updateColorLegend in the two roff import
sites that previously deleted and recreated the legend bound to a result,
so views referencing the legend keep their binding on re-import.
Extract the rock color matching from createColorLegendMatchDefaultRockColors
into matchDefaultRockColors so the facies branch can pass matched colors to
updateColorLegend. Remove the now-unused
RimColorLegendCollection::createColorLegend.
The boundary conditions table required several clicks in each cell before
a value could be changed, because the table view used Qt's default edit
triggers. Add an opt-in editOnSingleClick attribute to the table view
editor that starts editing on a single click and opens combo box popups
immediately, and enable it for the BCPROP keywords table.
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.
Delete the detached ensembles after rebuilding the connected editors instead of before. Updating the tree while the editors still referenced freed objects caused a use-after-free crash in PdmUiTreeItemEditor teardown. This matches the ordering used in caf::CmdDeleteItemExec.
Guard against a null wellPathGeometry() when configuring the 3D well target editor for the first target of a lateral. The parent well pointer can be non-null while its geometry is not yet available, which caused a null dereference when copying wellPathPoints().
Replace the transient Data Analytics tree label with a real
RimDataAnalyticsCollection object that owns the case-level fault distance
collection and the well target mappings. The folder shows its analytics
objects flattened and exposes a right-click menu to create a new Fault
Distance and a new Well Target Mapping.
Migrate case-level well target mappings from older project files into the
new collection via initAfterRead; fault distance is unreleased and needs
no migration. The case accessors faultDistanceCollection() and
addWellTargetMapping() now forward to the new object, and the creation
features resolve a selected Data Analytics folder.
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.
A file-based well path whose source file is missing has a null wellPathGeometry(). Add null checks at the remaining call sites that dereferenced it without one, so operations on such a well path no longer crash:
- RimWellPathGroup: skip geometry merging for a child with no geometry (grouping runs on import and project load).
- RimWellPathFracture::computeFractureDirectionNormal: return undefined when geometry is missing.
- RivWellPathPartMgr: extend the existing well path null checks to also require geometry in the attribute, well measurement, and valve append paths.
- RimCompletionCellIntersectionCalc, RicExportLgrFeature, RicCreateMultipleWellPathLaterals, RigLasFileExporter, RiuWellPathComponentPlotItem: guard the geometry before use.
Sites that were already guarded or only reachable through guarded paths were left unchanged.
When a project references an RMS well path file that no longer exists, the well path geometry is null. The MSW completion export validated the eclipse case, well path, and MSW parameters but not the geometry, so generateCellSegments asserted and crashed when triggering Export Completion Data for Visible Well Paths.
Guard the single MSW export dispatcher extractSingleWellMswData with a well path geometry null check that returns an error, protecting all export callers. Harden generateCellSegments to return empty instead of asserting on null geometry.
Also log a warning on the interactive well path import path when a file cannot be read, matching the existing project-load behavior.
Fixes#14121.
The Event Timeline stores event timestamps with full time-of-day precision, but the exported SCHEDULE deck only emitted DAY/MONTH/YEAR in the DATES keyword, dropping any sub-day precision the user had set.
Emit the optional TIME field (HH:MM:SS[.SSS]) in datesKeyword() whenever the timestamp is non-midnight, formatting with millisecond precision when present. Date-only events keep their previous DAY/MONTH/YEAR-only output. The first-date comment in the schedule generator mirrors the same time so it stays consistent with the keyword.
Select the summary plot as the current item before any menu commands are
created, so every command in the context menu operates on that plot. This is
the root fix for plot-level commands (New Analysis Plot, correlation plots,
etc.) that derive their enablement from the selected plot: previously the
selection could be left on an ensemble realization's summary case, disabling
them.
Because the plot is now selected, the Show Plot Data / Edit Plot / Split / Delete
commands resolve the plot from the selection, so passing it as user data is no
longer needed. The RicShowPlotDataCtxFeature and RicEditSummaryPlotCtxFeature
subclasses existed only to force isCommandEnabled to true for the context menu;
they are now obsolete and removed, and the menu uses the base RicShowPlotData
and RicEditSummaryPlot features directly.
Also highlight the curve under the cursor before showing the menu, giving the
same visual feedback as a left-click. Separate highlighting from selection:
extract the visual-only part of selectClosestPlotItem into
applyHighlightForClosestItem, shared by selectClosestPlotItem (left-click:
highlight + select) and the new highlightClosestPlotItem (highlight only). The
context menu uses the highlight-only path, so it does not change the selection.
Add highlightClosestPlotItemAtPosition that takes widget coordinates and
converts them to canvas coordinates internally, so the caller does not depend
on qwt headers.
The case-level Data Filters node (RimDataFilterCollection) was always shown under
RimEclipseCase, cluttering the tree when empty. Gate it in
RimEclipseCase::defineUiTreeOrdering on a new shouldBeVisibleInTree() check, and
refresh the owner case from onItemsChanged/onChildDeleted so the node appears and
disappears as the collection crosses the empty boundary.
Because a hidden node cannot be right-clicked to create the first filter, add a
RimEclipseCase::appendMenuItems override that exposes the filter-creation
commands as a Filters submenu on the case node. A shared
RicCellFilterFeatureTools::selectedDataFilterCollection() resolves a selected
RimEclipseCase to its data filter collection, so the cell, property and combined
filter create features target the case-level collection.
The view filter nodes were unified under a read-only RimFilterInViewCollection
facade, and the source collections are now tree-hidden. As a result, the
existing collection->updateConnectedEditors() calls no longer refresh the tree:
the filters are shown under the facade, which only refreshes when a source emits
filtersChanged/wrappersChanged.
Several property-filter mutations changed the child array without emitting that
signal (insertAt/push_back/erase do not auto-fire onChildAdded/onChildDeleted),
so newly created or removed filters did not appear under the Filters node:
property filter insert, new combined filter, add linked filter, undo of a
property-filter creation, and Show Contributing Wells.
Emit the change signal from these paths (via the existing onChildAdded hook, or
filtersChanged on removal) so the single facade handler refreshes the tree. The
cell-filter, paste, property-add and data-filter paths already emit the signal
and are unchanged.
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.
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.
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.
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
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.
* 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
* 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
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.
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.
Jon Jenssen
Magne Sjaastad
Kristian Bendiksen
magnesj