<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 3, 2017 at 11:44 AM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Fri, Feb 3, 2017 at 11:41 AM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Feb 3, 2017, at 12:59 AM, Mark McClure <<a href="mailto:mark.w.mccl@gmail.com" target="_blank">mark.w.mccl@gmail.com</a>> wrote:<br>
><br>
> Hi, Jed and Matt.<br>
><br>
> To close the loop, it turns out that the condition number issue had a simple explanation. The BC equation that I had added to the system had very different units from the other equations. Multiplying that row by a constant (effectively, modifying the units of the equation) improved the condition number of the matrix by many orders of magnitude. Big picture, this did not have an apparent effect on any of the numerical performance - the linear solver still had nonconvergence in the same places (when I used a large number of processes) and when I use a smaller number of processors so that the linear solve always converges, the overall numerical scheme is unaffected by whether or not I scale the extra BC equation. I hadn't realized how important it is to make sure the equations are scaled consistently/nondimensionalize<wbr>d when using the convergence number to evaluate whether a system is singular. Interesting experience.<br>
><br>
> Thanks again for the help. I'll use the direct solver you suggested as a backup and send the user a warning if they try to use too many processors on a small problem.<br>
><br>
> An aside, at first, when I saw that my overall numerical scheme was failing, I didn't realize the problem was that the linear solver was not converging. I spent a fair amount time debugging until I found the issue and learned how to use KSPConvergedReason. Because if KSP doesn't converge, it merely returns incorrect numbers. Without knowing to run KSPConvergedReason, an inexperienced user (like me) many not know about the nonconvergence in the linear solve and could spend a lot of time checking for other issues. It might be worth changing the default behavior for nonconvergence to be that it returns an nan so that the user gets a clear signal that the values coming out of KSP cannot be used.<br>
<br>
   Because the linear solvers in PETSc are usually used by the nonlinear solvers and ODE integrators that have recovery methods for failure in a linear solve we moved away from the "crash and burn" on failed linear solver approach; since that makes the recovery more difficult.<br>
<br>
    We could consider the following; if the KSP is not created by a SNES or TS it defaults to "crash and burn" on failed linear solve this would help newbies who are only solving linear systems and expecting a "crash and burn" on failure.<br></blockquote><div><br></div></span><div>I am for that.</div></div></div></div></blockquote><div> </div><div>I like this feature.</div><div>Hong</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>  Matt</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
   What do people think?<br>
<br>
   Barry<br>
<br>
><br>
> Regards,<br>
> Mark<br>
><br>
><br>
><br>
> On Thu, Feb 2, 2017 at 7:48 AM, Jed Brown <<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>> wrote:<br>
> Mark McClure <<a href="mailto:mark.w.mccl@gmail.com" target="_blank">mark.w.mccl@gmail.com</a>> writes:<br>
><br>
> > I think you are right that I have an issue with how the BC is implemented.<br>
> > It is a pipe flow simulation that is solving mass and momentum balance<br>
> > simultaneously (corresponding unknowns are pressure and flow rate). I am<br>
> > applying a constant mass flow rate boundary condition. Upon further<br>
> > consideration, it may be that I am not properly providing a boundary<br>
> > condition for the momentum balance equation at the inlet. If I did, the<br>
> > inlet pressure could be readily calculated standalone,<br>
><br>
> Momentum inflow is common, but if you also have momentum outflow (i.e.,<br>
> all Dirichlet conditions for momentum) then there is a null space of<br>
> constant pressure -- pressure is only determined up to a constant.<br>
> See the user manual section on solving singular equations.<br>
><br>
> > outside the system of equations, and the problematic equation would be<br>
> > removed.<br>
><br>
<br>
</blockquote></span></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_-2584988518352596139gmail_signature" data-smartmail="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</font></span></div></div>
</blockquote></div><br></div></div>