This is currently being handled by having MatCreate() dynamically compose
all the possible (matrix format, solver package) combinations in the Mat,
but then we have no way to have -help list the possibilities. What about
having a static list
typedef struct _n_MatFactorSolverPackageLink *MatFactorSolverPackageLink;
struct _n_MatFactorSolverPackageLink {
MatType type;
PetscFList package_list;
MatFactorSolverPackageLink *next;
}
MatFactorRegisterSolverPackage(MATMPIAIJ,MATSOLVERSUPERLU_DIST,path,"MatGetFactor_mpiaij_superlu_dist",MatGetFactor_mpiaij_superlu_dist);
I think Sean is volunteering to do this...
Also, what about using macro stringify to remove the repetitiveness in
XRegisterDynamic and PetscComposeFunctionDynamic? I also think we can
eliminate some of the boilerplate to make a new XRegisterDynamic. I think
that a macro solution would be no more mysterious than PetscTryMethod. I
dislike adding macros, but I do get tired of creating more boilerplate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111019/c4453895/attachment.html>
