Re: [Libmesh-users] Lagrange Convergence - Finish line From: Roy Stogner - 2008-07-10 23:37 ```On Fri, 11 Jul 2008, Maxime Debon wrote: > Using the example 0 was the good trick, I finally found that even with a > simple ODE problem, the maximum number of solver iterations was important ... > > > // ----------------------------------------------------------------------- > equation_systems.parameters.set > ("linear solver maximum iterations") = 1000; > // ----------------------------------------------------------------------- > > So, the problem disappears with an higher max. number or putting the line as > a comment. Whew! Good to know it wasn't a bug, at least. I'm surprised that the quadratic Lagrange elements turned out to be the choice that needed the most solver iterations, though. Even more than cubic Hermites! Personally I set the max iteration count ridiculously high when I'm solving a linear problem; unless you've got a nonlinear solver that will take more outer iterations to cover up for a bad linear solve, a bad solution is usually worse than no solution at all. --- Roy ```

[Libmesh-users] Lagrange Convergence Maxime Debon <maxime.debon@et...>
 Re: [Libmesh-users] Lagrange Convergence From: Roy Stogner - 2008-07-10 01:33 ```On Thu, 10 Jul 2008, Maxime Debon wrote: > However, this only occurs when quadratic (Edge3) and cubic (Edge4) > shape functions are used. Using linear Lagrange (Edge2) or cubic > Hermite (Edge3) verify the stability of the error when incrementing > the number of elements (To one thousand or more). What happens with quadratic Hierarchic elements? I find it hard to imagine that we've got a bug in any of the 1D Lagrange shape functions, but if that's the case then using a different implementation (and a slightly different basis) for the same function space would be the fastest way to confirm it. --- Roy ```

 Re: [Libmesh-users] Lagrange Convergence From: Roy Stogner - 2008-07-10 13:07 ```On Thu, 10 Jul 2008, Maxime Debon wrote: > Using a 1000 elements mesh, I made the computation with : > - HIERARCHIC Order 1 - Edge2 :: Success > - HIERARCHIC Order 2 - Edge3 :: Success > - HIERARCHIC Order 3 - Edge3 :: Success > - HIERARCHIC Order 4 - Edge3 :: Success > - BERNSTEIN Order 2 - Edge3 :: Success > - BERNSTEIN Order 3 - Edge3 :: Success > - BERNSTEIN Order 4 - Edge3 :: Success > - BERNSTEIN Order 5 - Edge3 :: Success > - BERNSTEIN Order 6 - Edge3 :: Success > - CLOUGH Order 2 - Edge3 :: Success > - HERMITE Order 3 - Edge3 :: Success > - LAGRANGE Order 1 - Edge2 :: Success > > The results are quite good with all these elements. The incredible behaviour > only happens with : > > - LAGRANGE Order 2 - Edge3 :: Problem > - LAGRANGE Order 3 - Edge4 :: Problem > > The problem seems to generate a solution whose node values are slightly > (really ) diminishing when the number of elements goes beyond 50 (80). Very strange. And it's going to be very hard to debug if it can't be triggered on simple meshes. How much simplification can you do and still see this behavior? You're running a nonlinear transient problem at the moment, right? --- Roy ```

 Re: [Libmesh-users] Lagrange Convergence From: John Peterson - 2008-07-10 13:39 ```On Wed, Jul 9, 2008 at 7:56 PM, Maxime Debon wrote: > NB: To implement the Neumann condition in a transient case, I finally > used, on the boundary, a finite difference approximation. This seems like it could be a problem if not done correctly at higher orders. What norm are you using to measure the error, and how are you computing it? -- John ```

 Re: [Libmesh-users] Lagrange Convergence - Finish line From: Maxime Debon - 2008-07-10 23:26 ```Hi, Using the example 0 was the good trick, I finally found that even with a simple ODE problem, the maximum number of solver iterations was important ... // ----------------------------------------------------------------------- equation_systems.parameters.set ("linear solver maximum iterations") = 1000; // ----------------------------------------------------------------------- So, the problem disappears with an higher max. number or putting the line as a comment. Thank you for your advice, Maxime ```

 Re: [Libmesh-users] Lagrange Convergence - Finish line From: Roy Stogner - 2008-07-10 23:37 ```On Fri, 11 Jul 2008, Maxime Debon wrote: > Using the example 0 was the good trick, I finally found that even with a > simple ODE problem, the maximum number of solver iterations was important ... > > > // ----------------------------------------------------------------------- > equation_systems.parameters.set > ("linear solver maximum iterations") = 1000; > // ----------------------------------------------------------------------- > > So, the problem disappears with an higher max. number or putting the line as > a comment. Whew! Good to know it wasn't a bug, at least. I'm surprised that the quadratic Lagrange elements turned out to be the choice that needed the most solver iterations, though. Even more than cubic Hermites! Personally I set the max iteration count ridiculously high when I'm solving a linear problem; unless you've got a nonlinear solver that will take more outer iterations to cover up for a bad linear solve, a bad solution is usually worse than no solution at all. --- Roy ```

 Re: [Libmesh-users] Lagrange Convergence - Finish line From: John Peterson - 2008-07-10 23:38 ```On Thu, Jul 10, 2008 at 6:24 PM, Maxime Debon wrote: > Hi, > > Using the example 0 was the good trick, I finally found that even with > a simple ODE problem, the maximum number of solver iterations was > important ... One should generally continue iterating until a suitable relative (or absolute) residual norm is reached, with correspondingly small Newton stepsize norm (for nonlinear problems). Reaching the max number of linear solver iterations before one of these other goals is achieved is probably best treated as a failure in a linear problem. The max number of iterations is just there to control how long you are willing to wait for an answer... -- John ```

 Re: [Libmesh-users] Lagrange Convergence - Not so sure From: Roy Stogner - 2008-07-11 23:31 ```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 ```

 Re: [Libmesh-users] Lagrange Convergence - Not so sure From: Derek Gaston - 2008-07-12 01:27 ```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 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 > Libmesh-users@... > https://lists.sourceforge.net/lists/listinfo/libmesh-users > ```

 Re: [Libmesh-users] Lagrange Convergence - Not so sure From: Roy Stogner - 2008-07-12 02:15 ```On Fri, 11 Jul 2008, Derek Gaston wrote: > 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. Seriously? Is this default PETSc behavior, or is this something in the libMesh interface that we need to change? > 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. This is definitely going to be a problem once we have more people using PETSc's nonlinear solvers. There's at least some status information we can get from the SNES object after the solve to let us know something's wrong, I assume? > 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!). That's my thinking, yes. Throw a "ConvergenceFailure" exception or some such, and then whatever catches it can change time step length or continuation step length or preconditioner complexity or whatever else it thinks will make a retried solve more likely to succeed. Maybe even "up the number of max its". I didn't think that made any sense at first glance. If you're willing to some number N > max_its iterations, why not set max_its = N in the first place? But maybe you want to examine the results of the partial solve and decide whether to change the linear system or preconditioner or just continue the solve as is. --- Roy ```

 Re: [Libmesh-users] Lagrange Convergence - Not so sure From: Derek Gaston - 2008-07-12 02:20 ```> change the linear system or preconditioner or just continue the solve > as is. > Yeah, I guess what I was thinking is that you examine the last few iterations... and maybe you were pretty close to your convergence tolerance but didn't quite make it (but still far enough away that you can't accept the solution) so you just bump max_its a bit and let it keep going. I don't know... just saying there's lots of possibilities.... Derek ```