Report invalid Jacobian values at the starting parameters

[timmens]

• optimagic version used, if any: 0.5.2

What would you like to enhance and why? Is it related to an issue/problem?

If the Jacobian value is invalid (infinite or NaN) at the starting parameters, an error should be thrown. Currently, no error is thrown, and the optimization simply fails.

MRE

import numpy as np

import optimagic as om
from optimagic.optimization.optimize import minimize


def fun(x):
    return np.sum(x ** 2)

def jac(x):
    return np.full_like(x, np.nan)

# the following runs without error
minimize(
    fun,
    np.arange(2),
    jac=jac,
    algorithm=om.algos.scipy_lbfgsb,
)

[Aziz-Shameem]

Hey @timmens
I think this case is covered in this PR
Do we intend to provide a different error message when the nan values appear at the start VS when they appear during the optimization ?

[timmens]

Hey! Yes, we intend to provide a different error message when something goes wrong at the start vs. when something goes wrong after updating the starting values. The knowledge that this happened at the start is extra information that might be helpful for the user for debugging purposes.

[Aziz-Shameem]

I see.
Maybe I can take this up as an addition to the other PR.

[janosg]

The error handling for the user provided functions at the start parameters is done here for the objective function and here for all other functions.

Currently we only check that the function evaluations do not throw an error but not if the result is valid (e.g. not NaN and finite). If any value is not NaN or not finite we also want to throw and InvalidFunctionError (as opposed to the UserFunctionRuntimeError you get when the initial evaluations were fine but problems ocurred at a later stage).

Doing the finiteness checks is a bit hard because at this very early stage of processing we cannot assume too much on the output format of the functions. So I think the best place to do the checks for all user provided functions (including fun, which can be accessed via problem.fun_eval or the first_crit_eval variable) here, where you can use the converter to create flat versions of all the function outputs.

Before you start you need to familiarize yourself with the Converter and the different classes we use to represent the outputs of fun

[Aziz-Shameem]

Hi
Is my understanding correct :

1. We want to check for nan and inf values in all user provided functions - fun, jac, fun_and_jac
2. We want to implement this check at the start parameters
3. This check will return an InvalidFunctionError as opposed to UserFunctionRuntimeError that is returned for such errors later during optimization. The error message needs to be different too, appropriately.

Also, since we are doing this, would it not be complete to add this check on fun for nan/inf values occurring later during optimization ? (right now it is done only for jac). I assume the check for jac covers the check for fun for most optimizers/optimizations, but not for all.

[janosg]

Hi @Aziz-Shameem, yes you understand this correctly.

We could add a check for NaN on the fun value later during optimization but inf/-inf can be handled by some optimizers (mostly gradient free global ones) so we would not want to throw an error.