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<div>
<br></div><div>typedef struct _n_MatFactorSolverPackageLink *MatFactorSolverPackageLink;</div><div>struct _n_MatFactorSolverPackageLink {</div><div>  MatType type;</div><div>  PetscFList package_list;</div><div>  MatFactorSolverPackageLink *next;</div>
<div>}</div><div><br></div><div>MatFactorRegisterSolverPackage(MATMPIAIJ,MATSOLVERSUPERLU_DIST,path,"MatGetFactor_mpiaij_superlu_dist",MatGetFactor_mpiaij_superlu_dist);</div><div><br></div><div><br></div><div>I think Sean is volunteering to do this...</div>
<div><br></div><div><br></div><div>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.</div>