Use of gradient calculation in acq_funct's

[sqbl]

Hi,
Our acq functions have implemented the ability to return gradient (https://github.com/novonordisk-research/ProcessOptimizer/blob/762732e84e07859f9460903ffb62584d7059f052/ProcessOptimizer/acquisition.py#L117C1-L119C34). I do not see the neccesity for returning said gradient. If I'm mistaken, then disregard this Issue.
Alternatively, I propose that we change the acq.functions (and the corresponding tests).

Without gradients, we will have a more easy approach to implement new acq functions.

[sqbl]

If and when we are to look into new acq functions, this could serve as points of inspiration:
scikit-optimize/scikit-optimize#528 (remember to look into if Sobol can be replaced to e.g. scipy or plain old random) nEI looks good in some examples, but can also offer no improvements in other examples: scikit-optimize/scikit-optimize#415, scikit-optimize/scikit-optimize#452)
Or this: sustainable-processes/summit#72
Or these/this: https://github.com/kiudee/bayes-skopt/blob/master/bask/acquisition.py

[sqbl]

See also: scikit-optimize/scikit-optimize#460

And finally: remember, that there is already greedy A optimum implemented: scikit-optimize/scikit-optimize#432

[sqbl]

This seems like some interesting new acq functions that could be looked into:
scikit-optimize/scikit-optimize#1156

[SRFU-NN]

Suggestion for solution to be implemented:

Change acquisition functions so they always return a tuple, with the second entry (grad) being None if they don't calculate gradient.
If grad from acquisition function is None, get scipy to estimate gradients.

#221 closed
See #209

[SRFU-NN]

Though this is changing the return type of a central function, which is a big task.