-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Recommended approach for utilising gradients #12
Comments
Gradient-based optimizers in general should be more efficient than derivative-free. You can use this gradient in |
Thanks, this works. I also checked with another person who suggested I have tried using gradients, however, the result seems wrong? When checking the result using gradients, the found points have identical parameter values to the initial point (except for the one I am computing the profile with). When I do it without gradients, all parameter values are different in the profile end points. This does not seem to be directly tied to using a gradient-dependant local alg. This seems weir, right? I am investigating closer, but also figured I'd ask if it is something that you recognise. |
Hm, seems gradient based (starting with |
Yes, it is the same model (although the data points are different, I can try and give you an updated file with the new data points) |
I have sent an updated project folder |
It's a bit weird but it seems the gradient-based methods need much lower tolerance to work properly. In your example I get the same result with
|
Thanks, that did work. However, the runtimes suffer quite bad. E.g. for |
I should not that even for |
A final note (sorry for all the comments). When I run using a gradient-based method, also supplying a gradient, I get lots of ┌ Warning: autodiff gradient is not available, switching to finite difference mode
└ @ LikelihoodProfiler ~/.julia/packages/LikelihoodProfiler/Qi97K/src/cico_one_pass.jl:67 messages. Exactly what does this mean? I am supplying a gradient, so autodiff should not be relevant? |
In theory the gradient-based methods should be faster. With your model I see that the number of likelihood function calls ("right/left CP counter") with The warning with |
The warning are from a large scan of auto-generated data sets on a hpc, so it is non-trivial to create a reproducing MWE. I will have a go through, and report to you when/if I get one |
I have created an optimisation problem using PEtab.jl. This gives me a gradient, which I have tried to adapt to LiklihoodProfiler's format using
My impression is that, by default, this gradient is not utilised. What combination of (profiling) method and local algorithm do you recommend for utilising gradients properly?
What kind of advantage can I expect to get if I have a gradient?
The text was updated successfully, but these errors were encountered: