[petsc-dev] SLEPc broken due to procedural options for external direct solvers

[Jose E. Roman]

The following changeset in petsc-dev prevents SLEPc from using external solvers such as MUMPS.
http://petsc.cs.iit.edu/petsc/petsc-dev/rev/c69e747aa463

The fact that now MatGetFactor is called within PCFactorSetMatSolverPackage (and thus from PCSetFromOptions) breaks all the initialization scheme that we had for the hierarchy of objects in SLEPc. We have EPS --> ST --> KSP --> PC, and at EPSSetFromOptions we chain XXXSetFromOptions calls for all 4 classes, but at this point the KSP operator/preconditioner is not available yet, only at XXXSetUp (the reason is that we decide which is the coefficient matrix of the linear system at STSetUp, then we call KSPSetOperators). We could try to move the code that initializes the matrix from XXXSetUp to XXXSetFromOptions, but if we did this then the user could not provide procedural options for MUMPS because in some schemes we call KSPSetOperators several times within EPSSolve.

I understand that the motivation of the change is to allow the user to set up MUMPS (et al) options procedurally. But as it is now it seems that these options get lost if the PC matrix is changed, for instance when the Jacobian matrix changes within a non-linear solve. To be consistent, the call to MatSetMumpsIcntl should be done every time the PCFactor matrix is created. Maybe letting the user provide a callback function for this would be a better solution, instead of requiring KSPSetOperators be called before KSPSetFromOptions.

Any thoughts?