Certain Mat implementations (and associated utility user-level functions) need 
to go in the KSP library because they use KSP even though, from the user point 
of view, they only have a Mat-level API.

Where should the information needed in the include files go? For MATLMVM they 
are mixed up some in petscmat.h and some in petscksp.h

$ grep MAT include/petscksp.h 
.  `KSP_DIVERGED_INDEFINITE_MAT` - the operator was indefinite for a `KSPType` 
that requires it be definite
  KSP_DIVERGED_INDEFINITE_MAT            = -10,
  MAT_SCHUR_COMPLEMENT_AINV_DIAG,
  MAT_SCHUR_COMPLEMENT_AINV_LUMP,
  MAT_SCHUR_COMPLEMENT_AINV_BLOCK_DIAG,
  MAT_SCHUR_COMPLEMENT_AINV_FULL
  MAT_LMVM_SYMBROYDEN_SCALE_NONE     = 0,
  MAT_LMVM_SYMBROYDEN_SCALE_SCALAR   = 1,
  MAT_LMVM_SYMBROYDEN_SCALE_DIAGONAL = 2,
  MAT_LMVM_SYMBROYDEN_SCALE_USER     = 3
~/Src/petsc (barry/2023-12-21/fix-dmproject/release *>) arch-fix-dmproject
$ grep MATLMVM include/petscmat.h 
#define MATLMVM                      "lmvm"
#define MATLMVMDFP                   "lmvmdfp"
#define MATLMVMBFGS                  "lmvmbfgs"
#define MATLMVMSR1                   "lmvmsr1"
#define MATLMVMBROYDEN               "lmvmbroyden"
#define MATLMVMBADBROYDEN            "lmvmbadbroyden"
#define MATLMVMSYMBROYDEN            "lmvmsymbroyden"
#define MATLMVMSYMBADBROYDEN         "lmvmsymbadbroyden"
#define MATLMVMDIAGBROYDEN           "lmvmdiagbroyden"

Should they all go in petscksp.h or all in petscmat.h ? Seems bad to have some 
arbitrarily in each? I vote for petscmat.h since then their docs also go in the 
Mat docs and users don't need to think "Oh, because MATLMVM uses a KSP in its 
implementation (why should users need to know or care about this?) I also need 
include petscksp.h even though MY code does not use KSP at all."

Thoughts




Reply via email to