Re: [Libmesh-devel] VTK output fails in parallel

2011-02-23 Thread Roy Stogner
On Wed, 23 Feb 2011, Roman Vetter wrote: > I suppose it's a matter of opinion/objective. Do the libMesh > developers/users want their solution output either > > a) complete, including higher order terms, in a way that complies with > the VTK file format, but not necessarily perfectly visualizable

Re: [Libmesh-devel] convergence reason in PETSc nonlinear solver

2011-02-23 Thread Roman Vetter
> So there are a couple options for exposing reason to the user. > > 1. Send the raw backend-specific enum to the user. Downside: user needs to > write different code for each back end. > > 2. Always convert to some new libmesh enum. Downside: conversion from > backend value to generic value is not

Re: [Libmesh-devel] convergence reason in PETSc nonlinear solver

2011-02-23 Thread Jed Brown
On Wed, Feb 23, 2011 at 14:05, Roman Vetter wrote: > Exactly. That's kind of the point. In order to be able to call > SNESConvergedReasons[reason], the reason enum/int must be stored > before _snes gets destroyed, which it isn't currently. Which brings be > back to my initial suggestion. > So the

Re: [Libmesh-devel] convergence reason in PETSc nonlinear solver

2011-02-23 Thread Roman Vetter
> Having a switch statement like that is pretty silly. You can get the reason > in string form (const char *) with > > KSPConvergedReasons[reason] > > The solver has converged if reason>0 and diverged if reason<0. > > The same applies to SNES, use SNESConvergedReasons[reason] to get the > string. >

Re: [Libmesh-devel] convergence reason in PETSc nonlinear solver

2011-02-23 Thread Jed Brown
On Wed, Feb 23, 2011 at 11:12, Roman Vetter wrote: > - The PETSc linear solver provides a print_converged_reason() member, > which includes the KSPConvergedReason enums, but not all of them! > Having a switch statement like that is pretty silly. You can get the reason in string form (const char *

Re: [Libmesh-devel] convergence reason in PETSc nonlinear solver

2011-02-23 Thread Roman Vetter
> I definitely agree with letting the application code access the > convergence/divergence reason, but not so much with making it an > opaque PETSc-specific int. A new enum_convergence.h would fix all > three of those problems at once, if you wanted to go to the trouble. > You wouldn't need to bot

Re: [Libmesh-devel] VTK output fails in parallel

2011-02-23 Thread Roman Vetter
2011/2/22, Roy Stogner : > >>> Does VTK have native support for higher-order data? If so, adding >>> that to our VTKIO output would be fantastic. >> >> Yes, VTK does, but it's not implemented in VTKIO. I attached a patch >> that does it. :-) > > Does it, but how well? It looks like the higher ord