thelfer / mfem-mgis Goto Github PK

MFEM proposes to use the HypreDiagScale preconditioner that is just a Jacobi preconditioner in hypre. Among Hypre preconditioners, this is the only one with "identity" (useless I guess) that is not implemented in MFEM-MGIS.

Is it because it's a pretty simple preconditioner? Since I do a performance analysis for all solvers/preconditioners, even though I don't expected anything with such a preconditioner, I was wondering if it was voluntary.

The PartialQuadratureSpace::getOffsets now returns this hash table.

The current Newton solver may failed because the direct imposition of Dirichlet boundary conditions leads to high strain increment on boundaries where those conditions are applied.
An elastic or tangent prediction of the solution is classically used to mitigate this issue.

A first step for the post-processing of stress, strain and state variables would be to extrapolate them to nodal values.

.

HypreILU is automatically disabled by the compilation flag: -DHYPRE_OLD_VERSION

This option is defined in CMakeLists.txt:15 and I can confirm that this option works as expected ...

# HypreILU is not defined for old versions of Hypre
# Comment this line for newest Hypre librarires
ADD_DEFINITIONS(-DHYPRE_OLD_VERSION)

Regarding MFEM, we check that the Hypre version is recent, ie hypre >= 2.19v (code below).
mfem/linalg/hypre.cpp:

#if MFEM_HYPRE_VERSION >= 21900
HypreILU::HypreILU()
{
   HYPRE_ILUCreate(&ilu_precond);
   SetDefaultOptions();
}
etc...

So, if HYPRE_OLD_VERSION is only used to handle the use of HypreILU, we could do the code below, right? Or did I miss something again?

if(HYPRE_VERSION VERSION_LESS 2.19) # HYPRE_VERSION env variable
ADD_DEFINITIONS(-DHYPRE_OLD_VERSION)
message(STATUS "HypreILU is disabled")
else()
message(STATUS "youpi, tu peux utiliser HypreILU")
endif()

Raphaël

Write a paper to describe library mfem-mgis

The final user imports a mesh at the beginning of each numerical simulation.
MFEM typically deals with material ids and boundary ids, but these are integers and are not very pratical to deal with because user has to remind exactly which identifier is associated with each material/boundary.
We would like a support for using string identifiers in the input parameters and postprocessing to simplify user's life to replace integer ids.
This could be well coordinated with MED support that provides such kind of string references.
Remark : GMSH reader of MFEM will typically not retrieve the information of string idenftifiers from the mesh (it would require much work to do this addtionnal feature), we will not target for the moment to have extended suppor to read string identifiers from GMSH files.

The computeMeasure returns the volume (in 3D and axisymmetrical hypotheses) or the surface (in other bidimensional hypotheses) on which is built a behaviour integrator.

I'm trying to solve a heat problem with MFEM-MGIS but I didn't find a way to add a heat source.
Is it possible to add that possibility ?
In pure MFEM it would be something like this :

  Vector powerDendity(mesh.attributes.Max());
  powerDendity = 0.;
  powerDendity(1) = 1.e6;
  PWConstCoefficient powerDendity_func(powerDendity);

  ParLinearForm b(&fespace);
  b.AddDomainIntegrator(new DomainLFIntegrator(powerDendity_func));
  b.Assemble();

Petsc package is currently not linked correctly when using the new installation way.

gcc-11.3.0/mfem-4.5.0-bq2b467degenr2a5wizfskvzs4hus3c7/include/mfem/linalg/petsc.hpp:29:10: fatal error: petscconf.h: No such file or directory
   29 | #include "petscconf.h"
      |          ^~~~~~~~~~~~~

Put some variables in cache in order to speedup compilation process.
Cirrect a few ting compared #30 .