Interactive Modeling— Experiment Protocol and Simulation Studies

Practical computer simulation is not simply a matter of programming and
solving model equations. We must also make it convenient to modify our
models and try many different experiments (see also Section 1-5). In addition
to DYNAMIC program segments listing the model equations (1-1), each sim-
ulation study requires an experiment protocol program that sets and changes
initial conditions and model parameters, calls computer runs, and displays or
tabulates solutions for different model configurations.
The simplest experiment protocols are just sequences of successive
commands, say
a = 20.0 | b = – 3.35 (set parameter values)
x = 12.0 (set the initial value of x)
drun (make a differential-equation
-solving simulation run)
reset (reset initial values)
a = 20.1 (change model parameters)
b = b – 2.2
drun (try another run)
Dynamic-system Models and Computer Programs 3Each drun command calls a differential-equation-solving simulation run, and
reset resets initial conditions. Typed commands ought to execute immediately
to permit interactive modeling. The operator inspects the solution output after
each simulation run and then types new commands for the next run. Command-
mode operation also permits interactive program debugging [5].
A simulation study combines such commands into a storable program seg-
ment (experiment-protocol script) that can branch and loop to call repeated
simulation runs for different parameter combinations. Simulation studies
may involve thousands of model and parameter changes, so programming
must be easy and computations must be as fast as possible. This is why we
like to interpret experiment-protocol scripts and compile the program seg-
ments executing the actual simulation runs.

Simulation Software
Commercially available equation-oriented simulation programs such as
ACSLTM accept system equations in a more or less human-readable form,
sort defined variable assignments as needed, and feed the sorted equations to
an optimizing Fortran or c compiler [5]. Berkeley Madonna and DESIRE
(see below) have built-in equation-language compilers and execute immedi-
ately. Block-diagram interpreters (e.g., SimulinkTM, VissimTM, and the open-
source program Scicos) permit graphical block-diagram composition and
immediately execute interpreted simulation runs. Such programs usually pro-
vide equation-language blocks for complicated expressions. Interpreted code
is slow; production runs are sometimes translated into c for faster execution.
Alternatively, ACSLTM, Easy5TM, and Berkeley Madonna have block-diagram
preprocessors for compiled simulation programs. More advanced modeling
is possible with the Modelica language

OPEN DESIRE and DESIRE
The simulation programs described in this book, and, in particular, our new
techniques for model replication (vectorization), Monte Carlo simulation,
and submodels (Chapters 3–7), use the open-software simulation package
OPEN DESIRE for Linux, Unix including Cygwin (Unix under Windows),
and Microsoft WindowsTM, or the commercially available DESIRE/2000
program for Windows.

DESIRE simulation systems allow inexpensive per-
sonal computers and workstations solve thousands of differential equations
in seconds.
DESIRE uses double-precision (64-bit) floating-point arithmetic and
accepts command scripts and model descriptions in a readable mathematical
notation such as
y = a
*
cos(x) + b d/dt x = – x + 4
*
y
Command scripts can include operating-system calls, shell scripts, and calls to
other computer programs. DESIRE’s command-script language is itself a
general-purpose mathematical language and handles vectors, matrices, and
even complex numbers (e.g., for frequency-response and root-locus plots)
Programs are entered and edited in editor windows. Each program
begins with an experiment-protocol script that is interpreted much like an
advanced Basic dialect. When the experiment-protocol script encounters a
drun statement, a built-in runtime compiler automatically compiles a
DYNAMIC program segment listing model equations. The state-equation-
solving simulation run then executes at once and produces solution displays
in bright color.
Very fast compilation (typically under 50 ms) simplifies interactive mod-
eling. Experimenters can immediately observe results of programmed or
screen-edited models and experiment-protocol changes. One can enter and
edit different models in multiple editor windows and run these models in turn
to compare results (Fig. 1-1). Runtime displays show solution time histories
and error messages during rather than after each simulation run, so that you
can save time by aborting undesirable runs before they complete.
The experiment-protocol script starting each DESIRE program defines an
experiment. Subsequent DYNAMIC program segments define models used
in the experiment and specify runtime input/output requests. An experiment
protocol can call multiple DYNAMIC segments with different models, dif-
ferent versions of the same model, and/or different input/output operations.