On Feb 26, 2013, at 4:44 PM, Dmitry Karpeev <karpeev at mcs.anl.gov> 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.
>
>
