Simulation experiments on logical models

[matthiaskoenig]

Topic

This proposal covers logical models.

Proposal

A proposal draft for SED­ML to cover models encoded in SBML Qual was written up:

This is available at
https://github.com/SED-ML/sed-ml/blob/master/specification/proposals/SEDMLextensionforSBMLQual.pdf

[jonrkarr]

In my opinion, the existing SED-ML constructs are sufficient to capture simulations of logical models. For example, we now have BoolNet working with SBML-qual, SED-ML, and multiple logical simulation algorithms. This uses SED-ML uniformTimeCourse, a new KiSAO terms for an additional algorithm, and new KiSAO terms for parameters. To make it work within the current structure of SED-ML, we used JSON to encode the value of 1 parameter into SED-ML. This demonstrates that SED-ML can be used with logical simulations, or any other formalism. For portability between simulation tools, the community needs to align on the data types for these parameters. With BioSimulators, we've created a space for the community to share this information.

While simulations of other formalisms can be encoded into SED-ML, SED-ML could provide more direct support for other formalisms. The advantages would be a cleaner XML encoding and more ability to validate descriptions of simulations at the SED-ML format level. However, I don't think these are strong advantages. SED-ML files are already not particularly easy for humans to read. Trying to make them more human readable would add minor value. Second, simulation experiments generally require more validation beyond whether they adhere to the syntax of SED-ML. Adding SED-ML classes for domain-specific simulations wouldn't eliminate the need for simulation tools to validate simulation experiments.

I think there is a need to make SED-ML easier to use for other domains. However, I would not suggest that SED-ML try to add extensions for specific domains as proposed in the above link. Basically, the document above proposes a high barrier to entry for new domains, which will prevent their adoption of SED-ML.

• The process for adding extensions would likely be too formal and too slow. For example, although the document above was written five years ago, SED-ML still cannot be used for logical simulations.
• This would lead to the need for many extensions for various algorithms, which would create a lot of work. The reason is that these extensions are necessary not for specific domains, but for specific algorithms. While there's a most number of distinct domains of computational biology, the number of algorithms is large.
• This breaks down the abstraction barrier between SED-ML and individual model languages.

Instead, I think there's a simpler and easier way to support additional domains

• Add URNs for other model formats. Better is to embrace a larger community effort to catalog formats such as EDAM.
• Data types for parameters: Make it easier for domains to encode information into parameters by allowing investigators to declare their data types.
• Implicit targets for data generator variables
• Forum for discussion about the representation of simulation experiments with a lower barrier to entry: Provide a less formal space for developers and investigators to find how others are encoding similar information about similar experiments. The SED-ML specifications provide a mechanism for the community to discuss how to capture simulation experiments. But, the bar to expand or modify this is high. There needs to be a more bottom-up place to propose how to represent a simulation experiment and see how other investigators are approaching similar problems that investigators can more easily contribute to.

[luciansmith]

Is there anything that needs to be updated in the spec itself to make this work, insofar as it currently works at all?

[jonrkarr]

The specifications could (a) note that tools are free to be more restrictive than the SED-ML schema (i.e. only support integer-valued time courses) and point to an example (can be external to the specifications). I can share an example. The example would also be an example of how to properly deal with multiple namespacea.

In my opinion, the other information needed for logical simulations has to get encoded into either model changes or algorithm parameters. This is the same as for kinetic models.

[luciansmith]

The decision at the 6/16/21 Editor's Meeting was to create a generic 'Algorithm' class to allow this and other options.

[luciansmith]

New text:

"2.2.6.4 Analysis
The Analysis represents any sort of analysis or simulation of a Model, entirely defined by its child
Algorithm. If a simulation can be defined by a different Simulation, that should be used instead, so
that tools are more likely to recognize the request. But for any simultion or any analysis not covered
by SteadyState, OneStep, or UniformTimeCourse, the only thing necessary is a KiSAO term for the
Algorithm defining what to do.
Listing 2.41 shows the use of the analysis element.

<listOfSimulations>
 <analysis id="reachability">
   <algorithm kisaoID="KISAO:0000972" />
 </analysis >
</listOfSimulations>

Listing 2.41: The SED-ML analysis element, defining a reachability analysis of a logical model."

I made up KiSAO term 972; once a real KiSAO term is created that would make a good example, this should be switched.

[jonrkarr]

One concrete example is a network free simulation (KISAO_0000263) with BioNetGen with a stop condition (KISAO_0000525) algorithm parameter. This would be better encoded with the new class because the simulation length is not known ahead of time. To work well, we'll need more KiSAO terms for initial time, output start time, etc. See SED-ML/KiSAO#96.

Another example is a discrete event simulation with Smoldyn (KISAO_0000057) where output should be observed at each event rather than fixed, predetermined time intervals.

[luciansmith]

Can you give me XML for the 'analysis' of those two examples?

[jonrkarr]

The two I mentioned are below. A third is an integration with OpenCOR over a variable other than time (currently OpenCOR+SED-ML treats this with UniformTimeCourse even though there's no time involved).

There's only a small amount of work required to make all of these work.

A concrete logical modeling example could be added once KiSAO terms are created.

Simulate a time course until a stop condition becomes true

Simulation tool: BioNetGen
Algorithms: CVODE: KISAO:0000019, SSA: KISAO:0000029, PLA: KISAO:0000524, NFsim: KISAO:0000263
Example model: https://github.com/KarrLab/h1_hesc/blob/a6361cd1bb6a6059a47dcacc2391f593d47ce921/cell_cycle/tyson_2011/hybrid_model/hybrid_model_rules.bngl

<listOfSimulations>
    <analysis id="time_course_to_stop_condition">
        <algorithm kisaoID="KISAO:0000263">
            <algorithmParameter kisaoID="KISAO:0000525" value="ObsA&gt;9"/>
        </algorithm>
    </analysis >
</listOfSimulations>

This isn't quite fully defined because there's no KiSAO term for maximum simulation length yet. To work more similarly to UniformTimeCourse with options for start time, output start time, and observed step size (different from integration step size), 3 more KiSAO terms need to be added.

Simulate a time course and observe each event

Simulation tool: Smoldyn
Algorithms: Brownian diffusion Smoluchowski method (KISAO:0000057)

<listOfSimulations>
    <analysis id="non_uniform_time_course">
        <algorithm kisaoID="KISAO:0000057">
        </algorithm>
    </analysis >
</listOfSimulations>

Similarly, fully specifying this requires another KiSAO term for simulation length.

ODE integration over a variable other than time

Simulation tool: OpenCOR
Algorithms: CVODE (KISAO:0000019)
Example model: https://models.cellml.org/exposure/dc3f6b6188dd7e15345da6b546c69407/sine-approximations.cellml/cellml_math

<listOfSimulations>
    <analysis id="integration_over_non_time_variable">
        <algorithm kisaoID="KISAO:0000019">
        </algorithm>
    </analysis >
</listOfSimulations>

Again, fully specifying this requires a maximum integration value (analogous to the role of UniformTimeCouse.outputEndTime).