test: mixed-dimensional consistency

[OmarDuran]

This PR introduces a new suite of integration tests designed to verify the consistency and correctness of several core capabilities: the Finite Element Method (FEM) mechanical solver SolidMechanicsAugmentedLagrangianContact, single-phase flow, compositional hydrostatic equilibrium, and the workflow for defining fractures using the SurfaceGenerator class.

These tests specifically target the resolution of mixed-dimensional problems generated with the internal Surface Generator, where fractures (2D entities) are conformal within a 3D matrix mesh. The test suite also includes verification of the topological modifications induced in the mesh by fracture generation.

Among its key benefits, this PR enables a more robust initialization procedure for mechanical problems with fractures. It allows for the following workflow: initialize the intact rock problem, perform a fracturing step (generation of fractures), initialize fracture tractions based on the already computed surrounding stress, and finally equilibrate the entire system with fractures before the actual dynamic simulation.

<Events minTime="0.0" maxTime="1.0">
    <SoloEvent name="IntactRockInitialization" targetTime="0.0" beginTime="0.0" target="/Tasks/PRE.SPLIT.STEP"/>
    <SoloEvent name="FracturingStep" target="/Solvers/SurfaceGen" targetTime="0.0" beginTime="0.0"/> 
    <SoloEvent name="FracturedRockInitialization" targetTime="0.0" beginTime="0.0" target="/Tasks/POST.SPLIT.STEP"/>
    <PeriodicEvent name="solverApplications" target="/Solvers/mechSolver" forceDt="1.0"/>
</Events>

The following four C++ integration test files are introduced; all other code modifications are strictly test-driven and were required to support these new integration tests.

All simulations shown in the image sequence were executed using 12 MPI ranks.
C1: Mesh configuration containing five fractures with no topological connection to the domain boundary.
(Expected Euler characteristic of the resulting 3D mesh: 2)

C2: Mesh configuration containing three intersecting fractures that are topologically connected to the domain boundary.
(Expected Euler characteristic of the resulting 3D mesh: 8)

C3: Mesh configuration containing three perfectly aligned fractures.
(Expected Euler characteristic of the resulting 3D mesh: 2)

Test description

testFEMConsistency.cpp (Serial and MPI test)

The test ensures that the mechanical solvers preserve stress equilibrium and correctly handle contact/interface conditions across different mesh types and fracture configurations.

The physical setup corresponds to a pure compression case (-10 [MPa]), with no shear induced by the boundary conditions. As a result, the stress field is constant, which allows for direct verification. For volume elements, the averaged computed stress tensor is checked against the applied boundary tractions. For fracture surfaces, the traction vector
𝑡=𝜎⋅𝑛 is applied neighboring volume cells onto the fracture faces, computed, and verified on both sides of the fracture against the expected traction. The value of the normal traction (-10 [MPa]) can be easily verified because the loading condition is hydrostatic and the displacement solution is trilinear and exact.
The test ensures that the mechanical solvers preserve stress equilibrium and correctly handle contact/interface conditions across different mesh types and fracture configurations.

Regardless of the DFN geometry, the normal traction is -10[MPa] and the displacement jump is zero; that is, continuity of stresses and displacements is obtained:
C1

C2

testMixedDimHydrostaticEquilibrium.cpp (Serial and MPI test)

This test verifies that a hydrostatic equilibrium state defined in both the matrix (3D elements) and fractures (2D elements) with compatible boundary conditions, it is indeed a valid solution of the underlying mixed-dimensional equilibrium problem.

Because the system is initialized exactly at equilibrium, executing a single simulation step should not modify the solution regardless of the time step size. The test therefore checks that the numerical solver preserves the hydrostatic state without introducing spurious pressure or saturation changes.

Regardless of the DFN geometry, saturation and pressure on fractures and matrix should be aligned:
C1

C2

testMixedDimSinglePhaseFlow.cpp (Serial and MPI test)

This test verifies that the single-phase flow solver reproduces exact linear pressure solutions in mixed-dimensional settings. It ensures that the solver correctly handles contact and interface conditions between matrix and fracture elements across different mesh configurations, while preserving the exactness of the analytical pressure solution.

C3 satisfies K-orthogonality; therefore, exactness in linear pressure solutions is expected:

testSurfaceGenerator.cpp (Serial and MPI test)

This test validates the correctness of the Surface Generator by ensuring that the mesh undergoes the expected topological modifications during fracture generation.

The tests cover a variety of fracture configurations and fracture networks (62 configurations), which are compiled in the following directory:src/coreComponents/integrationTests/meshTests/dfn_market. It verifies:

• The expected number of fractures created in the mesh
• The correct duplication of nodes required for fracture separation
• The Euler characteristic of the mesh before and after the split, ensuring that the topological transformation is consistent

Special acknowledgments to @rrsettgast for his guidance and suggestions during the implementation of these changes, and to @castelletto1 for providing the five-fracture mesh configurations.

[codecov]

Codecov Report

❌ Patch coverage is 79.65368% with 188 lines in your changes missing coverage. Please review.
✅ Project coverage is 64.07%. Comparing base (2b691d5) to head (68d1450).

Files with missing lines	Patch %	Lines
.../coreComponents/physicsSolvers/FieldApplicator.cpp	31.89%	126 Missing ⚠️
...tegrationTests/mechanicTest/testFEMConsistency.cpp	93.83%	13 Missing ⚠️
...idFlowTests/testMixedDimHydrostaticEquilibrium.cpp	85.71%	12 Missing ⚠️
...sicsSolvers/surfaceGeneration/SurfaceGenerator.cpp	85.33%	11 Missing ⚠️
...lvers/multiphysics/PoromechanicsInitialization.cpp	0.00%	8 Missing ⚠️
...ntact/SolidMechanicsAugmentedLagrangianContact.cpp	94.73%	8 Missing ⚠️
...rs/solidMechanics/SolidMechanicsInitialization.cpp	91.30%	4 Missing ⚠️
...sts/fluidFlowTests/testMixedDimSinglePhaseFlow.cpp	96.82%	2 Missing ⚠️
src/coreComponents/dataRepository/Group.cpp	66.66%	1 Missing ⚠️
...ents/mesh/mpiCommunications/CommunicationTools.cpp	50.00%	1 Missing ⚠️
... and 2 more

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #3957      +/-   ##
===========================================
+ Coverage    58.87%   64.07%   +5.19%     
===========================================
  Files         1356     1363       +7     
  Lines       113234   114086     +852     
===========================================
+ Hits         66668    73097    +6429     
+ Misses       46566    40989    -5577     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[herve-gross]

Great work to improve robustness. Thank you.

[bd713]

Since the partitioning remains unchanged, there is no real need to recompute and verify the coloring at every surfaceGenerator time-step.
In the future, we should compute and check the coloring once (similar to PR3847), and getColor() would simply return the stored value.

[bd713]

Should we make findNeighborRanks symmetric in the first place?

[bd713]

Fully agreed that we need more robust QC on the input.
Now, how redundant is this with the symmetrization already performed on the split graph in the calling function?
Could we simply check that the symmetry assumption is not violated and raise an error, instead of fixing the graph in a different place?