I notice that this part of the message does not change even when I specify "-snes_mf_type default" (which is the alternative to wp), so I am a bit confused on how I interact to the -snes_mf_type or if I am interpreting the message wrong. Could you clarify this?
Hmm, the two possibilities are -snes_mf_type wp or ds. I would expect an error message if you passed default. Regarding selecting the err=1.49012e-08 (relative error in function evaluation) this number should be the square root of the expected error in the function evaluation. So for double-precision numbers and a function evaluation with no noise (so computed accurately to double precision) the tolerance is the square root of the machine epsilon. You should only change this number (make it bigger) if you know that your function evaluations are not fully accurate. For example, if you know your function evaluation is only accurate to 10 decimal digits you could use an err of 1e-5. But if your function evaluations are accurate to double precision then changing this number is unlikely to help anything. Barry > On Apr 6, 2022, at 3:13 PM, Alfredo J Duarte Gomez <[email protected]> > wrote: > > Good afternoon petsc team, > > I have a few questions regarding the matrixfree in the snes context. > > I am currently using the matrix-free method with my own preconditioner to > solve a TS problem. I currently trigger this with the -snes_mf_operator > option. > > So far the default values have been working great, but I ran into trouble > during a convergence study when I made the time step very small, which I > suspect is probably happening because it's dropping below the matrix-vector > product tolerance. > > I wanted to explore the parameters of the matrix-vector product but using the > -snes_view option I notice that the following full message comes out: > > ----------------------------------------------------------------------------------- > SNES Object: 96 MPI processes > type: newtonls > maximum iterations=20, maximum function evaluations=10000 > tolerances: relative=1e-06, absolute=1e-06, solution=1e-15 > total number of linear solver iterations=14 > total number of function evaluations=35 > norm schedule ALWAYS > Jacobian is never rebuilt > Jacobian is applied matrix-free with differencing > Jacobian is applied matrix-free with differencing, no explict Jacobian > SNESLineSearch Object: 96 MPI processes > type: l2 > maxstep=1.000000e+08, minlambda=1.000000e-12 > tolerances: relative=1.000000e-08, absolute=1.000000e-15, > lambda=1.000000e-08 > maximum iterations=1 > KSP Object: 96 MPI processes > type: gmres > restart=100, using Classical (unmodified) Gram-Schmidt > Orthogonalization with no iterative refinement > happy breakdown tolerance 1e-30 > maximum iterations=400, initial guess is zero > tolerances: relative=0.01, absolute=1e-50, divergence=10000. > left preconditioning > using PRECONDITIONED norm type for convergence test > PC Object: 96 MPI processes > type: shell > MyPreconditioner > linear system matrix followed by preconditioner matrix: > Mat Object: 96 MPI processes > type: mffd > rows=8400000, cols=8400000 > Matrix-free approximation: > err=1.49012e-08 (relative error in function evaluation) > Using wp compute h routine > Does not compute normU > Mat Object: 96 MPI processes > type: mpiaij > rows=8400000, cols=8400000, bs=4 > total: nonzeros=2041029504, allocated nonzeros=2041029504 > total number of mallocs used during MatSetValues calls=0 > -------------------------------------------------------------------------------- > > I have been focusing specifically on the part: > > Matrix-free approximation: > err=1.49012e-08 (relative error in function evaluation) > Using wp compute h routine > Does not compute normU > > I notice that this part of the message does not change even when I specify > "-snes_mf_type default" (which is the alternative to wp), so I am a bit > confused on how I interact to the -snes_mf_type or if I am interpreting the > message wrong. Could you clarify this? > > Also let me know if you have any general suggestions on tightening the > tolerance of the matricxvector products. > > Thank you, > > -Alfredo > > > > -- > Alfredo Duarte > Graduate Research Assistant > The University of Texas at Austin
