Properly handle compute errors raised in berny optimization procedure

[coltonbh]

Description

Closes #300 .

Changelog description

Handle gradient computation errors correctly inside of BernyProcedure.compute() method

Note on decisions

• Updated the .compute() call signature to reflect the possibility of returning a FailedOperation. While the OptimizationResult object may have success=False, it still requires trajectory and energies attributes, both of which cannot be None, and if a gradient computation fails on its first iteration it is not possible to create any AtomicResult or energies values; thus it is not possible to return an OptimizationResult object, even with success=False set on the object.

Open Questions

• 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 @classmethod. I have followed the convention already in the code but would consider updating it to remove the "" if allowed.

Status

• [ x] Code base linted
• [ x] Ready to go

[coltonbh]

Another one for ya @loriab :)

[codecov]

Codecov Report

Merging #301 (0490362) into master (cf5fdc5) will decrease coverage by 10.96%.
The diff coverage is 96.15%.

[coltonbh]

@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!

[loriab]

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).

[loriab]

Suggested change

	input_data = OptimizationInput(**input_data)
	ret = qcng.compute_procedure(input_data, "berny", raise_error=False)
	input_model = OptimizationInput(**input_data)
	ret = qcng.compute_procedure(input_model, "berny", raise_error=False)

"model" for pydantic obj and "data" for dict is my convention. but my aim is merely a dummy commit to trigger CI.

[loriab]

I've hit this too. Thanks for the fix!