On Feb 26, 2013, at 4:44 PM, Dmitry Karpeev <[email protected]> wrote:

These calls compute default values for normtype and pcside based on partial KSP options, which can cause an unwarranted error to be thrown. For example, in code there may be

KSPSetPCSide(ksp, PC_RIGHT); /* hardwired default, e.g., in Moose. */

Now, when I'm using command-line arguments -ksp_type preonly an error is thrown, since KSPPREONLY doesn't work with PC_RIGHT.

Huh? EXTERN_C_BEGIN #undef __FUNCT__ #define __FUNCT__ "KSPCreate_PREONLY" PetscErrorCode KSPCreate_PREONLY(KSP ksp) { PetscErrorCode ierr; PetscFunctionBegin; ierr = KSPSetSupportedNorm(ksp,KSP_NORM_NONE,PC_LEFT,2);CHKERRQ(ierr); /* LEFT/RIGHT is arbitrary, so "support" both */ ierr = KSPSetSupportedNorm(ksp,KSP_NORM_NONE,PC_RIGHT,1);CHKERRQ(ierr); Is it because MOOSE also hardwires the norm type and preonly doesn't support it? What is the full and complete error message.

Fine, I try -ksp_type preonly -ksp_pc_side left but still get the same error, since KSPSetUpNorms_Private() is called after KSP type has been set to KSPPREONLY, but BEFORE there was a chance to set the PC side!

Is there any reason to keep these calls to KSPSetUpNorms_Private() in KSPSetFromOptions()?

I think they are there so that users can overwrite them in the rest of KSPSetFromOptions(). If you move them to KSPSetUp() then the user cannot reset them. Barry

KSPSetUpNorms_Private() will be just about the first thing called in KSPSetUp() and will compute the appropriate normtype and pcside, but now based on complete KSP options.

Not to mention that calling XXXSetUp_YYY() XXXSetFromOptions() seems generally contrary to PETSc's design philosophy.

Dmitry.