I might mention that this same thing happens with the NonlinearSystem class and Petsc SNES. If it hits max linear its on any of the linear solves during a non-linear solve... the whole code just silently quits. Usually this happens during the first linear solve... so when it quits it writes out the solution vector... which just looks like the initial condition. There is nothing to indicate what happened. I've been meaning to do something about this for the past couple of weeks... but it's still on my todo list.
In general I'm not a fan of throwing exceptions... I think a lot of that comes from my Java days where people WAY overuse exceptions.... and it ends up taking over your code (I worked on a couple of codes that had way more lines of code for exception handling than for the actual program logic!). That said, I do think it fits in this situation. If we could throw an exception that could be caught it could open up all kinds of possibilities (for instance, in a transient setting you might cut down on your dt... or even just up the number of max its if you've got cycles to burn!). Just thought I would mention that I'm seeing similar behavior... and when a colleague of mine was running my code he got pretty confused when his solve came back from the supercomputer and all he saw was the initial condition.... Derek On Fri, Jul 11, 2008 at 5:30 PM, Roy Stogner <[EMAIL PROTECTED]> wrote: > > On Fri, 11 Jul 2008, Maxime Debon wrote: > > > Back to Lagrange, the new file uses the penalty method. > > This one gives me a perfect straight line answer, with the SVN libMesh > and my default options, in parallel or serial... with the exception > that the lower boundary is at a value of 1e-10 instead of 0, of > course. > > Ah, but it looks like if I get rid of my default PETSc options, I get > that nasty curve instead! It's still an incomplete solve; you're just > hitting the default max iterations count of 5000 rather than a > user-imposed count. > > I'm going to copy this to libmesh-users, even though it's just the > same problem again; we ought to be able to come up with some behavior > better than "quit silently with the wrong solution" when a max > iteration count is reached. It feels to me like the "right" thing to > do would be to throw an exception, so that an outer nonlinear or time > solver would have a chance to recover but a user of the linear solver > alone could get some feedback as to what went wrong. However, we've > still got exception throwing as an optional libMesh feature (one > that's not even in a non-SVN release yet, I think), and this would be > the first time we used it for anything other than an unexpected error. > --- > Roy > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Libmesh-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/libmesh-users > ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
