It took me a while to get back to this as it was not originally a big issue.
AFAICT the libmesh method is translating codes from possibly many sources or solvers into something consistent for libmesh users. This seems to be a common problem- needing something efficient like int return codes along with slow string descriptions. I added to it by making yet another lookup in my own code quickly out of date wrt libmesh AND any solvers lol :) Maybe there is some general mechanism for converting int/enum to int or at least allowing the user to see that the return code is not known to the current library version and allow the user to do whatever with it. In the immediate case had the libmesh method done effectively what you suggest and just display the int returned by KSPConvergedReason that would have been all I needed right awy. Returning it would have been great too if there was some way to flag " this is the value from solver and not a libmesh enum ." Not sure you can just or with a flag bit given no constraint on what the solver could return and negatives are already in use :) Not sure anyone wants it to throw. As long as there is something sane in the solution everything can limp along for later diagnosis. Personally I'm just using an anomaly counter that tallies return code frequencies and various things in my own code that I look at later and putting this code in there makes it easy to look for all exceptional conditions later. ________________________________________ From: Jed Brown <j...@jedbrown.org> Sent: Monday, August 14, 2017 7:39 PM To: Mike Marchywka; John Peterson Cc: libmesh-users@lists.sourceforge.net Subject: Re: [Libmesh-users] "Unknown convergence flag!" Please, please use KSPConvergedReasons[reason], even if only for reasons that libMesh does not intelligently handle. It is a string representation of the reason -- you can print it and the user won't have to look it up in an enum. Mike Marchywka <marchy...@hotmail.com> writes: > AFAICT the actual problem has been fixed, > > https://github.com/libMesh/libmesh/pull/976/files > > except that the error report could be more informative. However, > this would probably work too for anyone reading archives, > > http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/KSP/KSP_DIVERGED_PCSETUP_FAILED.html > > Notes: Run with -ksp_error_if_not_converged to stop the program when the > error is detected and print an error message with details. > > once you have some idea where to look. I changed my data a bit and not > getting the problem now. Thanks. > > ________________________________________ > From: Mike Marchywka <marchy...@hotmail.com> > Sent: Monday, August 14, 2017 3:09 PM > To: John Peterson > Cc: libmesh-users@lists.sourceforge.net > Subject: Re: [Libmesh-users] "Unknown convergence flag!" > > ________________________________________ > From: John Peterson <jwpeter...@gmail.com> > Sent: Monday, August 14, 2017 2:51 PM > To: Mike Marchywka > Cc: Roy Stogner; libmesh-users@lists.sourceforge.net > Subject: Re: [Libmesh-users] "Unknown convergence flag!" > > On Mon, Aug 14, 2017 at 12:38 PM, Mike Marchywka > <marchy...@hotmail.com<mailto:marchy...@hotmail.com>> wrote: > > ________________________________________ > From: Roy Stogner <royst...@ices.utexas.edu<mailto:royst...@ices.utexas.edu>> > Sent: Monday, August 14, 2017 1:27 PM > To: Mike Marchywka > Cc: John Peterson; > libmesh-users@lists.sourceforge.net<mailto:libmesh-users@lists.sourceforge.net> > Subject: Re: [Libmesh-users] "Unknown convergence flag!" > > On Mon, 14 Aug 2017, Mike Marchywka wrote: > >> Is libmesh too old to recognize all the return codes from ksp > > Perpetually. We add new codes from time to time, but so does PETSc. > > We really should use the PETSc API here to print some sane string from > within libMesh, though, not just "unrecognized". A PR would be > appreciated. > > Thanks. I guess just printing the unrecognized code would make it possible > for the > user to look it up and that is really all I need now. Although if you print > general error messages from insdie the code that should not fail, > > But libmesh doesn't throw an error/fail when > PetscLinearSolver<T>::get_converged_reason() gets an unrecognized reason, it > just prints a message to std::err. Is it your code that is throwing the error? > > -- > John > ---------------------------------- > No one is throwing - that was my point. If you do what you do now just adding > the file/line info and unrecognized > value to the output would help. If the value is reasonable for the PETSc I'm > linked to that is one thing, if it is > xCDCDCDCD that is another problem :) Thanks. > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Libmesh-users mailing list > Libmesh-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libmesh-users > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Libmesh-users mailing list > Libmesh-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libmesh-users ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
