chore: update trilinos, hypre and fmt.

[CusiniM]

GEOS-DEV/thirdPartyLibs#273
GEOS-DEV/LvArray#322

Updated tpls:

• Trilinos: 15.1.1
• Hypre: hypre-v2.31.0-26-gf6cfb0355. Contains MGR improvements that required GEOS code changes.
• fmt 11.01.1

[codecov]

Codecov Report

Attention: Patch coverage is 3.12500% with 31 lines in your changes missing coverage. Please review.

Project coverage is 55.73%. Comparing base (94a0e86) to head (92c1457).
Report is 89 commits behind head on develop.

Files with missing lines	Patch %	Lines
...Strategies/MultiphasePoromechanicsReservoirFVM.hpp	0.00%	18 Missing ⚠️
src/coreComponents/common/DataTypes.hpp	0.00%	1 Missing ⚠️
src/coreComponents/dataRepository/DataContext.hpp	0.00%	1 Missing ⚠️
...onents/linearAlgebra/interfaces/hypre/HypreMGR.hpp	0.00%	1 Missing ⚠️
...hypre/mgrStrategies/CompositionalMultiphaseFVM.hpp	0.00%	1 Missing ⚠️
...mgrStrategies/CompositionalMultiphaseHybridFVM.hpp	0.00%	1 Missing ⚠️
...Strategies/CompositionalMultiphaseReservoirFVM.hpp	0.00%	1 Missing ⚠️
...gies/CompositionalMultiphaseReservoirHybridFVM.hpp	0.00%	1 Missing ⚠️
...es/hypre/mgrStrategies/MultiphasePoromechanics.hpp	0.00%	1 Missing ⚠️
...es/SinglePhasePoromechanicsConformingFractures.hpp	0.00%	1 Missing ⚠️
... and 4 more

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #3214      +/-   ##
===========================================
- Coverage    55.75%   55.73%   -0.02%     
===========================================
  Files         1041     1041              
  Lines        88534    88562      +28     
===========================================
+ Hits         49358    49362       +4     
- Misses       39176    39200      +24     

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

[rrsettgast]

this doesn't make sense to me? I read it as
"If we GEOS_USE_HYPRE_DEVICE is the same as GEOS_USE_HYPRE_CPU then do something"...but should these ever be the same?

[victorapm]

I've seen a few test cases with GPUs where threshold > 0 causes a crash in hypre, which does not seem straightforward to resolve. Since threshold > 0 works for CPUs, and for the sake of getting this new truncation functionality used in GEOS, I'm currently setting different threshold according to the architecture. After the GPU path in hypre is improved, I will change back the threshold parameter to the same default for CPUs and GPUs in GEOS

[rrsettgast]

are these settings documented somewhere?

[victorapm]

There is some documentation via doxygen, see https://geosx-geosx.readthedocs-hosted.com/en/latest/doxygen_output/html/namespacegeos_1_1hypre.html#a05c6983a0ed8e068d0861c91767e83da

We've talked about adding a more detailed description on RTD. Should we re-prioritize that? cc @castelletto1

[rrsettgast]

I meant to ask whether there is a discussion on the documentation regarding the strategy? So in this case, for CompositionalMultiphaseFVM there is a strategy that consists of:

     m_levelFRelaxType[0]          = MGRFRelaxationType::jacobi;
     m_levelFRelaxIters[0]         = 1;
     m_levelInterpType[0]          = MGRInterpolationType::jacobi;
     m_levelRestrictType[0]        = MGRRestrictionType::injection;
     m_levelCoarseGridMethod[0]    = MGRCoarseGridMethod::galerkin;
     m_levelGlobalSmootherType[0]  = MGRGlobalSmootherType::none;
     m_levelFRelaxType[1]          = MGRFRelaxationType::none;
     m_levelInterpType[1]          = MGRInterpolationType::injection;
     m_levelRestrictType[1]        = MGRRestrictionType::blockColLumped; // True-IMPES
     m_levelCoarseGridMethod[1]    = MGRCoarseGridMethod::galerkin;
     m_levelGlobalSmootherType[1]  = MGRGlobalSmootherType::ilu0;
     m_levelGlobalSmootherIters[1] = 1;

And is there an easily accessible explanation for all of these options, and why they go together in the geos documentation....or in the hypre documentation? I suspect the hypre documentation is more of an expert level documentation??

[victorapm]

There isn't an easily accessible explanation in neither documentations. I believe hypre's documentation is a better place for a detailed documentation, while in GEOS, we could provide an overview of these preconditioning techniques for each physics model, e.g., the strategy above resembles the commonly used CPR method

[rrsettgast]

what is the effect of this?

[CusiniM]

My guess is that the gsElimWInverse is not really scalable. Shouldn't we do block jacobi though? It's a block diagonal matrix so wouldn't block jacobi be exact?

[victorapm]

Yes, we should be doing block jacobi

[victorapm]

Sorry, now I recall what's going on here...

Under the hood, hypre does block-Jacobi because of the interpolation choice m_levelInterpType[0] = MGRInterpolationType::blockJacobi. However, this logic is confusing (it shouldn't depend on the interpolation) and hypre should have a specific option for doing block-Jacobi F-relaxation.

I can work on that.

[untereiner]

Hello @CusiniM
I am wondering, are raja and chai direct dependencies of GEOS or are they transitive dependencies via lvarray ?

[CusiniM]

Hello @CusiniM I am wondering, are raja and chai direct dependencies of GEOS or are they transitive dependencies via lvarray ?

direct dependencies:

GEOS/src/coreComponents/common/GEOS_RAJA_Interface.hpp

Line 23 in a3b438d

#include <RAJA/RAJA.hpp>

[CusiniM]

@cssherman can you approve this?

[untereiner]

I am looking a bit more to the Lvarray dependencies:

• Lvarray needs raja
• geos needs lvarray but also raja.

Can lvarray live without raja ?
In the negative case it would be cleaner that geos only depends on lvarray and let lvarray manage the raja dependency (version, public API for geos, etc.)
Do you agree ?

[corbett5]

RAJA is one of the few hard dependencies of LvArray.