Closed coltonbh closed 2 years ago
Another one for ya @loriab :)
@loriab wanted to check in on this now that I'm back to developing a bit. Old PR--possible to merge in? This fixes basic error handling that was incorrect inside the berny
procedure.
Thanks!
Is it necessary to declare types in the function signature using the "" employed previously in this method? Seems more canonical to declare return types without "" values unless they are the class being defined in a https://github.com/classmethod. I have followed the convention already in the code but would consider updating it to remove the "" if allowed.
The "" types in function signatures are a legacy of (1) mypy being fired up for these repos only every year or two and (2) Sphinx docs not being able to do anything with signature types at the time of documentation. Without quick feedback on typing right/wrong, it was easiest to use the harmless strings. Now that #362 modernizes docs to use types from signature, I'm all for starting to convert to non-"" types. Once docs links are clean enough, we can turn on warnings-to-errors and nitpicky so that the docs build does some type checks (at least that imports work).
Description
Closes #300 .
Changelog description
Handle gradient computation errors correctly inside of
BernyProcedure.compute()
methodNote on decisions
.compute()
call signature to reflect the possibility of returning aFailedOperation
. While theOptimizationResult
object may havesuccess=False
, it still requirestrajectory
andenergies
attributes, both of which cannot beNone
, and if a gradient computation fails on its first iteration it is not possible to create anyAtomicResult
orenergies
values; thus it is not possible to return anOptimizationResult
object, even withsuccess=False
set on the object.Open Questions
Status