In 8251562cd9, logging was activated when no field editor could be created. This happens for PdmChildArray fields and PdmChildFields. A early return checking for these types was added, and caused well targets to be hidden from the property editor.
The numerical precision in the output was lowered in #11556 since Stimplan
was not correctly handling the high precision (requested by Nan).
That change leads to the MD not always increasing (which is expected by
Stimplan). Added another tweak to the MD values to make sure it increases
in the precision range that will be written to file.
The original issue asked for improved precision in the output,
but that is not a viable option this Stimplan does not use all
of the decimal precision.
Fixes#12894.
Changes:
- Refactors data writing to allow configurable row length
- Adds documentation describing the Eclipse grid format (COORD and ZCORN)
Co-Authored-By: Kristian Bendiksen <kristian.bendiksen@gmail.com>
Documents the procedure for updating the generated C++ code for Eclipse keywords from JSON definition files in the opm-common library.
This procedure is necessary when updating to a newer version of opm-common, when new keywords are added, or when existing keyword definitions change.
Implements type-safe angle (degrees and radians) representation classes.
Provides utilities for converting between Cartesian and cylindrical
coordinate systems.
Includes a unit test suite for validation.
* Updates well path connection logic.
Refactors well path connection to ensure tie-in location is updated correctly after connecting to a parent well. This ensures the visualization and data consistency are maintained.
* Updates connected editors after target manipulation
Ensures that connected editors are updated whenever the target is manipulated through the 3D manipulator.
* #12613 Adds functionality to append lateral well paths
- Updated Python API to accept measured_depth list and channel_data dictionary
- Modified C++ GRPC implementation to handle CSV-formatted channel mappings
- Replaced single values parameter with dictionary of channels
- Added comprehensive validation for all input parameters
- Updated parameter name from channel_keys_json to channel_keys_csv
- Enhanced tests to cover 16 different scenarios including edge cases
- Updated example to demonstrate new dictionary-based API functionality
Implement comprehensive Python API for importing well log data into ResInsight
well paths using lists of float values.
Core implementation:
- RigImportedWellLogData: Data storage class inheriting from RigWellLogData
- RimImportedWellLog: Scriptable model class for Python GRPC interface
- RimcWellPath_addWellLogInternal: GRPC method using key-value store for data transfer
- well_path.add_well_log(): Python API with validation and error handling
Features:
- Simple API: well_path.add_well_log(name='LogName', values=[1.0, 2.0, 3.0])
- Comprehensive input validation and type checking
- Efficient data transfer via key-value store mechanism
- Proper error handling with cleanup on failure
- Integration with existing well path functionality
Testing:
- 10 comprehensive unit tests covering all functionality
- Validation of input types, error conditions, and edge cases
- Integration testing with well path creation
Usage example included in PythonExamples directory demonstrating
import of gamma ray, porosity, and permeability log data.
The test `RigReservoirTest_BasicTest10k_NativeECL_Test` was allocating
an `ecl_grid_type` object but was not freeing it, leading to a memory
leak.
This commit fixes the issue by calling `ecl_grid_free` at the end of
the test.
The function `well_state_add_MSW2` in `well_state.cpp` would allocate
an `ecl_rsthead_type` object but would not free it in the case where
the `RSEG_KW` keyword was not found in the restart file view.
This would lead to a memory leak.
This commit fixes the issue by freeing the allocated object before
returning from the function in the error case.
Address sanitizer detected a memory leak in CmdFeatureMenuBuilder::MenuItem
objects caused by RiuContextMenuLauncher objects that were never deleted.
Problem: The RiuContextMenuLauncher class has two constructors:
1. RiuContextMenuLauncher(widget, CmdFeatureMenuBuilder&) - sets parent ✓
2. RiuContextMenuLauncher(widget, QStringList&) - missing parent ✗
The second constructor was missing the parent initialization, causing all
RiuContextMenuLauncher objects created with QStringList (used in 10+ locations)
to never be deleted, leading to memory leaks of their internal MenuItem vectors.
Root cause: Missing parent-child relationship meant Qt couldn't automatically
clean up these objects when their associated widgets were destroyed.
Fix: Added `: QObject( widget )` to the second constructor to match the first
constructor's behavior. This ensures Qt's automatic parent-child cleanup
handles the RiuContextMenuLauncher lifecycle properly.
This fixes the systemic issue affecting multiple plot types including:
- Correlation plots, Analysis plots, VFP plots, Well allocation plots
- All locations using `new RiuContextMenuLauncher(widget, {commands})`
Address sanitizer detected a memory leak in CmdFeatureMenuBuilder::MenuItem
objects allocated during context menu creation.
Problem: The RiuContextMenuLauncher constructor was creating a temporary
CmdFeatureMenuBuilder object, populating it with menu items, then copying
the entire object to the member variable m_menuBuilder. This caused
unnecessary memory allocation and copying of std::vector<MenuItem> data.
Root cause: Inefficient constructor implementation:
caf::CmdFeatureMenuBuilder menuBuilder; // temp object
for (cmd : commandIds) menuBuilder << cmd; // populate temp
m_menuBuilder = menuBuilder; // copy entire vector (leak source)
Fix: Build the menu directly into the member variable instead of creating
a temporary object and copying it:
for (cmd : commandIds) m_menuBuilder << cmd; // direct construction
This eliminates the unnecessary temporary object creation and copy operation
that was causing the MenuItem vector allocation detected by the sanitizer.
The fix maintains identical functionality while being more efficient.
Address sanitizer detected a memory leak in QProxyStyle objects
created during GUI theme updates.
Problem: The updateGuiTheme() function was called multiple times (e.g., during
initialization) and repeatedly created new PdmUiTreeViewStyle objects for
every PdmUiTreeViewWidget without checking if the widget already had the
correct style set.
Root cause: Each call to updateGuiTheme() would:
1. Iterate through ALL widgets in the application
2. Create a new PdmUiTreeViewStyle for every tree view widget
3. Call setStyle() which should take ownership, but repeated calls
were causing memory leaks
Fix: Added a check to only create and set a new PdmUiTreeViewStyle if the
widget doesn't already have one. This prevents repeatedly creating new
styles for the same widgets during multiple theme update calls.
The fix uses dynamic_cast to check if the current style is already a
PdmUiTreeViewStyle before creating a new one.
Address sanitizer detected a 1056-byte memory leak in QWidgetItem objects.
This was the actual root cause of the leak reported in the stack trace.
Problem: In ensureWidgetContainsEmptyGridLayout(), when clearing existing
layouts, the code was calling layout->takeAt(0) to remove QLayoutItem
objects but never deleting them. This caused QWidgetItem objects to
accumulate in memory without ever being freed.
The takeAt() method removes items from the layout but does NOT delete them.
The caller is responsible for deleting the returned QLayoutItem objects.
Fix: Added `delete item;` in the cleanup loop to properly free QWidgetItem
objects when clearing layouts before rebuilding the UI.
Address sanitizer detected a 1056-byte memory leak in QWidgetItem objects
created when adding widgets to layouts via QGridLayout::addWidget().
Root cause: PdmUiFieldEditorHandle destructor was using deleteLater() to
destroy widgets, but deleteLater() requires an active event loop to process
the delayed deletions. During application shutdown or certain cleanup
scenarios, the event loop may not process these deletions, causing
QWidgetItem objects to remain allocated.
Changes:
- Replace deleteLater() with immediate delete in destructor
- Update comment to explain why immediate deletion is necessary
- This ensures widgets and their associated QWidgetItem objects are
properly cleaned up when field editors are destroyed
The original comment acknowledged that deleteLater() "will not work unless
you are actually inside an event loop" - this change addresses that issue
by using direct deletion instead.
Address sanitizer detected a 32-byte memory leak in QVBoxLayout objects
created by PdmUiFormLayoutObjectEditor::recursivelyConfigureAndUpdateUiOrderingInGridLayout().
Root cause: QVBoxLayout objects were being both:
1. Added to parent layouts via addLayout() (proper Qt ownership)
2. Stored in m_layouts member vector (redundant storage)
The redundant storage prevented Qt's automatic cleanup, causing memory leaks.
For large point arrays, the scripting causes overflow in the grpc communication. Disable scripting to make sure the grpc object size is below size threshold.
Refactored RigGridBase::cellCornerVertices to return std::array<cvf::Vec3d, 8> by value instead of taking a reference to std::array as an output parameter. This change improves code readability and leverages modern C++ return value optimizations.
Updated all call sites across the codebase to reflect the new function signature.
Previously, we had support for import of well log file including (some) well path geometry. Then, when the full well path was imported later, the well log data was moved to the full well path. This functionality is now removed as it is not working well when we allow import of multiple well path files.
Kristian Bendiksen
Magne Sjaastad
magnesj
dependabot[bot]