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
