Well, getting the string from the originator of the code may not be a bad idea
but once you get a code that does
not make sense any more calls may be a concern although sure mostly it is
version problems.
I thought printing the int would be no effort and no risk. If you know what
solver you are going to link with
at libmesh compile time you could even generate the code.
I suppose someone could set up industry standard enums, it works for port
numbers and stuff lol.
I'm sure this is low on any priority list but typical default handler may just
print a swtich value. fwiw
________________________________________
From: Jed Brown <j...@jedbrown.org>
Sent: Wednesday, August 16, 2017 1:39 PM
To: Mike Marchywka; John Peterson
Cc: libmesh-users@lists.sourceforge.net
Subject: Re: [Libmesh-users] "Unknown convergence flag!"
Mike Marchywka <marchy...@hotmail.com> writes:
> 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.
>From that code:
switch(reason)
{
[...]
case KSP_DIVERGED_INDEFINITE_MAT : return DIVERGED_INDEFINITE_MAT;
case KSP_CONVERGED_ITERATING : return CONVERGED_ITERATING;
#if !PETSC_VERSION_LESS_THAN(3,7,0)
case KSP_DIVERGED_PCSETUP_FAILED : return DIVERGED_PCSETUP_FAILED;
#endif
default :
libMesh::err << "Unknown convergence flag!" << std::endl;
return UNKNOWN_FLAG;
}
My point is that this should, at a minimum, use
KSPConvergedReasons[reason] instead of the mysterious and unhelpful
string. An alternative would be to allocate new return codes and add
the string translation to a lookup table so the caller can work with it,
but that is a much larger change.
> 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
