sebapersson / PEtab.jl

Create parameter estimation problems for ODE models
https://sebapersson.github.io/PEtab.jl/stable/
MIT License
29 stars 4 forks source link

Supporting PEtab select and Catalyst models #108

Open TorkelE opened 10 months ago

TorkelE commented 10 months ago

It would be neat if one could integrate PEtab select's feature for model selection with models declared in Catalyst (similar as was done for normal PEtab models).

I am not fully familiar with PEtab select, but would something like this make sense?

using Catalyst

rn = @reaction_network begin
    k1, X --> Y
    k2, Y --> Z
    k3, Z --> V
    k4, V --> W
end

r1 = @reaction k_r1, X --> Z
r2 = @reaction k_r2, X --> V
r3 = @reaction k_r3, Y --> V
r4 = @reaction k_r4, Z --> W
reactions = [r1, r2, r3, r4]

Here, the user provides similar data as for creating a PEtabModel from rn using the Catalyst route. Next one supply a list of candidate reactions (stored in reactions) on which to run PEtab select.

Are there some additional points I am missing, and would this make sense to support?

sebapersson commented 10 months ago

I agree support for PEtab-select with Catalyst model would be great addition.

Briefly, PEtab-select allows model selection over a parameter space - where for each parameter in the parameter space the user can specify if they want to fixate a parameter to a value, or if it should be estimated. Then different methods like backward or forward selection can be used. Currently for all bookkeeping (generating candidate models) we use the petab-select python package.

I like your suggestion with reactions, to connect with PEtab select we would also need to allow the user (for each reaction) if optional to provide potentially fixated value for the parameters governing said reaction. Maybe, it could be good to allow the user to also provide, as an alternative to reactions, parameters to perform the selection over?

TorkelE commented 10 months ago

Sounds good. Next time we have a chat we could discuss further.

dilpath commented 10 months ago

Sounds good to me, selecting reactions is an intuitive way to see model selection with CRN-based models. As you have just one parameter per reaction in your example, specifying the model space in terms of reactions or parameters is equivalent. Supporting the specification of the model space in terms of both makes sense -- the former for intuitiveness, the latter as this is what PEtab Select is designed for.

In the case where you want to disable a reaction that involves multiple parameters, then you might want to add some "indicator" binary parameter to each reaction, such that PEtab Select can toggle groups of parameters on or off. At the moment, PEtab Select supports groups of parameters only via multiple rows in the model space. However, I see that being able to toggle groups of parameters on or off with meta grouping parameters would be a helpful addition.

Here's one possible workflow

  1. Catalyst.jl user requests model selection over reaction network rn. rn contains reactions r1 and r2. r1 involves parameter k1, r2 involves parameters k2a and k2b.

  2. Catalyst+PEtab.jl create the PEtab Select files automatically, including a new PEtab Select "meta grouping parameters" file like

    - reaction_r1:
    - k1
    - reaction_r2:
    - k2a
    - k2b
    and the standard PEtab Select model space file, but now with the metaparameters model_subspace_id petab_yaml reaction_r1 reaction_r2
    ... ... 0;estimate 0;estimate
  3. When generating candidate models, PEtab Select will automatically either set all parameters of a reaction to 0, or set all of them to be estimated together.

There are some open issues with the above still, e.g. the user has no control over which reactions are in the model selection problem, and the user isn't able to fix e.g. k2a to a specific value. I see some "easy" solutions for both though, so no real issues I think.

sebapersson commented 10 months ago

Thanks a lot for the input @dilpath - I like the workaround with an indicator (which I also see as quite straightforward to implement and workarounds can be found for cases like k2a) - and agree that allowing to turn of either parameters or reactions is a good path forward.

I will discuss this with Torkel next week, and then setup a first draft, would be great to have your input on this draft.