Steve,
I have removed the extra checks on norm, dot and mdot in petsc-3.3 in the
next patch petsc-3.3 should behave like previous versions of PETSc.
Barry
On Feb 22, 2013, at 6:35 PM, "Cea, Stephen M" <stephen.m.cea at intel.com>
wrote:
> Thanks for the quick responses!
>
> For the short time I am pretty sure that we can just treat the error from
> KSP_Solve like non convergence. Long term what you propose sounds good.
>
> Thanks again,
> steve
>
> -----Original Message-----
> From: Barry Smith [mailto:bsmith at mcs.anl.gov]
> Sent: Friday, February 22, 2013 4:20 PM
> To: petsc-maint at mcs.anl.gov; Jed Brown
> Cc: For users of the development version of PETSc; Cea, Stephen M
> Subject: Re: [petsc-dev] [petsc-maint #154101] clarification of FP error
> thrown in VECNORM in 3.3 PETSc
>
>
> On Feb 22, 2013, at 6:02 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
>> On Fri, Feb 22, 2013 at 5:57 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>
>>> We will figure out a way to manage this. I am thinking a global
>>> flag you can set indicating you don't want these checks performed;
>>> then you will get back the previous behavior.
>>
>>
>>
>> Would it be enough to have a flag per-object?
>
> Ok, I did a search through the code to see where we are checking it.
>
> 1) VecNorm, VecDot, VecMDot -- and generate an error
>
> 2) Many of the Krylov solvers and nonlinear solvers check the results of
> (most - should be all) norms and dots and either
>
> a) generate a not converged KSP or SNES converged reason (good)
>
> b) generate an error (bad, most do this).
>
> Note that currently the checks in the solvers are redundant because an
> error was already generated in the VecNorm, Dot or MDot so NaN never
> gets to the iterative solver
>
> 3) Few other irrelevant places.
>
> The simplest thing would be to simply remove the checks in 1). Then,
> eventually, update all the solvers to NOT generate an error but instead
> return with an appropriate diverged reason. The drawback is that other code
> using dots and norms will always chug along without generating an error if
> users don't check the results themselves.
>
> I vote we just make a patch in 3.3 to remove the checks in norm, dot, mdot
> and Jed adds another project to the bitbucket list saying upgrade the checks
> in the solvers to return with appropriate diverged reason instead of
> generating an error. Then the whole flag business goes away.
>
>
>
> Barry
>
>
>>
>> I don't like a global flag because it would have to be set
>> collectively (this isn't nice if you subproblems on subcomms and not
>> everyone wants to tolerate NaNs.) Note that to tolerate NaNs and bail
>> out cleanly, a reduction is required in places where it would otherwise not
>> be.
>>
>
