> On Jan 12, 2016, at 8:19 PM, Gideon Simpson <[email protected]> wrote: > > Got it. I’m trying to build up my desired convergence test, based on the > default routine. I’m getting the following compiler error, which I don’t > entirely understand: > > blowup_utils.c:180:9: error: > incomplete definition of type 'struct _p_SNES' > snes->ttol = fnorm_scaled*snes->rtol; > ~~~~^ > /opt/petsc/include/petscsnes.h:20:16: note: forward declaration of > 'struct _p_SNES' > typedef struct _p_SNES* SNES;
Since you are accessing the internals of SNES you need to include <petsc/private/snesimpl.h> > > Separately, is there a way to get the step vector? SNESGetSolutionUpdate() > > -gideon > >> On Jan 12, 2016, at 9:17 AM, Dave May <[email protected]> wrote: >> >> >> >> On 12 January 2016 at 15:06, <[email protected]> wrote: >> Do I have to manually code in the divergence criteria too? >> >> Yes. >> >> By calling SNESSetConvergenceTest() you are replacing the default SNES >> convergence test function which will get called at each SNES iteration, >> therefore you are responsible for defining all reasons for convergence and >> divergence. >> >> To make life easy, you could copy everything in the funciton >> SNESConvergedDefault(), >> >> http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/SNES/SNESConvergedDefault.html#SNESConvergedDefault >> >> and just replace the rule for >> SNES_CONVERGED_FNORM_RELATIVE >> with your custom scaled stopping condition. >> >> >> >> >> >> >> On Jan 12, 2016, at 8:37 AM, Dave May <[email protected]> wrote: >> >>> >>> >>> On 12 January 2016 at 14:33, Gideon Simpson <[email protected]> >>> wrote: >>> I’m just a bit confused by the documentation for >>> SNESConvergenceTestFunction. the arguments for the xnorm, gnorm, and f are >>> passed in, at the current iterate, correct? >>> >>> Yes, but nothing requires you to use them :D >>> >>> I interpreted this as though I had to build by convergence test based on >>> those values. >>> >>> This is a misinterpretation. You can ignore all of xnorm, gnorm and fnorm >>> and define any crazy stopping condition you like. >>> >>> xnorm, gnorm and fnorm are commonly required for many stopping conditions >>> and are computed by the snes methods. As such, are readily available and >>> for efficiency and convenience they are provided to the user (e.g. to avoid >>> you having to re-compute norms). >>> >>> Cheers, >>> Dave >>> >>> >>> -gideon >>> >>>> On Jan 12, 2016, at 8:24 AM, Dave May <[email protected]> wrote: >>>> >>>> >>>> >>>> On 12 January 2016 at 14:14, Gideon Simpson <[email protected]> >>>> wrote: >>>> That seems to to allow for me to cook up a convergence test in terms of >>>> the 2 norm. >>>> >>>> While you are only provided the 2 norm of F, you are also given access to >>>> the SNES object. Thus inside your user convergence test function, you can >>>> call SNESGetFunction() and SNESGetSolution(), then you can compute your >>>> convergence criteria and set the converged reason to what ever you want. >>>> >>>> See >>>> >>>> http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/SNES/SNESGetFunction.html >>>> >>>> http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/SNES/SNESGetSolution.html >>>> >>>> Cheers, >>>> Dave >>>> >>>> >>>> >>>> >>>> What I’m really looking for is the ability to change things to be >>>> something like the 2 norm of the vector with elements >>>> >>>> F_i/|x_i| >>>> >>>> where I am looking for a root of F(x). I can just build that scaling into >>>> the form function, but is there a way to do it without rewriting that >>>> piece of the code? >>>> >>>> >>>> -gideon >>>> >>>>> On Jan 12, 2016, at 12:14 AM, Barry Smith <[email protected]> wrote: >>>>> >>>>> >>>>> You can use SNESSetConvergenceTest() to use whatever test you want to >>>>> decide on convergence. >>>>> >>>>> Barry >>>>> >>>>>> On Jan 11, 2016, at 3:26 PM, Gideon Simpson <[email protected]> >>>>>> wrote: >>>>>> >>>>>> I’m solving nonlinear problem for a complex valued function which is >>>>>> decomposed into real and imaginary parts, Q = u + i v. What I’m finding >>>>>> is that where |Q| is small, the numerical phase errors tend to be >>>>>> larger. I suspect this is because it’s using the 2-norm for convergence >>>>>> in the SNES, so, where the solution is already, the phase errors are >>>>>> seen as small too. Is there a way to use something more like an >>>>>> infinity norm with SNES, to get more point wise control? >>>>>> >>>>>> -gideon >>>>>> >>>>> >>>> >>>> >>> >>> >> >
