search

SciML / ModelingToolkit.jl

An acausal modeling framework for automatically parallelized scientific machine learning (SciML) in Julia. A computer algebra system for integrated symbolics for physics-informed machine learning and automated transformations of differential equations
https://mtk.sciml.ai/dev/
Other
1.41k stars 203 forks source link

Parameter Identifiability Analysis #170

Closed ChrisRackauckas closed 6 months ago

ChrisRackauckas commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

https://bmcsystbiol.biomedcentral.com/articles/10.1186/s12918-017-0428-y

finmod commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

ChrisRackauckas commented 4 years ago

https://www.sciencedirect.com/science/article/abs/pii/S0025556409001485

finmod commented 4 years ago

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 commented 4 years ago

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

ChrisRackauckas commented 4 years ago

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 commented 3 years ago

https://arxiv.org/abs/1910.03960 https://www.sciencedirect.com/science/article/pii/S074771711300165X https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.308.6010&rep=rep1&type=pdf https://www.biorxiv.org/content/10.1101/2020.02.04.933630v1.full

ChrisRackauckas commented 3 years ago

https://github.com/afvillaverde/strike-goldd

ChrisRackauckas commented 3 years ago

https://github.com/alexeyovchinnikov/SIAN-Julia

finmod commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 6 months ago

StructuralIdentifiability.jl