Notebook

Running scripts in the IDE¶

This short notebook explains how to run scripts in the IDE, and discusses the pros and cons of using Myokit's embedded script feature.

Myokit .mmt files can contain a Model, Protocol, and/or embedded script. If present, the script is shown on the "Embedded script" tab. Scripts must start with the header [[script]], but can then contain any old Python code -- even Python code that doesn't use Myokit or does dangerous things like deleting your favourite files!

There are three main differences between using the script tab or using external Python scripts:

In the script tab, you can access the model and protocol via get_model() and get_protocol(). In external Python scripts you must use myokit.load_model() and myokit.load_protocol() (or myokit.load()).
In the IDE, some feedback on simulation progress is provided via a progress bar. This is not enabled by default in external scripts.
The "embedded script" is packaged in a single file with the model and protocol.

Points 2 and 3 are discussed in more detail below.

Getting progress updates in external scripts¶

Myokit simulations and some other long-running methods accept a ProgressReporter as an extra argument. This is used to show a progress bar in GUI environments, but can also be used in external scripts to provide some text-based user feedback. An example simulation run with the ProgressPrinter reporter is shown below:

In [1]:

import myokit
model, protocol, _ = myokit.load('models/c/decker-2009.mmt')

s = myokit.Simulation(model, protocol)
d = s.run(1000, progress=myokit.ProgressPrinter())

[0.0 minutes] 10.1 % done, estimated 0 seconds remaining
[0.0 minutes] 12.4 % done, estimated 0 seconds remaining
[0.0 minutes] 22.2 % done, estimated 0 seconds remaining
[0.0 minutes] 36.1 % done, estimated 0 seconds remaining
[0.0 minutes] 58.3 % done, estimated 0 seconds remaining
[0.0 minutes] 100.0 % done, estimated 0 seconds remaining

Pros and cons of embedded scripts¶

Myokit's embedded scripts were designed with sharing in mind: A cardiac electrophysiology model downloaded from the internet can be pretty hard to understand unless it's packaged with some good initial conditions, a pacing protocol, and ideally some representative simulation code.

However, there is a downside to using embedded scripts, in that they can lead to situations where there are several copies of the same model, potentially with small differences between the model definitions. This has the potential to create unnecessary confusing and/or bookkeeping, and can make it harder to make your work reproducible.

In general, the following strategy is advised:

Use embedded scripts during development, to play around, and to share early results with colleagues and collaborators.
Write your final simulation code in external Python files that all load and re-use the same model code. Publish these files along with a single copy of the model when you publish your paper!

Of course, in many cases you will want to modify a model before running a simulation. Instead of modifying the model code, this can be done dynamically, via Myokit's model API. This is the subject of a later notebook.