llnl / parelag

Parallel element agglomeration algebraic multigrid upscaling and solvers.

Element-Agglomeration Algebraic Multigrid and Upscaling Library

version 2.0

      ________              _______________________________
      ___  __ \_____ __________  ____/__  /___    |_  ____/
      __  /_/ /  __ `/_  ___/_  __/  __  / __  /| |  / __  
      _  ____// /_/ /_  /   _  /___  _  /___  ___ / /_/ /  
      /_/     \__,_/ /_/    /_____/  /_____/_/  |_\____/   
                                                                 

https://github.com/llnl/parelag

ParElag is a parallel distributed memory C++ library for numerical upscaling of finite element discretizations.

For building instructions, see the file INSTALL. Copyright information and licensing restrictions can be found in the file COPYRIGHT.

ParElag implements upscaling and algebraic multigrid techniques for the efficient solution of the algebraic linear system arising from mixed finite element discretization of saddle point problems. In particular, it constructs upscaled discretization for wide classes of partial differential equations and unstructured meshes in an element-based algebraic multigrid framework. This approach has the potential to be more accurate than classical upscaling techniques based on piecewise polynomial approximation. In fact, the coarse spaces and respective coarse models computed by ParElag not only posses the same stability and approximation properties of the original finite element discretization but also are operator dependent.

ParElag uses the MFEM library (http://mfem.org) for the finite element discretization and supports several solvers from the HYPRE library. Visualization in ParElag is based on GLvis (http://glvis.org).

For examples of using ParElag, see the examples/ directory.

This work was performed under the auspices of the U.S. Department of Energy by Lawrence Livermore National Laboratory under Contract DE-AC52-07NA27344. LLNL-CODE-745557.

parelag's Issues

Repeated computation in DeRhamSequence::ComputeCoarseTracesWithTargets()

This loop:

parelag/src/amge/DeRhamSequence.cpp

Line 1792 in 0f85bff

for (int iAE(0); iAE < nAE; ++iAE)

computes among other things coarse local mass matrices and local coarse bases for the trace spaces.

Then, this loop:

parelag/src/amge/DeRhamSequence.cpp

Line 1990 in 0f85bff

for (int iAE(0); iAE < nAE; ++iAE)

seems to repeat at least the computation of the coarse local mass matrices again.

Also, the parts (2 lines each) for the projection operator:

parelag/src/amge/DeRhamSequence.cpp

Line 1894 in 0f85bff

MultiVector allDataAsMV(p_loc->Data(), p_loc->Width(), loc_size);

and

parelag/src/amge/DeRhamSequence.cpp

Line 2042 in 0f85bff

MultiVector allDataAsMV(p_loc.Data(), p_loc.Width(), loc_size);

seem identical

I think that the second loop

parelag/src/amge/DeRhamSequence.cpp

Line 1990 in 0f85bff

for (int iAE(0); iAE < nAE; ++iAE)

need to be deleted completely from the code.

As a side note, DeRhamSequence::ComputeCoarseTracesNoTargets() doesn't seem to exhibit such a repetition.

My question is if I understand this correctly or there is some minor thing that needs the second loop on line DeRhamSequence.cpp:1990?

Setting default parameters after setting the user given parameters in the AMGe solver factory

Looking at SolverFactoryCreator, the "builder" routine passes the parameter list via a call to SolverFactory::Initialize(). Then, SolverFactory::Initialize() first calls SetParameters() to set the provided parameters and after that SetDefaultParameters() (which simply calls the polymorphic _do_set_default_parameters()) to possibly fill in any gaps in the user provided parameters. That is a bit of a strange, but understandable (considering that SetParameters() uses "merging"), decision. However, it hides a danger of overwriting user-provided parameters with default values and essentially quietly removing that parameter from user control. One would think that this might be mitigated since the call to _do_initialize() in SolverFactory::Initialize() has again the user-provided parameters as an argument, but the danger is still there.

I do not know if I understand that correctly or I misunderstood something but here is an example with AMGeSolverFactory. The _do_set_default_parameters() routine uses the "hard" Set() function in the parameter list class, which explicitly and unconditionally modifies the value, essentially overwriting the user provided values, for parameters like "Maximum levels" and "Forms". Then, _do_initialize() ignores the parameters in the argument, so the overwrite seems final. In other factory classes, the "soft" Get() with default values is used and that seems appropriate.

I'm thinking about changing the Set() to Get() in AMGeSolverFactory. However, I can imagine how this can be a problem in the already existing examples. For example, up to now the "Forms" has always been seen as empty, forcing obtaining the forms from the solver state. But if some .xml parameter file has "Forms" that was incorrectly set, this may cause errors that have not appeared up to now, since the parameter value takes precedence versus the value in the solver state. I still prefer doing it right and if that causes errors, addressing them separately.

some exception test

Does the following exception test make sense?

parelag/src/amge/DOFAgglomeration.cpp

Lines 447 to 452 in 62cac5e

	PARELAG_TEST_FOR_EXCEPTION(
	fabs(*it-1.0) < 1e-6 && fabs(*it-1.0) > 1e-6,
	std::runtime_error,
	"DofAgglomeration::CheckAdof(): "
	"ADof_rDof_[" << i << "] has an entry equal to " << *it << "\n"
	"FIXME: Something has gone wrong.");

The test will always return false no matter what value *it is (or maybe I just need a cup of afternoon coffee).

AMS parameters

parelag/src/linalg/solver_ops/ParELAG_AMSSolverWrapper.cpp

Line 88 in b95d355

HYPRE_AMSSetAlphaAMGOptions(

This seems odd and incorrect. Shouldn't this actually be a call to HYPREAMSSetBetaAMGOptions() or I'm confusing something and the code is correct in its current state?