Add fetch og polygons from cloud using ri-cloud-api service as submodule
Current version of submodule fetches polygons from Sumo, prodviding polygons with standard results tag.
- RimContourMapPeaksCollection: clamp m_peakCount to [1,20] and m_minDistance to >= 0.0
- RigContourMapPeakFinder: assert z.size() matches nx*ny before indexing in computeProminenceAndRegionSize
Each contour map projection owns a peaks collection. Computed peaks are shown in the project tree and visualized as single-point marker polygons in the global polygon collection. Markers are deleted with their peak, copied views drop peaks sharing markers with the original, and peaks are flagged as outdated when the result, time step or value filter changes.
Add setters for line and sphere appearance on RimPolygon. Add RimPolygonCollection::updateViewsAfterPolygonsChanged(), shared with the contour map polygon tools, and a deferred variant that is safe to call from destructors.
Union-find sweep from highest to lowest value computes the prominence of each peak. Peaks are filtered on prominence and edge contact, ranked by prominence or value, and thinned by minimum distance. Flat shoulders and plateaus are rejected, and prominence is measured against the minimum of each connected data region.
roffcpp main (36c20f8) bumps its googletest FetchContent pin from
release-1.11.0 to v1.15.2, matching the bump made here for opm-parser-tests, and
updates its own build matrix to supported GitHub runners.
This removes one of the two remaining release-1.11.0 pins that would break a
CMake 4.x configure if the FetchContent declaration order ever changed. The
openzgy pin is still outstanding (CeetronSolutions/openzgy#10).
CMake 4.x on the ubuntu-26.04 runners removed compatibility with
cmake_minimum_required(VERSION < 3.5), and ThirdParty/openzgy/zfp declares
VERSION 3.1 (3.4 on Windows), so configuring fails at
ThirdParty/openzgy/zfp/CMakeLists.txt:4.
zfp is a nested submodule of openzgy pinned at 0.5.5; the first release
declaring a 3.5-or-later minimum is 1.0.0, so clearing this properly means a
major-version upgrade of a compression library and whatever API changes that
brings to the openzgy wrapper. That is worth doing on its own schedule, not as
part of a CI fix.
Pass the policy minimum instead, which is already the established approach in
this repository: ResInsightMac.yml passes the same flag, and both
x64-linux-release and x64-windows-release set it via
VCPKG_CMAKE_CONFIGURE_OPTIONS for the same reason.
A scan of every CMakeLists.txt in the repository and its submodules (excluding
ThirdParty/vcpkg/ports, which the triplets already cover) finds zfp to be the
only remaining declaration below 3.5.
ResInsightWithCache.yml is deliberately left alone: it still runs on
ubuntu-24.04, and its cmake command line feeds the buildcache hash, so adding a
flag there would invalidate the cache for no present benefit. It will need the
same flag when it moves to ubuntu-26.04.
googletest release-1.11.0 declares cmake_minimum_required(VERSION 2.8.12),
which CMake 4.x rejects, so configuring on the ubuntu-26.04 runners fails with
"Compatibility with CMake < 3.5 has been removed from CMake" at
build/_deps/googletest-src/CMakeLists.txt:4. This was previously masked: the
clang-tidy and clazy runs died earlier, during the vcpkg build.
All googletest consumers share one FetchContent declaration name, so the first
FetchContent_Declare wins and the later ones are inert. opm-parser-tests is
added at CMakeLists.txt:612, ahead of openzgy (675), roffcpp (785),
regression-analysis (794) and ApplicationLibCode (1230), so its pin is the one
that has been in effect for the whole build -- including the targets that
already ask for v1.15.2. Bumping it therefore both fixes the configure failure
and makes the build use the version the rest of the tree already declares.
None of the test directories use the *_TEST_CASE_* macros googletest removed in
1.13, so no test source changes are needed.
The remaining two release-1.11.0 pins live in the roffcpp and openzgy
submodules and cannot be changed from this repository; they are inert while the
declaration order above holds.
vcpkg builds every port in both debug and release unless VCPKG_BUILD_TYPE says
otherwise, and that variable is only read from the triplet file. The workflows
that already pass -DVCPKG_TARGET_TRIPLET/-DVCPKG_HOST_TRIPLET pointing at a
*-release triplet (ResInsightWithCache, rhel8-unit-tests, rhel8-package,
Dockerfile.rhel8) therefore skip the debug half; the remaining three did not.
clang-tidy and clazy-report passed no triplet at all and so used the plain
x64-linux triplet, building every port twice. Both only need
compile_commands.json, so the debug half was pure cost -- and it was the debug
build that failed in the ubuntu-26.04 runs: the snappy error surfaced at
"Building x64-linux-dbg", before the release half was even attempted.
ResInsightMac passed -DVCPKG_BUILD_TYPE=release on the top-level CMake command
line, which has no effect on the ports vcpkg builds, so both macOS legs were
also building debug dependencies. Replace it with the triplet pair and add
x64-osx-release and arm64-osx-release, following the existing convention of
keeping a separate release triplet rather than folding VCPKG_BUILD_TYPE into
the shared overlay so local developer builds keep their debug dependencies.
The new triplets differ from x64-osx/arm64-osx only by
set(VCPKG_BUILD_TYPE release).
Verified that each of the seven cmake invocations using the vcpkg toolchain now
sets both triplet variables, that all four *-release triplets parse and resolve
to VCPKG_BUILD_TYPE=release, and that installing a port with x64-linux-release
builds only "x64-linux-release-rel" with no debug tree.
Also correct the overlay-ports path quoted in a Dockerfile.rhel8 comment, which
the previous commit narrowed to the thrift port directory.
snappy 1.2.2, a transitive dependency of arrow, includes <immintrin.h> only
when SNAPPY_HAVE_BMI2 or SNAPPY_HAVE_X86_CRC32 is set, but MemCopy64() selects
an AVX code path on a separate condition, `defined(__x86_64__) &&
defined(__AVX__)`. The vcpkg port passes -DSNAPPY_HAVE_BMI2=OFF and
-DSNAPPY_HAVE_X86_CRC32=OFF to keep the binaries portable, so on a toolchain
whose default target enables AVX that branch is compiled with no intrinsics
header and snappy.cc fails with "'__m256i' was not declared in this scope".
This broke the clang-tidy and clazy-report workflows the first night after they
moved to ubuntu-26.04. The runner switch also changed the vcpkg compiler hash,
so the binary cache went from "Restored 103 package(s)" to "Restored 0
package(s)" and every port was rebuilt from source, which is what exposed
snappy in the first place. The bug is not GCC 15 specific: microsoft/vcpkg#51047
reports it against GCC 14.3.1. It is still present in snappy 1.3.1 and main, and
vcpkg master still ships 1.2.2 with the SNAPPY_HAVE_* options off, so neither a
baseline bump nor a port update fixes it.
Vendor the port under ThirdParty/vcpkg-overlay-ports and add
avx-immintrin.patch, which includes <immintrin.h> for the __AVX__ branch as
well. The patch cannot change the ISA baseline of the result: it only supplies
a header on a path the compiler was already going to take. Verified by
reproducing the failure locally with an overlay triplet setting
-march=x86-64-v3, confirming the patched port builds both with and without that
flag, and checking that objdump finds no AVX instructions in the library built
with the stock toolchain.
Reference the two overlay ports by their individual directories rather than by
the parent directory. The two configurations resolve different versions of both
ports (default: snappy 1.2.2#1, thrift 0.22.0; rhel8: snappy 1.2.1,
thrift 0.20.0#1), so an overlay of the whole directory would downgrade thrift
for the default builds and bump snappy for RHEL8. Dry runs of both manifests
confirm each profile now picks up only its own overlay.
The bumped port-version misses the existing vcpkg binary caches, but those
caches are already cold for the ubuntu-26.04 workflows.
- Only consider visible well paths when computing the generic view bounding box.
- Fix polygon visibility filtering so individually hidden polygons no longer contribute to the bounding box.
- The bounding box is no longer implicitly invalidated when object visibility is toggled; it now only changes on initial load or when explicitly recomputed.
- Add RicUpdateGenericViewBoundingBoxFeature, a context menu command on RimGeneric3dView that recomputes the domain bounding box from currently visible objects, updates the grid box geometry, and zooms to fit.
Based on magnesj/ResInsight#1078:
- Lift surfaceInViewCollection()/polygonInViewCollection() to virtual Rim3dView methods
- Make RimGeneric3dView scriptable as GenericView
- Add Project.create_generic_view() Python method
- RimcGridView surface/polygon methods now work on any Rim3dView
- Add Python tests and example script
- Added RimGeneric3dView, a 3D view that is not tied to any grid case,
useful for wells, surfaces and other data not requiring a reservoir
grid. The view supports a custom name.
- Introduced RimGenericViewCollection, a new top-level collection that
holds both Eclipse views and RimGeneric3dView instances. It overrides
defineUiTreeOrdering() to display both types as a single flat list
under the top-level 'Views' node.
- RimOilField now exposes a single genericViewCollection instead of a
plain eclipseViewCollection field.
- RimEclipseViewCollection is unchanged and continues to be used for
per-case and ensemble view collections.
- Updated RimEclipseCase::globalViewCollection() and related helpers to
use RimGenericViewCollection, and added matching overloads in
RicNewViewFeature for creating eclipse views from the merged
collection.
- Added RicNewGenericDataViewFeature to create a new generic data view
from the context menu.
cvf::ref<RivContourMapProjectionPartMgr> requires the type to be complete
at the point the implicit destructor is instantiated. Declaring the
destructor and defining it in the .cpp (where RivContourMapProjectionPartMgr.h
is included) avoids the incomplete-type error on clang/gcc Linux builds.
A static property with an active dynamic filter now produces a contour map per time step. Adds a synthetic ensemble fixture with unified restart files, as the OPM reader used for statistics does not support per-step restart files.
Replace the built-in formation filter with ensemble data filters. Load ensemble data filters after project read, and parent new views before assigning the case so the ensemble filter collection is resolved correctly.
The opm-common reader only reads unified restart files (UNRST). When the
opm-common reader was selected in preferences, cases with one restart file per
time step (X0000, X0001, ...) were opened without dynamic results.
- Fall back to the resdata reader when there is no unified restart file but
non-unified restart files are present.
- Unit tests using dynamic results check that the result and time step exist
before accessing them, so a missing result fails the test instead of
crashing the test executable.
The import and schedule export of simulator events are two halves of the same
workflow, so they share the "simulator-events" flag instead of having one
keyword each. Users who enabled "simulator-events-import" have to tick the new
entry once in Preferences -> System -> Experimental Features.
The schedule generated from the well event timeline can now be written to
file from the GUI, without scripting.
- RicScheduleDataGenerator::generateScheduleForTimeline() collects the dates
and wells from the timeline (honoring the last applied timestamp, never
filtering insert-date events). The Python generate_schedule() method now
calls it, so GUI and Python export the same schedule.
- New RicExportScheduleFeature "Export Schedule from Events" asks only for the
file name and uses fixed defaults: the Eclipse case of the active view (else
the first case of the project), MSW keywords for every well with events, the
first date as a comment and aligned columns.
- Available from the context menu of the well event timeline and the well path
collection, and from File -> Export, gated by the new experimental feature
"simulator-events-export".
INSERT_DATE statements are now expanded into one timeline event per
occurrence instead of a list of bare dates, so each generated date keeps
the COMMENT of its statement.
- New RimWellEventInsertDate (EventType::INSERT_DATE): a date-only event
that generates no keyword, added with
WellEventTimeline.add_insert_date_event(event_date, comment).
- The schedule generator writes the comment of an insert-date event as
"--" lines directly below its DATES keyword.
- generate_schedule(_text) no longer takes additional_dates; insert-date
events are part of the timeline, but keep the previous behavior of not
being filtered by set_timestamp().
- SimulatorEventsDocument.report_dates and ApplyReport.report_dates are
replaced by SimulatorEventsDocument.insert_date_events/insert_dates;
merging files drops insert dates repeating both date and comment.
INSERT_DATE is now a SCHEDULE event using KEY=VALUE attributes, and the file
format version is bumped to SIMEVENTS 1.2:
<date-expr> INSERT_DATE [EVERY=<duration>] [UNTIL=<date-expr>]
- EVERY takes a duration literal, DURATION variable or expression
(EVERY=1mon, EVERY=30d, EVERY=12mon, EVERY=12h) and must be positive.
Occurrence n is start + n months (clamped), then + n times the fixed part,
which preserves the dates of the previous DAY/MONTH/YEAR recurrences.
- UNTIL is an inclusive end date and requires EVERY; quote values with spaces.
- COMMENT is accepted and ignored; other attributes are rejected.
- SIMEVENTS 1.1 files and old-style INSERT_DATE lines are rejected with a
migration hint showing the rewritten line.
Importing several SIMEVENTS files together now merges them into one document
before coalescing, so keyword events with the same owner, type and timestamp
are combined across files, not only within one file.
- Add merge_simulator_events_documents, parse_simulator_events_files and
apply_simulator_events_files. Source locations carry the file name, so
conflict warnings and errors identify both files.
- Reject mismatched UNIT, and a second RESTART or duplicate WELSPECS across
files. Collect parse errors from all files in one pass.
- Warn when files declare the same FILTER name with different expressions,
and keep each file's filter instead of reusing the first one.
- CLI accepts multiple files; the import dialog allows multi-selection.
Add a test covering a flat 'realization-N/CASE.EXT' folder structure
(no iter-N level) grouped with EnsembleGroupingMode::NONE, verifying
all files end up in a single best-effort ensemble. Also add a test
confirming empty input produces no bogus ensemble entry.
RiaEnsembleNameTools::groupFilesByEnsembleName had no branch for
EnsembleGroupingMode::NONE, so it silently returned an empty map and
no ensemble was created for this grouping mode. Add handling that
groups all input files into a single ensemble.
Also surface warning dialogs instead of silently doing nothing when
no ensemble/grid ensemble could be created from the selected files,
in RicImportGridAndSummaryEnsembleFeature and
RicCreateGridCaseEnsemblesFromFilesFeature.
Increase the time resolution of the SIMEVENTS format and replace whole-day
integer offsets with Go-style duration literals.
- All DATE values are now datetimes with second resolution. A date-only
literal means midnight; a time-of-day requires the 'T' separator and
fractional seconds are rounded to the nearest second.
- DURATION values and offset terms are Go-style literals such as 5d,
12h30m, 1.5h, 3mon and -3d. Units (mon, d, h, m, s) are mandatory, must
appear in strictly descending order without repeats, and a fraction is
allowed only on the last component (never on mon or s). Unitless numbers
and the legacy DAYS suffix are rejected with hints.
- New Duration type keeps calendar months separate from the fixed
timedelta part; adding months clamps to the end of shorter months, and
str() renders the Go-style form.
- Header version bumped to 1.1; 1.0 files are rejected with a migration
hint.
- Update tests, sample .events file, example script and
docs/simulatorEvents.md.
The legacy computeCaseGroupStatistics command could not distinguish an unset list from an
empty one, so [] meant all statistics cases. Keep that in the deprecation shim.
Only a missing property in a view was a warning in the legacy command; a failed write
aborted with COMMAND_ERROR. The forwarding turned every failure into a warning. Add
RimEclipseView_exportCurrentProperty::hasCurrentProperty() so the Ricf command can
distinguish the two cases without parsing error strings.
The legacy exportMsw and exportWellPathCompletions commands relied on the export
implementation creating the folder (RicWellPathExportCompletionsFileTools::openFileForExport),
so the default <project>/completions folder worked on a fresh project. The new Rimc methods
rejected a non-existent folder up front. Create it instead, and only fail if that fails.
RicfForwarding::findCase() and findCaseGroup() resolved a negative id to the first
Eclipse result case / first case group for every legacy command. Only replaceCase and
replaceSourceCases had that behavior; all other commands rejected a missing id. Make the
lookups strict and add explicit findCaseOrFirstEclipseResultCase() / findCaseGroupOrFirst()
for the two replace commands.
Jørgen Herje
Magne Sjaastad
dependabot[bot]
Kristian Bendiksen
JJ