MTK and SI ODEs have different formats for variable identifability

[TorkelE]

Simple example:

using StructuralIdentifiability, ModelingToolkit

@mtkmodel mtk_ode begin
    begin
        @variables t
        D = Differential(t)
    end
    @parameters begin
        p1
        p2
    end
    @variables begin
        x1(t) # dependent variables
        x2(t)
        y(t), [output = true]
    end
    @equations begin
        D(x1) ~ p1 - x1
        D(x2) ~ p2*x1 - x2
        y ~ x2
    end
end
@named mtk_ode = mtk_ode()

si_ode = @ODEmodel(
    x1'(t) = p1 - x1(t),
    x2'(t) = p2*x1(t) - x2(t),
    y(t) = x2(t)
)

mtk_ident = assess_identifiability(mtk_ode)
si_ident = assess_identifiability(si_ode)

Here we have

julia> mtk_ident
Dict{SymbolicUtils.BasicSymbolic{Real}, Symbol} with 4 entries:
  x1(t) => :nonidentifiable
  p2    => :nonidentifiable
  p1    => :nonidentifiable
  x2(t) => :globally

julia> si_ident
Dict{Any, Symbol} with 4 entries:
  x2 => :globally
  p1 => :nonidentifiable
  p2 => :nonidentifiable
  x1 => :nonidentifiable

with x1 and x2 being functions of time in the first case, and not in the second case. My impression is that it is the identifiability of the initial conditions (of x1 and x2) that is assessed, is that correct? If so, would it make sense to have x1 and x2 being the names in the MTK case? Or even possibly write it as x1(0) and x2(0) for both cases?

[sumiya11]

Hi @TorkelE , Thanks for the example !

In both cases, identifiability results for states are given are as functions of time. For example, if we report x2(t) (or x2) identifiable, we mean that x2 is identifiable for each moment in time (including x2(0)).

For si_ident = assess_identifiability(si_ode) we just don't have the (t) in the output due to some internal implementation details.

PS. is y(t) = y(t) in the si_ode a typo? I am quite surprised and happy that it (presumably) works even like this 😅

[TorkelE]

Sounds good! Thanks for the clarification :). Yes, y(t) = y(t) is a typo, fixed it now.

Gleb said that there were cases when initial conditions where identifiable, but not trajectories, are these common? Also, if you support identifiability for those, would you then have two outputs for each initial conditions (one the trajectory and one the initial condition)?

[sumiya11]

Gleb said that there were cases when initial conditions where identifiable, but not trajectories, are these common? Also, if you support identifiability for those, would you then have two outputs for each initial conditions (one the trajectory and one the initial condition)?

Hm, I don't think we support such cases (I think the situation where the ic can be reconstructed but the trajectories are not identifiable is not possible, but I am not very sure :^) ). It'd better if @pogudingleb could clarify

[pogudingleb]

@TorkelE , my apologies if something I said before caused any confusion!

I completely agree with Sasha (@sumiya11 ) that the outputs you get should be interpreted in the same way: the whole trajectory is identifiable (in other words, the state is observable). The reason they are displayed differently is purely implementational, and now I see that this may be quite misleading, so I have just created a dedicated issue.

For the inputs accepted by StructuralIdentifiability right now, identifiability of the value of the state at one point in fact implies the identifiability of the whole trajectory. However, if we were accepting, as a part of input, the information that some initial conditions are known (we do not at the moment, and there is an issue for this), then there could be a case when initial condition is identifiable but the whole trajectory is not.

I hope this clarifies the issue!

[TorkelE]

Thank you, no I think I had some misconceptions before, but now I understand fully what is going on, thanks a lot!. Given #243, I will close this issue.

[sumiya11]

@TorkelE Now I recall that you have mentioned that the identifiability result is valid for initial confitions in your new tutorial in Catalyst.jl (sorry I think I missed this part when I was reading the first time). It is correct, but probably it would make sense to change the wording to reflect that the identifiability results also hold for the whole trajectories

[TorkelE]

Yes, I will do a rewrite beginning of next week. I hope to make the final (for this PR) changes, and then hold of further changes until later (potentially awaiting some updates in StructuralIdentifiability.jl).