Register a 'workflows' experimental feature and gate the taskmaestro Workflows
UI behind it, following the registry pattern from #14081. The Workflows tree
collection is only added in RimProject::defineUiTreeOrdering when the feature is
enabled, and RimWorkflowCollection::rescanWorkflows() skips the eager discovery
scan (and its per-workflow Python introspection) when disabled.
Discover taskmaestro workflows under ~/.taskmaestro/workflows/ and surface
them as a "Workflows" collection in the project tree alongside Scripts.
Each workflow's task input schema is auto-generated by introspecting the
Pydantic models via a Python helper (rips.taskmaestro_helper) and rendered
as PDM field bindings - scalars for str/int/float/bool, and PdmPtrField
pickers for fields typed as rips.Case / rips.WellPath / rips.View.
The Run button on a RimWorkflow writes input.yaml from current bindings
(rips object references serialized as __resinsight_ref__ maps), spawns
the helper's run subcommand, and streams output to a modeless log dialog.
The helper resolves __resinsight_ref__ markers back to live rips objects
via the running ResInsight's gRPC server before driving taskmaestro.
- Camera::fitView/computeFitViewEyePosition: derive one corrected, non-parallel up vector and use it consistently for right, upNorm, planeTop and the final setFromLookAt(), instead of only repairing the right vector. Previously the degenerate (parallel dir/up) case still produced a singular view matrix because up itself was never corrected. Added a regression test exercising fitView() end-to-end (not just computeFitViewEyePosition()) that checks the resulting direction/up/right form a valid orthonormal basis.
- RimViewController::updateCameraLink/updateTimeStepLink: guard against ownerViewLinker()->masterView() being null (RimViewLinker::setMasterView(nullptr) is a supported state), not only against a null view linker.
- RicHistogramPlotTools: use RiaGuiApplication::isRunning() before calling RiaGuiApplication::instance(), since instance() itself asserts when there is no running GUI application.
- RimDockWindowController::updateViewerWidget: create the view widget before the dock widget, so a failed view-widget creation does not leave a dock widget allocated without a dock manager (which deleteDockWidget() cannot clean up).
- RimStimPlanModelCalculator::calculateFormation: avoid continue via a small lambda, and reject double values outside the range of int before the static_cast to avoid undefined behavior.
- Fix out-of-bounds vector access in calculateFormation when an index derived from curve data falls outside formationNamesVector, including when the value is invalid (NaN/inf) or negative.
- Initialize m_stimPlanModel to nullptr in the constructor; it was previously left uninitialized until setStimPlanModel() was called.
- Guard all entry points that dereference m_stimPlanModel directly (extractCurveData, calculateLayers, findCurveAndComputeLayeredAverage, findCurveAndComputeTopOfLayer, calculateStressWithGradients, calculateTemperature, calculateFacies, calculateFormation) and return a safe default/log an error when it is null.
- Bounds-check findValueAtTopOfLayer/findValueAtBottomOfLayer against both the layer index and the underlying values vector, returning quiet_NaN instead of out-of-bounds access or a thrown exception from vector::at().
- Guard computeAverageByLayer against out-of-range indices and empty layers (division by zero), returning 0.0 for empty layers instead of NaN/inf.
dir^up becomes a zero vector when the view direction and up vector are parallel, producing an invalid zero-normal plane. Plane::distanceToOrigin() then asserts/aborts (CVF_ASSERT, always active). Fall back to an arbitrary axis to compute a valid right vector in this degenerate case.
Guard all public entry points against null plot/data-source/curve/ensemble arguments, null-check RiaGuiApplication::instance() and RimMainPlotCollection::current() before dereferencing, and skip null curves/data sources when collecting existing data sources.
RimViewController::masterView() dereferenced ownerViewLinker() without a
null check, causing a crash when the controller has been detached from
its RimViewLinker parent (e.g. mid-destruction, after the owning
child-array field has already erased it but before delete runs).
The same unguarded ownerViewLinker() dereference existed in several other
methods: isActive(), isCameraLinked(), isTimeStepLinked(),
isResultColorControlled(), isLegendDefinitionsControlled(),
isPropertyFilterOveridden(), updateOverrides(),
updateDuplicatedPropertyFilters(), updateCameraLink(),
updateTimeStepLink(), updateResultColorsControl(),
updateLegendDefinitions() and applyCellFilterCollectionByUserChoice().
All now store ownerViewLinker() in a local and null-check it before use,
matching the pattern already used in isCellFiltersControlled().
Guarded two unconditional null derefs: dockWidget->setWidget(viewWidget) when viewWidget creation fails, and viewPdmObject() in handleViewerDeletion() when no view has ever been assigned to control. Added regression test for the handleViewerDeletion() case; the setWidget() path requires a running GUI/main window and isn't reachable from the headless unit test harness.
synchronize2dIntersectionViews() could crash in two ways: when the view's ownerCase() is null, and when the collection has no Rim3dView ancestor at all (e.g. mid-destruction after detaching from the PDM tree, where firstAncestorOrThisOfTypeAsserted<Rim3dView>() returns null since CAF_ASSERT is compiled out in release). Both cases are now guarded.
A system HDF5 reports /usr/include. CMake filters implicit dirs from
target include directories but not from the source-file
INCLUDE_DIRECTORIES property, so -I/usr/include reached the command line
and broke #include_next <math.h> in <cmath> on gcc-toolset.
RigConnectionContainer was a thin wrapper around std::vector<RigConnection> with no added value beyond push_back/reserve/remove_duplicates. Replace it everywhere with std::vector<RigConnection> and inline the remaining container-merge and deduplication logic at their single call sites.
The NNC geometry computation now only tests candidates in the neighbor pillar column for I/J fault faces, intentionally producing fewer NNCs (edge contacts and small non-zero-area overlaps outside the column are no longer generated). Update the test assertion from 3416 to 3345 to match.
RigConnection had user-defined copy operations and no move operations, so
sorting in remove_duplicates() and merging connections copied the polygon of
every connection.
- Remove the member-wise copy operations, so the implicit noexcept move
operations are used.
- Take the polygon by value and move it into the connection.
- Add move overloads of RigConnectionContainer::push_back(), and use them when
collecting the computed connections.
- Avoid copying each native connection when building the set of cell pairs.
Computing additional NNCs spent most of its time running quad overlap tests on
candidate cells outside the neighbor pillar column. Most of these touch the
fault face along an edge only. Restrict candidates for I and J faces to the
neighbor column. This intentionally skips a small number of non-zero area
overlaps outside the column.
- Return std::expected from RimSurfaceCollection::importSurfacesFromFiles
with a message naming the files that could not be imported
- Return specific errors from ImportSurface and NewSurface scripting
methods instead of nullptr
- Import before deleting the surface to overwrite, so a failed overwrite
keeps the existing surface
- Catch surfio exceptions in RifSurfio to avoid a crash on corrupt files
- Include the method name in the generic "no result" gRPC error
- Add Python tests for import_surface error handling
* Add publish-dev-build job to distribute dev builds to OPM/ResInsight-Builds
* Limit publish-dev-build to schedule and workflow_dispatch events
* Distribute dev builds to CeetronSolutions/resinsight-builds instead of OPM/ResInsight-Builds
* Shorten comments in publish-dev-build job
* #14806 Faults: Compute unnamed fault faces in parallel and only from positive faces
- A negative I or J face is the positive face of the neighbor cell with a lower
index, and is already handled when that neighbor is processed. Only visit the
positive faces.
- Each cell only writes the fault index of its own positive faces and the
opposite faces of its neighbors, so process the cells in parallel. The
thread results are appended in thread order, so the fault faces keep the
same order as before.
* #14806 Faults: Add unit tests for parallel unnamed fault face computation
Build a small in-memory grid (no file, no view) with geometric faults at
every I interface, and verify that calculateFaults() finds all unnamed
fault faces, keeps them ordered by native cell index (the per-thread
results are appended in thread order), and separates faces touching an
inactive cell into the dedicated inactive fault face list.
Building the cell search tree was dominated by one small std::vector<int>
allocation per leaf, and a tree with one cell per leaf becomes very deep for
large grids.
- BoundingBoxTree: Store leaf ids in flat arrays, and move the input data
instead of copying it. The tree shape is unchanged. Queries no longer copy
the ids of each leaf.
- RigMainGrid: Always group at least 8 cells along K in each leaf.
findIntersectingCells() removes cells not intersecting the query bounding
box, so the result is the same set of cells as for a tree with one cell per
leaf. This also applies to very large grids, which previously got the
cells of the whole leaf.
- Include cells of nested LGRs and LGR cells in invalid main grid cells in
the grouped tree, as the previous tree with one cell per leaf did.
Fixes a set of related bugs affecting ensemble contour maps that use a GENERATED (grid calculation) result, plus a related bug where switching a view's case lost generated results.
- Remove unused SOURCE_GROUP_HEADER_FILES from GrpcInterface CMakeLists
- Scope the following defines to the files that need it ENABLE_GRPC, USE_ODB_API , USE_OPENVDS, USE_HDF5
- RifOdbReader.cpp copied an odb_InstanceRepository by value, which
fails to compile under MSVC's strict conformance mode due to an
ambiguous implicit copy constructor in the vendor headers (diamond
inheritance). Use a reference instead, since it was only ever read
from.
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
Kristian Bendiksen
Magne Sjaastad
Jørgen Herje
magnesj
dependabot[bot]