GEOS-DEV / GEOS-DEV/GEOS

hypre_MGRSetup fails for THM model with wells - Segmentation fault

Open
#3,924 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

type: bug type: new
Dominant language
C++
Stars
287
Forks
109
Avg merge
4d 41m
Merged PRs (30d)
5

Description

Describe the bug
Geos crashes with enabled thermal effects in elastic mechanical model, the simulation fails (negative BHP value + Segmentation fault).
Isothermal poroelastic model runs well.

To Reproduce
Steps to reproduce the behavior:

  1. Unpack the mesh files and adjust the path to VTU files in XML data files
  2. Run the attached model (geosx ThermoPoroElastic.xml)
  3. See the error attached below
    Expected behavior
    A clear and concise description of what you expected to happen.

Screenshots
Rank 9: wellControls2: surface density computed with P_surface = 101325 Pa
Rank 9: wellControls2: total fluid density at surface conditions = 995.6540540734746 kg/sm3, total rate = 0 kg/s, total surface volumetric rate = 0 sm3/s
Rank 9: wellControls2: The BHP (at the specified reference elevation) = -488346.5410838615 Pa
Attempt: 0, ConfigurationIter: 0, NewtonIter: 0
( Rflow ) = ( 5.59e-08 ) ( Renergy ) = ( 0.00e+00 ) ( Rsolid ) = ( 4.44e-12 ) ( Rwell ) = ( 0.00e+00 ) ( Renergy ) = ( 0.00e+00 ) ( R ) = ( 5.59e-08 )
***** ERROR
***** SIGNAL: 11
***** LOCATION: (external error, captured by signal handler)
Signal no. 11 encountered: Segmentation fault
StackTrace of 24 frames
Frame 0: /lib64/libc.so.6
Frame 1: /lib64/libc.so.6
Frame 2: .....mpi/2021.9.0/lib/release/libmpi.so.12
....
Frame 8: PMPI_Allgatherv
Frame 9: hypre_MPI_Allgatherv
Frame 10: hypre_GaussElimSetup
Frame 11: hypre_MGRSetup
Frame 12: geos::HyprePreconditioner::setup(geos::HypreMatrix const&)
Frame 13: geos::HypreSolver::setup(geos::HypreMatrix const&)
Frame 14: geos::PhysicsSolverBase::solveLinearSystem(geos::DofManager const&, geos::HypreMatrix&, geos::HypreVector&, geos::HypreVector&)
Frame 15: geos::PhysicsSolverBase::solveNonlinearSystem(double const&, double const&, int, geos::DomainPartition&)
Frame 16: geos::PhysicsSolverBase::nonlinearImplicitStep(double const&, double const&, int, geos::DomainPartition&)
Frame 17: geos::PhysicsSolverBase::solverStep(double const&, double const&, int, geos::DomainPartition&)
Frame 18: geos::CoupledSolver<geos::SinglePhasePoromechanics<geos::SinglePhaseBase, geos::SolidMechanicsLagrangianFEM>, geos::SinglePhaseWell>::solverStep(double const&, double const&, int, geos::DomainPartition&)
Frame 19: geos::PhysicsSolverBase::execute(double, double, int, int, double, geos::DomainPartition&)
Frame 20: geos::EventBase::execute(double, double, int, int, double, geos::DomainPartition&)
Frame 21: geos::EventManager::run(geos::DomainPartition&)
Frame 22: geos::GeosxState::run()
Frame 23: main
Frame 24: __libc_start_main
`

Platform (please complete the following information):

  • Machine: RHEL 8.10
  • Compiler: gcc 13.1.0
  • GEOS Version: 1.1.0
  • GEOS Version sha: develop 1e617be8614817d92f0a7a159994cbed1661ff98 , tpls: 9687680c61fa3378f7b2ce7eea8327736809fb63

Additional context
Log files made for 10 MPI processes, but the bug reproduces on 1 MPI process too).

Mesh files
Meshes have .vtu format, I archived 34_34_57 with which the bug can be reproduced. Please remove .txt extension which was added to manage the uploading.
mesh_34_34_57.7z.txt
Just in case, I attach a smaller mesh which might help for debugging. However I didn't try to reproduce the issue with it.
mesh_4_4_6.vtu.txt

Poroelastic model (which runs)
PoroElastic.xml
PoroElastic_base.xml
run_isothermal.log

ThermoPoroelastic model (which fails)
run_thermal.log
ThermoPoroElastic.xml
ThermoPoroElastic_base.xml

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by running ThermoPoroElastic.xml with the supplied mesh and comparing its output with PoroElastic.xml and the attached logs. Trace the failure from hypre_MGRSetup through geos::HyprePreconditioner::setup and the coupled solver entry points shown in the stack trace. Done means the thermal model no longer produces the negative BHP followed by a segmentation fault.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
hpc
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.