[petsc-users] -pc_factor_mat_solver_package wish_list

[Barry Smith]

   Ok, so you are suggesting the same functions/options database as today except that : separated strings for alternatives?

    Note that PetscFListGetPathAndFunction() which is used by all the checkers handles the form [/path/libname[.so.1.0]:]functionname[()] so : is already reserved. I would suggest | but the damn shell would require always protecting the arguments with "". 

    Barry


On Jan 7, 2013, at 5:09 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Mon, Jan 7, 2013 at 5:02 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>  How would this be done in the code? Ideally there is a functional interface with a corresponding OptionsData base interface. Something like the equivalent of PCFactorSetMatSolverPackages(pc,{MATSOLVERSUPERLU_DIST,MATSOLVERMUMPS, MATSOLVERPETSC,PETSC_NULL})
> 
> It could, but I'd prefer to have a generic routine that created an alternative from the array of types (by joining them with ':').
> 
> Otherwise it's just more boilerplate for every object.
>  
>    Then follow this paradigm for all set types and packages? But then since there is  a PCFactorSetMatSolverPackage() and a PCFactorSetMatSolverPackages() should there be
> a -pc_factor_mat_solver_package  package AND -pc_factor_mat_solver_packages  package1:package2  ?
> 
> No need, if it containts a ':' then it's an alternative. The implementation of PCFactorSetMatSolverPackages() would just join the strings and call PCFactorSetMatSolverPackage().