Skip to content
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

Closed
ChrisRackauckas opened this issue Aug 26, 2019 · 19 comments
Closed

Parameter Identifiability Analysis #170

ChrisRackauckas opened this issue Aug 26, 2019 · 19 comments
Labels
analysis A transformation pass that doesn't make a new system.

Comments

@ChrisRackauckas
Copy link
Member

ChrisRackauckas commented Aug 26, 2019

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

@finmod
Copy link

finmod commented Sep 2, 2019

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.

@ChrisRackauckas
Copy link
Member Author

@finmod
Copy link

finmod commented Nov 4, 2019

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.

@ChrisRackauckas
Copy link
Member Author

Well there's structural identifiability and practical identifiability. Structural is in the domain of ModelingToolkit, while practical is in the numerical domain of DiffEqSensitivity.

@finmod
Copy link

finmod commented Nov 4, 2019

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.

@ChrisRackauckas
Copy link
Member Author

@ChrisRackauckas
Copy link
Member Author

@finmod
Copy link

finmod commented May 12, 2020

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.

@finmod
Copy link

finmod commented May 12, 2020

...to output an ODEproblem, PDEproblem, SDEproblem and perhaps MFGproblem....

@ChrisRackauckas
Copy link
Member Author

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 OptimalControlSystem, turning it into ODESystem, SDESystem, or even straight discretization into a fully nonlinear OptimizationSystem. Then we would rely on the compilation process of those systems to generate the code. This is then somewhat similar to how ReactionSystem transforms into JumpSystem, ODESystem, and SDESystem. If we have a contextually-symbolic form of the optimal control problem we can in theory make it very easy to generate the code for all of the forms that could show up.

@ChrisRackauckas ChrisRackauckas added the analysis A transformation pass that doesn't make a new system. label Mar 11, 2021
@ChrisRackauckas
Copy link
Member Author

@ChrisRackauckas
Copy link
Member Author

@finmod
Copy link

finmod commented Apr 7, 2021

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.

@ChrisRackauckas
Copy link
Member Author

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.

@pogudingleb
Copy link

Wanted to mention this new package: https://github.com/pogudingleb/StructuralIdentifiability.jl
In terms of efficiency it in a general position with the Maple version of SIAN (may be faster, may be slower, more benchmarking in progress). Can also assess local identifiability separately pretty fast since it implements the Sedoglavic algorithm.

@anandijain
Copy link
Contributor

@pogudingleb is there a reason that you don't use any sciml packages? You seem to have implemented @ode_model on your own, but maybe parameterized functions or MTK would suffice. Tight integration would be great to have, since we'd probably want to do a pass in MTK, without type conversion

@pogudingleb
Copy link

@anandijain This is a very relevant point. I was looking at the ODEproblem from DifferentialEquations.jl but it typically does not involve the information about observations. However, I plan to write a converter for some popular formats/datatypes and would appreciate any suggestions for this.

@ChrisRackauckas
Copy link
Member Author

StructuralIdentifiability.jl

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
analysis A transformation pass that doesn't make a new system.
Projects
None yet
Development

No branches or pull requests

4 participants