Consolidate different gradient checks

Feature description Currently we have several different (rather redundant) gradient checking routines, which only have slightly different functionalities, which in my opinion do not all justify being there in parallel. (In the end: We want to have a minimal interface to the outside world to be user-friendly):

In objective/base https://github.com/ICB-DCM/pyPESTO/blob/0aaa34179497c429434b4b6d2aeb35309b113961/pypesto/objective/base.py#L370

https://github.com/ICB-DCM/pyPESTO/blob/0aaa34179497c429434b4b6d2aeb35309b113961/pypesto/objective/base.py#L422

https://github.com/ICB-DCM/pyPESTO/blob/0aaa34179497c429434b4b6d2aeb35309b113961/pypesto/objective/base.py#L589

In the PEtab importer https://github.com/ICB-DCM/pyPESTO/blob/fb2be819b41411dc1686d8429ce5efa6c535b70b/pypesto/petab/importer.py#L83

Motivation/Application I think, that having one FD check in objective/base and maybe another one for checking multiple eps values is great. The one in the PEtab importer is clearly redundant, since you would rather create a problem object, and then call a gradient check on that (which is also, what the function does…). The third function in the objective base also seems close to the other ones and not “general purpose”.

Therefore I would like to

a) propose to get rid of the gradient check in the PEtab importer and would like to

b) open the discussion, if the third gradient check in objective/base adds enough “general purpose” value, that it justifies to have and maintain an other gradient checking method there.

Opinions? @yannikschaelte @dweindl @stephanmg

[stephanmg]

As far as this concerns the function I’ve added, I can consolidate in the following way:

1. check_gradients function in PEtab importer can be removed from the code base (The function can be implemented outside of pyPESTO if really nobody thinks it might be useful to have)

2. check_gradients_match_finite_differences can be made pseudo-private to not clutter the public API. It willl be used only internally in a visualization method I plan to PR into pyPESTO anyway.

Does this sound reasonable? Feel free to assign me if you think that’s appropriate.

[yannikschaelte]

If I see correctly, (1)+(2) should be the base implementation. (4) autofills petab nominal parameters, which seems reasonable (not sure if there is room for simplification there though). (3) conceptually takes the output of (2) and actually compares the obtained atols+rtols, which (1)+(2) fail to do. Thus I guess (3) also makes sense to keep, as otherwise one would need to have binary output for (1)+(2) whether the df or bool is of interest. It seems however that (3) could be simplified to e.g. not redefine mode + multi_eps, but just call (2) and evalute the outputs.