sebapersson/sbmlimporter.jl

Import dynamic models in the SBML format into a ReactionSystem for Gillespie, SDE and ODE simulations

sbmlimporter.jl's Issues

Allow SBML import to a catalyst ReactionSystem

Currently models are imported as ModelingToolkit ODESystem - and we cover a relatively wide part of the semantic test-suite.

Naturally, it would be nice to have support for Catalyst ReacationSystem - at least for those cases where it is reasonable to have stochastic simulations in the model.

It should be relatively straightforward to achieve Catalyst support. Currently, the SBML model is parsed into a ModelSBML struct, which with other things stores the math for reactions, and their associated stoichiometry - which should be enough for translating efficiently into a Catalyst ReacationSystem.

As a starting example, it can be worthwhile to start with the first semantic test case, and see if the ModelSBML can be translated into a Catalyst ReacationSystem.

Update to ModelingToolkit v9

When possible should update to use ModelingToolkit v9. However, before this is done Catalyst must update.

Add Aqua.jl

For 1.0 it would be good to add a quality check via Aqua.jl.

Remove get_tstops function

Currently the SBMLImporter returns a get_tstops function for handling parameter dependent tstops. This can be avoided by adding tstops via the initialize argument to the callback.

Generate a common `ParsedReactionNetwork` structure with ReactioNNetworkImporters

Should have though of this earlier, but just realised, sorry.

ReactionNetworkImproters (https://github.com/SciML/ReactionNetworkImporters.jl?tab=readme-ov-file) implements a special ParsedReactionNetwork structure, which is the output when a reaction network model is read from a file. It contains the ReactionSystem model, but also other stuff like parameter values. This is the current structure (from https://github.com/SciML/ReactionNetworkImporters.jl/blob/master/src/ReactionNetworkImporters.jl):

struct ParsedReactionNetwork
    "Catalyst Network"
    rn::ReactionSystem

    "Dict mapping initial condition symbolic variables to values."
    u0::Any

    "Dict mapping parameter symbolic variables to values."
    p::Any

    "Dict mapping symbolic variable for species names to full string for species name"
    varstonames::Any

    "Dict from group name (as string) to corresponding symbolic variable"
    groupstosyms::Any
end

Would it make sense to try an make SBMLImporter generate a struct of the same type? Currently, events are created separately as callbacks, so a field would need to be added for these as well. But if possible, one could do things like creating overloads ODEProblem(prn::ParsedReactionNetwork), which both ReactionNetworkImporters and SBMLImporter could use.

Allow for efficient and correct SSA simulations

Currently when importing by default we set only_use_rate=true for a Catalyst.Reaction. The drawback with this is that it does not allow for efficient SSA simulations. To allow for efficient SSA simulations for reactions where it makes sense only_use_rate should be set to false, and for reaction that make sense I mean reaction with:

• Involved species have only_substance_units=true (species are given in amount)
• The propensity does not depend on assignment rules, rate-rules etc...

How to do this in practice? If these criteria are fulfilled it should be enough to just divide with the reactants in the propensity (@TorkelE)? To test correctness we can use test-case 1-39 in the stochastic part of the SBML test-suite.

If a user tries to create a JumpProblem for a model where only_substance_units=true (e.g. that might happen a specie is given in unit of conc.), once the import struct is done #16 , a warning can be thrown in the overload method.

Remove ifelse_t0 function vector

Currently for model with ifelse we rewrite to callback. However, to make sure that the ifelse variable has a correct value at time 0, the importer returns a function vector ifelse_t0. This could be avoided by using initialization for the ifelse callback.

TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Update docs for 1.0

With the push to 1.0 a lost has happened that is not in the docs. The docs should therefore be updated to show:

1. What is needed for a SBML importer to achieve efficient SSA simulations (hasOnlySubstanceUnits=true for model species)
2. How to simulate a model as a JumpProblem, SDEProblem and ODEProblem
3. Update differences to SBMLToolkit

More efficient import for large models

For large SBML models (>1000 species) import is currently very slow. This is mainly due to sub-optimal coding patterns, e.g. nested for-loops to check if a formula has a reaction id etc. This can be avoided by, for example, extracting identifiers from SBML-math while parsing to check if a formula for example has a reaction id.

Error with importing SBML file

I'm trying to import the SBML model from https://www.ebi.ac.uk/biomodels/BIOMD0000000627#Overview. I use the following code:

using ModelingToolkit
using Downloads
using SBMLImporter

URL = "https://www.ebi.ac.uk/biomodels/model/download/BIOMD0000000627.3?filename=BIOMD0000000627_url.xml"
output = Downloads.download(URL)
mdl, cb = load_SBML(output)
sys = ODESystem(mdl)

But I get the following error:

ERROR: UndefVarError: `F_in` not defined
Stacktrace:
 [1] top-level scope
   @ none:1

Where F_in should be one of the variables in the model.

The SBML file imports fine using a tool like Copasi, so I think it isn't related to the file alone.

Any idea what is happening here? Or whether I'm doing something wrong?

Thanks in advance!

Remove check_massaction option in load_SBML

Currently load_SBML by default has check_massaction=true - reactions are automatically rewritten to mass-action reactions if possible. However, the heuristics are imperfect which sometimes cause bugs for the user, e.g. see #43.

With the recent addition of the mass_action argument the user can specify if they are confident the model is mass-action. I think this is the best option for efficient mass-action jump simulations.