<div dir="ltr">Well, there is a RELAP7 (MOOSE-based code) that encounters that problem:<div>the equation of state returns a NaN that gets handled correctly (retried with a </div><div>smaller timestep), but once we turn on -snes_vi_monitor, "Cannot get here" </div><div>is thrown.  Apparently, the monitor is called before divergence is declared.</div><div><br></div><div>I don't think it's meaningless crap: it can tell the user how many NaNs there are,</div><div>which can give them an idea of how many mesh points stay into the nonphysical</div><div>regime.  If not there, it should be counted somewhere.  In any event, the code</div><div>shouldn't die with a PLIB error in this case.  How should we handle it?</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 7, 2015 at 4:58 PM Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Oct 7, 2015, at 5:48 PM, Dmitry Karpeyev <<a href="mailto:karpeev@mcs.anl.gov" target="_blank">karpeev@mcs.anl.gov</a>> wrote:<br>
><br>
> Now that we allow NaNs bubble up through the solver,<br>
> this can trip mysterious-looking errors in SNESVI:<br>
> PETSC_ERR_PLIB, "Can never get here"<br>
> is thrown from SNESMonitorVI(), because a NaN in<br>
> the residual can defeat all of the seemingly-exhaustive<br>
> if-then-else branches counting the number of active constraints.<br>
<br>
  Shouldn't the SNESSolver already returned as "failed" before it ever gets to SNESMonitorVI in this case? Since the vector was marked with some Nan's it means that something has gone wrong already and any data in there is meaningless crap? Why count meaningless crap?<br>
><br>
> I think the fix should be to count the number of NaNs separately<br>
> and report them alongside the legitimate active bounds to give<br>
> the user as much useful information as possible.  Since this entails<br>
> a substantial difference to the output format of -snes_vi_monitor,<br>
> should the fix go to maint or master?<br>
<br>
  Not maint.<br>
<br>
><br>
> Dmitry.<br>
<br>
</blockquote></div>