> Before I apply your patch, do you know what happens if you use> > PETScWrappers::SolverCG but then select something else on the> command line? The command line options allows one to also change the solver type. And there are quite a few useful things that you get out of it such as ability to monitor the preconditioned or true residual norm, to change the maximum iteration, tolerances dynamically, to increase the restarts in case of GMREs and many other flexible options. > Using KSPSetFromOptions on the commandline should not change the solver > type - but it can change solver parameters.
Toby, if the philosophy behind the deal.II petsc solvers is to use custom tailored objects for each KSPType, then I do agree that you should be able to move the KSPSetFromOptions before the SetKSPType call. > As I see it KSPSetTolerances and KSPSetFromOptions overlap their > usage; see the -ksp_rtol switch which seems to modify the same target > and can be called from both routines (in fact all of the switches in > KSPSetTolerances seem to be modified by KSPSetFromOptions). What happens > if you call them in different orders? KSPSetTolerances sets the default iterations, and absolute/relative tolerances for the solver. This option can be overridden by the user from command line which gets propagated by KSPSetFromOptions. If the user does not specify anything, the default options remain active. > In short: Your patch may mess with the dealii::SolverControl. What > happens if you select a particular set of options with > dealii::SolverControl and something different on the command line with > -ksp_rtol=something_silly? I do not think so. Overriding via command line options provide the flexibility to test and decipher why a solver did or not converge without having to recompile the code.. Unless you dynamically change the rtol inside the code, I don't see why somebody would mess this up. > I think the important question here is in which order PETSc overrides > himelf (I guess SetFromOptions wins) and what how should we implement > that for deal.II users? I am tempted to let things like that > (commandline options taking control over deal.II options) be open to > PETSC_DEV users only. Depends on where SetFromOptions is placed. If you want to keep the solver constant based on the derived class, call the options before setting the type. It will still override all the solver control's parameters such as atol, rtol, maxit etc ... I prefer this. But if you want to dictate everything from the code, and feel that is the way to be done in deal.II, then the solver control initialization should be done after SetFromOptions. Then, you disallow the user to override the tolerances and the ksp type but allow him to use any other option usable on a KSP object. Hope that is clear. Vijay On Wed, Dec 14, 2011 at 10:38 AM, Toby D. Young <[email protected]> wrote: > > Vijay et al, > >> > While playing around with step-17 using PETSc solvers, I found that >> > via command line I could only control the preconditioners and not >> > the solvers. This seems like a major bug and is not in the >> > philosophy of what the PETSc solvers provide. Adding the >> > KSPSetOptions remedies this but I just wanted to know if there was >> > a reason to ever not include this or perhaps remove the call that >> > existed previously. >> >> But that of course doesn't mean that we have to continue doing so. >> Before I apply your patch, do you know what happens if you use >> PETScWrappers::SolverCG but then select something else on the >> command line? > > If I understand how this works correctly, the > dealii::PETScWrappers solvers are selected by KSPSetType and are > controled by KSPSetTolerances. This is good and it works. > > KSPSetFromOptions then sets the options for that solver from the > command line options if they work (and ignores them if not). This is > also good - but there is a gottcha! > > Using KSPSetFromOptions on the commandline should not change the solver > type - but it can change solver parameters. > > http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/KSP/KSPSetFromOptions.html > > Now, see also > > http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/KSP/KSPSetTolerances.html > > that dealii::PETScWrappers currently uses. > > As I see it KSPSetTolerances and KSPSetFromOptions overlap their > usage; see the -ksp_rtol switch which seems to modify the same target > and can be called from both routines (in fact all of the switches in > KSPSetTolerances seem to be modified by KSPSetFromOptions). What happens > if you call them in different orders? Vijay's patch puts this after > set_solver_type, so I assume it overrides that. Which order is the one > we should respect for deal.II users? Where is the PETSc documentation > on this issue? > > In short: Your patch may mess with the dealii::SolverControl. What > happens if you select a particular set of options with > dealii::SolverControl and something different on the command line with > -ksp_rtol=something_silly? > > If there is something different happening, it is not obvious to me. > > I think the important question here is in which order PETSc overrides > himelf (I guess SetFromOptions wins) and what how should we implement > that for deal.II users? I am tempted to let things like that > (commandline options taking control over deal.II options) be open to > PETSC_DEV users only. > > Is my argument clear? > > Best, > Toby > > > -- > Toby D. Young > > Assistant Professor Philosophy & Physics > Polish Academy of Sciences > www: http://www.ippt.gov.pl/~tyoung > skype: stenografia > > _______________________________________________ > dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii _______________________________________________ dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
