-
-
Notifications
You must be signed in to change notification settings - Fork 196
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
Parameter Identifiability Analysis #170
Comments
Also this : https://arxiv.org/pdf/1507.02543.pdf and this: https://journals.aps.org/pre/abstract/10.1103/PhysRevE.94.032221 Areas where ModelingToolkit may help. |
Concerning this issue in ModelingToolkit.jl, the point is that the parameter sensitivity matrix is a matrix of Lie derivatives. The Lie derivatives should be a standard operator in ModellingToolkit.jl which is then used for practically all methods of sensitivity analysis in DiffEqSensitivity.jl. Except for this IR issue of sensitivity matrix (Lie derivatives), Parameter identifiability analysis should be transfered as an issue in DiffEqSensitivity. The contribution of https://bmcsystbiol.biomedcentral.com/articles/10.1186/s12918-017-0428-y is essentially to measure and propose to resolve the ill-conditioning of the parameter sensitivity matrix. There are many methods already available that are well resumed in the introduction of this paper https://royalsocietypublishing.org/doi/full/10.1098/rsif.2017.0871. However, the information gain approach proposed in the latter paper deserves to be investigated as an efficient bypass of MCMC methods while still based on the standard sensitivity matrix. |
Well there's structural identifiability and practical identifiability. Structural is in the domain of ModelingToolkit, while practical is in the numerical domain of DiffEqSensitivity. |
Correct. It would be nice to have the structural identifiability generated automatically by ModellingToolkit as an elementary input to almost all methods of practical identifiability. In addition, since it is a Lie derivative it should already be available efficiently somewhere in Julia. |
http://qcpages.qc.cuny.edu/~aovchinnikov/seminar.html is a gold mine of stuff, including http://qcpages.qc.cuny.edu/~aovchinnikov/slides/NikkiMeshkat.pdf and https://arxiv.org/abs/1801.08112 |
In addition to NikkiMeshkat, the gold mine brings back to the fore Julia Banga et al, http://qcpages.qc.cuny.edu/~aovchinnikov/slides-Banga.pdf . I brought the AMIGO2 code in Matlab to your attention when you initiated DiffEqParamEstim. They are back with inverse optimal control and identifiability in both variables and parameters https://academic.oup.com/bioinformatics/article/34/14/2433/4924215 relying on GenSSI and DAISY toolboxes in (unfortunately) Matlab. My point of view on this subject is that you have achieved quite satisfactorily variable identifiability for nonlinear ODEs in DataDrivenDiffEq with the Lorenz example using Sindy. the next steps there would be to work on noisy data to establish the limits of the current solutions. The reason I open this issue specifically in ModelingToolkit is to gauge if ModelingToolkit can be used to define symbolically a generalised optimal control problem (e.g. Bolza problem) with feedback control in terms of functional forms for Lagrangian, Hamiltonian, payoff function, HJB, value function, IVP, FVP, infinite horizon with a view to output an ODEProblem or SDEProblem that can fit straight into a DiffEq solver like NeuralNetworkDiffEq or DataDrivenDiffEq. This higher level formulation is missing for dynamic systems although I sense that you @ChrisRackauckas know a lot about what has and has not been done already in this area. Please let me know where I should post this Optimal Control formulation problem. You participated to a chat "Solving an optimal control problem with JuMP" that shows that this continuous time problem can only be solved satisfactory in the DiffEq ecosystem. |
...to output an ODEproblem, PDEproblem, SDEproblem and perhaps MFGproblem.... |
Yeah, please open an issue on optimal control. This is the kind of thing this library is made to handle. My view is that we can have a high level definition of an optimal control problem, and indeed different methods and discretizations can be added as transformations of |
Never despair! This issue was opened in August 2019. This SIAN-Julia or more precisely the API identifiability_ode should be a standard feature of MTK. This is an important building block in specifying and testing models. It should almost be automatic that for any model, identifiability be checked first before anything else, particularly data fitting. I am unable to run the SIAN-Julia example because the Julia version is a thin wrapper of Maple, Fortran and others. GAP cannot be installed properly in my environment so I will take their word for it for now. This could be a nice project to profile the identifiability_ode API to be 100 % Julia. |
Yes, we're talking with the authors about that. It just needs a little bit of interfacing and it should be a lot easier for users to connect to it. Stay tuned. |
Wanted to mention this new package: https://github.com/pogudingleb/StructuralIdentifiability.jl |
@pogudingleb is there a reason that you don't use any sciml packages? You seem to have implemented |
@anandijain This is a very relevant point. I was looking at the |
StructuralIdentifiability.jl |
ON IDENTIFIABILITY OF NONLINEAR ODE MODELS AND APPLICATIONS IN VIRAL DYNAMICS
http://brain2.math.fau.edu/~ntuncer/resources/075700R.pdf
https://arxiv.org/ftp/arxiv/papers/0812/0812.4701.pdf
https://arxiv.org/pdf/1307.2298.pdf
The text was updated successfully, but these errors were encountered: