Chapter 7

Simulation Design

475-Simde
 Modeling Concepts

476-Simde
Modeling Concepts Introduction

Simde.1 Introduction

Previous chapters of this manual discuss how models of networks, nodes, and
processes can be defined using OPNET. The purpose of defining the models is to
be able to exercise them in a dynamic simulation in order to study system
performance and behavior. In this chapter, we will discuss the steps that follow
model specification in order to actually run simulations and collect information
from them. The contents of this chapter are summarized in the following table:

Simulation Design
Simulation Design Chapter: Content Summary
Section Topic

Specifying Data Collection Presents the various types of sup-

ported data that can be generated by a
simulation and the mechanisms that
enable its collection.

Simulation Construction Discusses the various components of a

simulation program and how a model
specification is used to produce an
executable simulation.

Simulation Execution Describes OPNET’s facilities for run-

ning simulations and interacting with
them.

Simde.2 Specifying Data Collection

At various stages during model development, OPNET users may wish to

conduct simulations in order to test correct operation of the model. When the
model has attained a complete form, simulations are run to actually study the
system’s behavior and performance. However, before beginning simulations, the
user must consider what information is to be obtained. In certain cases may
OPNET may require some additional specifications in order to cause that
information to be generated. In this section, we will discuss what types of outputs
can be offered by an OPNET simulation, and the mechanisms that are available to
extract them.
Simde.2.1 Phases of Data Collection

Models of complex systems typically evolve through stages of increasing

complexity. As the model developer progresses, new features are added to the
model until it converges on the desired level of realism. In the earlier stages, model
developers typically run simulations for the purpose of verifying the specifications
they have completed so far. In general, verification involves checking that some or
all of the following criteria are met:

477-Simde
Specifying Data Collection Modeling Concepts

Criteria Considered for Verification during

Early Modeling Phases
Observable Criteria

Progress Simulation progress is the most basic criteria and is always

examined first, often in an implicit manner by analyzing the
remaining criteria. The model developer must of course verify
that the simulation can be assembled and executed, and that
it can process events, and finally reach completion without
encountering serious errors. The number of events executed
must appear reasonable; that is it must appear that there is
meaningful generation and processing of events, and also
that the density of events over simulated time is not excessive
(simulations that have too great a density of events appear to
advance very slowly).

Flow of Data Basic flow of packets in the system model is analyzed to

ensure that packet generation, connections, and links are
properly configured and that there are no unexpected bottle-
necks or packet “sinks” in the system.

Basic Statistics Certain basic metrics in the system are understood in

advance, or the model developer may have an intuitive notion
of the range that the statistic should fall in. A subset of these
statistics may be observed in the simulation in order to deter-
mine if the model has generally valid behavior.

Key Events If particular events are expected to occur at known times, or if

particular processing is expected when certain events occur,
the model developer may wish to specifically analyze activity
of the model surrounding those events in order to ensure cor-
rectness.

Because the model developer typically needs to perform this type of work on a
fairly frequent and repetitive basis, it is important that the observables of interest
be quickly and conveniently accessible.OPNET provides features that directly
support these types of verifications, as described in subsequent sections.

As a modeling project reaches later stages, model developers begin to focus on

extracting information from the simulation that is specifically related to the goals
of their project. This may of course include the items appearing in the table above.
In addition, there are usually very specific questions to answer, as described in the
following table.

478-Simde
Modeling Concepts Specifying Data Collection

Information Collected in Later Modeling Phases

Observable Details

Application-Specific Statistics Each modeling project typically seeks to

determine specialized metrics in order to
answer the questions of system designers.
These metrics may have to be obtained from
customized computations provided by the

Simulation Design
modeler. Numerical post-processing of sta-
tistics may also be required after simulations
complete.

Behavioral Characterizations A modeling project may also seek to charac-

terize system behavior in a non-numerical
manner. For example, particular sequences
of events or correlation of events may be of
interest to report.

Application-Specific Visualization Dynamic visualization can often provide a

better understanding of the system’s activi-
ties. In some cases, this may require cus-
tomized animation during simulation.

Simde.2.2 Classes of Simulation Output

OPNET simulations can generate a variety of types of output which are

applicable in different situations. Given that OPNET simulations can contain user-
defined code, it is clearly also possible to define and compute new types of
simulation output which can be reported during simulations or afterwards for post-
processing. This section enumerates common forms of simulation output and
indicates the type of support that OPNET provides for generating it. Automatic
support means that OPNET computes and records the information with no
programming required by the modeler. Programmatic support means that OPNET
provides programmatic interfaces that allow the modeler to record customized
output. Finally, unsupported means that the output the modeler can use the general
mechanisms of the programming language and the Operating System to generate
the output, but OPNET provides no specific implementation support.

479-Simde
Specifying Data Collection Modeling Concepts

Forms of Simulation Output

Form of Output Details Support

Output Vectors The history of a system vari- Automatic for built-in statistics pro-
able can be captured as it var- vided by OPNET; programmatic
ies over time in the form of an for customized statistics computed
output vector. (OV) OVs pro- by user-defined code.
vide insight into the manner in
which the system evolves and
its response to particular inci-
dents during a simulation.
Each OV consists of a series of
values and associated times. A
simulation can be configured
to simultaneously collect multi-
ple independent OVs.

Output Scalars Certain metrics of interest do Automatic for built-in statistics pro-
not vary with time. Instead, vided by OPNET; programmatic
they are a single value that is for customized statistics computed
representative of the system’s by user-defined code.
performance over the course
of the simulation (e.g., the
throughput of the network).
Each of these statistics is
called an output scalar (OS).
Each output scalar is typically
recorded only once per simula-
tion. Output scalars from multi-
ple simulations are then
combined to analyze their
dependency on simulation
inputs, also recorded as sca-
lars.

480-Simde
Modeling Concepts Specifying Data Collection

Forms of Simulation Output

Form of Output Details Support

Animation Visualization of system activity Automatic for standard forms of

can be a valuable tool for gain- animation provided by OPNET;
ing insight into behavior and programmatic for customized
interactions between compo- graphics computed by user-
nents. Simulations can gener- defined code.
ate animations as they run or
save them for playback after

Simulation Design
they complete.

Proprietary Since OPNET allows inclusion Unsupported by OPNET; relies on

Reports and Files of user-defined processes and C language and OS access.
link models, it is possible to
generate customized reports
or output files as the simulation
runs, or when it completes.
The general facilities of the C
language and the operating
system are used for this pur-
pose.

Output Files

As mentioned above, simulation results can take on several different forms

including visual animations, time-dependent series of values, and parametric
relationships. For those forms of output that are not interactively utilized (i.e., as
the simulation continues to run), results are accumulated in files residing in the
host computer’s filesystem, until a simulation completes. These contents of these
files may be displayed at the user’s convenience using appropriate tools. There are
three types of output files that may be directly generated by the Simulation Kernel.

481-Simde
Specifying Data Collection Modeling Concepts

Simulation Output Files

File Type Details

Output Vector Generated by simulations in order to store time-series data.

Each simulation generates only one output vector (OV) file
that contains all OVs that are selected for the run. OV files
may have user-specified names, or default to the name of
the network model. OV files can grow to be quite large
depending upon the number and length of the vectors con-
tained within them. A vector contains a series of time-value
pairs; both are stored as C doubles (typically 16 bytes per
pair).

OV files are identified by the“.ov” file suffix. Simulations

overwrite identically named OV files.

Output Scalar Generated by simulations in order to store individual values

that capture summarized behavior, performance, or param-
etrization of a simulation. OS files store data cumulatively,
so that new simulations append data to existing output sca-
lar (OS) files, rather than overwrite them. In this way, an OS
file can be used to capture trends or relationships between
parameters expressed by running a series of simulations.
Since each simulation generally results in the addition of
only a few values to an OS file, these files are usually quite
small in comparison to OV files.

Each simulation can modify at most one output scalar file.

OS files are identified by the “.os” suffix.

Animation History Generated to support post-simulation visualization of a

modeled system’s behavior. An animation history (AH) file
contains a sequence of animation commands which can be
interpreted by the animation viewer op_vuanim to graphi-
cally display selected model activities that occurred during
the simulation.

Each simulation can generate at most one AH file. Identi-

cally named AH files are overwritten. AH files are identified
by the “.ah” suffix.

opnet also maintains a log of errors and significant events that occurred during
a simulation. This log (a tab-delimited ASCII file) may be examined using the
simulation log browser. For details, refer to the Project Editor chapter in Editor
Reference.
Simde.2.3 Statistic Collection Mechanisms

In the case of most simulations, a large number of system variables and metrics
are available for collection. Each module at the node level, as well as link at the
network level is the source of a significant number of built-in local statistics, and in

482-Simde
Modeling Concepts Specifying Data Collection

addition a simulation can generate large numbers of global and local user-defined
statistics. However, in general, only a small subset of the available data is of
interest to the simulation developer. Also, collecting all possible information
would be prohibitive in terms of storage space and would negatively impact
simulation speed. To address this problem, OPNET provides mechanisms to
selectively specify which information should be collected as a simulation runs.
These mechanisms are described in this section.

Simde.2.3.1 Probes

Simulation Design
The flow of data into output files is controlled by a special object called a
probe. Probe objects are not part of the model itself, and they do not affect the
behavior of the model during simulation in any way. Instead, they play the role of a
passive data collection device, “attached” to an object in the model that is capable
of generating information in one of the forms described above. In the sense that it
is passive, an OPNET probe is much like an ideal oscilloscope probe used in
analyzing an electronic circuit. By decoupling probes from models, OPNET
provides a powerful mechanism for quickly altering specification of data
collection, without necessitating any changes to the model itself.

The purpose of a probe is to act as an enabler of output data that could

potentially be stored in the simulation’s output files. Each source of data that is not
explicitly probed is essentially “shut off”. OPNET takes the approach that output
sources are off by default because the number of sources virtually always vastly
outnumbers the number of sources of interest.

Probes can be specified using the Probe Editor, which allows the
correspondence between probe objects and model objects to be established via a
graphical selection. Any number of probes may be specified and the collection of
probes is saved as a probe list. The probes of a probe list are applied as a group to a
simulation model at the time that the simulation is executed. Multiple probe lists
may be separately specified for the same model. They may then be applied to the
model during distinct simulations, but only one probe list may be used for a given
simulation run.

There are several different types of probes, corresponding to the different types
of supported output and objects in OPNET. In broad terms, there are three types of
probes: statistic probes, animation probes, and attribute probes. Within each of
these categories there may be several additional varieties of probes. Each of these
is described in this section and summarized in the following table.

483-Simde
Specifying Data Collection Modeling Concepts

Supported Probe Types

Probe Type Applications Varieties

Statistic Collect data of a numerical form Node

generated either by built-in object Coupled Node
statistics, or by user-defined local Link
and global statistics. Can gener- Global
ate both output vectors and out-
put scalars.

Attribute Capture values of object and sim-

ulation attributes as output sca-
lars. These are viewed as “inputs”
to the simulation model.

Animation Enable graphical animation com- Automatic

mands to be issued by the simula- Custom
tion. Animations describe various Statistic
aspects of system behavior. They
can apply to particular objects,
models, and statistics, or can be
completely customized.

Each probe is an object with a set of attributes that specify which output source
it applies to, as well as various options concerning how to collect the data. The
attributes vary for each type of probe. For details on the use of each attribute, refer
to the Probe Reference chapter of Modeling Reference.

Simde.2.3.1.1 Statistic Probes

OPNET supports local and global statistics. Local statistics are associated with
particular objects, which the statistic probes must reference in order to collect data.
The specific objects that support local statistics are nodes, links, and modules.
Node statistics actually originate in modules or submodules within the nodes, but
they are promoted to the node level by the node model specification (refer to the
Node Domain chapter of Modeling Concepts for more information on statistic
promotion). This mechanism allows users of node models (such as IT
DecisionGuru users) to access these statistics without having internal knowledge
of the node model’s components. Node and module statistics are supported by the
node statistic probe object, which provides attributes for specifying the physical
object being probed, down to the submodule level if necessary. Node statistic
probes support both built-in statistics of objects, as well as the user-defined
statistics that are declared by process models. Link statistic probes provide access
to pre-defined statistics that are computed for point-to-point and bus link objects.
For complete information on the individual statistics that are pre-defined by
OPNET for each object, refer to the Node Reference and Network Reference
chapters of Modeling Concepts.

484-Simde
Modeling Concepts Specifying Data Collection

Objects that Generate Statistics

Processors Application-specific (defined by developer)

Queues and Application-specific (defined by developer), and statis-

Subqueues tics related to queue size, available queue space, over-
flow occurrences, queuing delays, etc.

Generators Output levels, interarrival times, sizes of packets, etc.

Simulation Design
Transmitter Throughput, utilization, queue size
channels

Receiver Throughput, utilization, collisions, error rates,

channels radio statistics (radio receivers only)

Links Throughput, utilization, error rates; collisions

Global statistics provide information that relates to the overall system. Many
separate objects may contribute to a single global statistic during a simulation. For
example, every node in a network model may use the same global statistic to
record the end-to-end delay experienced by the packets it receives. The result is a
single statistic for the network’s end-to-end delay performance. Global statistics
are declared by process models and are supported by the global statistic probe
object. Of course, no objects are referenced in a global statistic probe; only the
name of the statistic is specified.

Coupled node statistic probes record information relating to a particular

object’s activity with respect to its interaction with another object. Only a small
number of statistics in OPNET support coupled probing. Currently, these are all
statistics of the radio receiver channel object. The coupling mechanism allows the
probe to focus only on the performance of a link between the receiver channel and
a particular transmitter elsewhere in the model. For example, a coupled node
statistic probe allows the received power statistic of a receiver channel to
measure only the power of the signal incident upon the receiver from a specific
transmitter. The same statistics can be collected using an ordinary node statistic
probe, in which case it will represent the received power from any transmitter,
whenever activity occurs. In other words, the coupled node statistic probe provides
selectivity.

Radio Receiver Channel

Coupled Statistics
signal-to-noise ratio

bit error rate

packet error rate

485-Simde
Specifying Data Collection Modeling Concepts

Radio Receiver Channel

Coupled Statistics (Cont.)
bit errors per packet

received power

All statistic probes offer a set of common options that are specified via their
attributes. Each probe can act as the source of both output vector and output scalar
statistics, as specified by their vector data and scalar data toggle attributes.
Both may be simultaneously enabled. If vector data is enabled, all of the values
of the statistic are collected in an output vector in the simulation’s output file. The
vector’s statistic collection can optionally be restricted to a simulation time frame,
as specified by the values of the vector start and vector stop attributes. This
is often useful to reduce the storage requirements for very dense statistics,
particularly since only a portion of a statistic’s activity is usually of interest. Often,
this period is at the end of the simulation, or after a particular event of interest
(e.g., a component failure), in order to analyze transient behavior.

Limiting Vector Time-Spans with Probe Start and Stop Times

The same vector data collected via two

separate probes, one without time limits,
and the other limited to the time interval
between 100 and 500 sec.

If a statistic probe’s scalar data attribute is enabled, then the probe will
generate a single scalar value in the simulation’s output scalar file at the end of the
simulation. The scalar value is computed as a function of all of the statistic’s
individual values over the course of the simulation according to a specified metric.
As with output vector collection, the scalar statistics computation can be restricted
to the values experienced by the statistic during a particular period. This period is

486-Simde
Modeling Concepts Specifying Data Collection

specified using the scalar start and scalar stop attributes of the probe. The
supported metrics are specified using the scalar type attribute and are
summarized in the following table:

Scalar Types Supported by Probes

last value The value of the final update within the collection window

sample mean The mean of the values of all the updates in the collection window

Simulation Design
(i.e., the sum of all the update values divided by the number of
updates)

time average The average value over time of the values generated during the
collection window; this average is performed assuming a “sam-
ple-and-hold” behavior of the data set (i.e., each value is
weighted by the amount of time separating it from the following
update and the sum of all the weighted values is divided by the
width of the collection window)

variance The sample-oriented variance of all update values occurring in

the collection window (i.e., the mean value of the square of the
difference between the update values and their sample mean)

min value The minimum value encountered during the collection window

max value The maximum value encountered during the collection window

In certain cases, statistics experience such frequent change during a simulation

that collecting all of their values in output vector form becomes problematic.
Specifically, one or more vectors may require a prohibitive amount of disk storage
to be collected in their entirety. In addition, the frequent saving of the statistic may
reduce the performance of the simulation, even though OPNET uses mechanisms
to minimize this effect. In such cases, it may be desirable to reduce the size of the
data that is being collected, even at the cost of a certain amount of accuracy or
completeness. One mechanism that can be used is to limit the window of time over
which collection is performed, as was described earlier in this section. Another
approach, which can be applied separately or combined with windowing, is to
reduce the values of the statistic at a specified rate in order to generate a less dense
output vector. Statistic probes support “on-the-fly” processing of statistics, and
particularly reduction of statistics, via their capture mode attribute. A probe’s
capture mode specifies a method by which a statistic’s values can be modified as
they are updated. The modified values are stored in the output file, rather than the
“raw” values that are initially submitted to the probe. Four capture modes are
supported, as described in the following table.

487-Simde
Specifying Data Collection Modeling Concepts

Statistic Capture Modes

Mode Details

all values All updates to the statistic are recorded without modification.

sample Records only certain statistic updates, and ignores others.

Supports two modes: 1) retain every n_th update; or 2) retain
an update every T seconds.

bucket Considers a set of points called a “bucket” and records a sin-

gle value which is representative of the bucket. Buckets can
be specified as time intervals or by the number of updates
they contain. The retained value is computed as one of the fol-
lowing functions of the values in the bucket: sum/time, min
value, max value, sample mean, time average, and count.
This the default capture mode.

glitch removal When multiple updates to a statistic occur at the same time,
only the last update is retained.

Comparison of Normal Mode and

Bucket Mode with Time-Average Option

Normal mode data includes all up- Bucket mode data is a time average of up-
dates of the queue size, showing dates every 25 seconds. It is much sparser,
detailed changes over time. but captures the general trends over time.

Depending on the statistic and the goals of the modeler, different capture
modes or options of the capture mode may be more appropriate. The figure above
illustrates the effect of using the bucket capture mode when collecting a quickly
varying statistic, such as the size of a queue with roughly equal random arrival and

488-Simde
Modeling Concepts Specifying Data Collection

departure rates. The bucket mode results are useful because they show the general
trend of the statistic’s variations, even if they do not capture any of the rapid
changes. However, because the changes are rapid, the time-averaged bucket mode
output fails to show how high the queue size can get. With some statistics that can
quickly rise and fall, this deficiency can be even more pronounced. If a buffer is
being sized, for example, the peak values may be of interest. The result of using the
bucket mode with a maximum value computation appears below.

Simulation Design
Comparison of Normal Mode and
Bucket Mode with Maximum Value Option

The maximum size option of the bucket mode provides a sparse

vector that is an upper-bound “envelope” for the actual queue size.

Simde.2.3.1.2 Attribute Probes

Attributes specify characteristics of objects. Since they are part of the

specification of a model, they can be viewed as “inputs” to the simulation. This is
particularly clear when an attribute is promoted past the network level of the model
and requires an assignment to be provided at the time of simulation execution. It is
useful to introduce certain simulation inputs into the output files in order to
facilitate studying the dependencies that exist between simulation outputs and
inputs. For example, we may wish to analyze how the throughput of a network
varies as a function of the traffic load that is submitted. Or, we may be interested in
the end-to-end delay of traffic as a function of the speed of the network’s
transmission lines. In these cases, traffic load and transmission line speed are
model inputs that we would vary over a series of simulation experiments. In each
experiment we would record these inputs as well as the throughput and end-to-end
delay. By recording the input and output quantities together we can establish the
relationship that exists between them.

489-Simde
Specifying Data Collection Modeling Concepts

Since user-defined code can access the values of attributes and has the ability to
also write values into the simulation output files, it is of course possible for process
models to save attribute values in the simulation output files. Process models can
also perform computations that combine or otherwise process the values of
multiple attributes. However, in cases where the values of numerical attributes are
of interest without further processing, special probes called attribute probes can be
used. Numerical attributes include the integer, double, toggle, and toggle
double data types. Each attribute probe applies to one object or simulation attribute
and generates a corresponding scalar value in the output scalar file. The attribute
probe has an attribute called object that allows it to refer to any object at the
network or node level in the model. If a simulation attribute is declared by any of
the process models in the system, an attribute probe can refer to it simply by
leaving the object attribute blank. The following graph shows an example of a
plot that can be obtained using an attribute probe for the independent variable (i.e.,
input), and a statistic probe for the dependent variable (i.e., output).

Scalar Plot Generated Using Output of

Statistic and Attribute Probes

Each point in the plot is the result of one simulation. The value of
“Processing Speed” changes and is recorded by an attribute probe
in each simulation. The resulting value of “Peak Queue Size” is re-
corded by a statistic probe. Both are scalars and can be plotted
against each other in the Analysis Tool.

490-Simde
Modeling Concepts Specifying Data Collection

Simde.2.3.1.3 Animation Probes

OPNET provides a mechanism called an animation probe which is used to

enable and configure the generation of animation information as a simulation runs.
The basis for the use of animation probes is similar to that of statistic probes;
namely that a very large amount of animation data could be collected in a typical
simulation, while only a small part of it may actually be of interest. By specifically
indicating which aspects or physical parts of a model should be animated, the flow
of resulting information can be kept manageable.

Simulation Design
Three types of animation probe objects, called automatic animation probes,
custom animation probes, and statistic animation probes, may be placed in a
simulation’s probe file to enable generation of animation data. Multiple probes of
each type may coexist within the same probe file. Automatic animation probes and
statistic animation probes both enable built-in animation capabilities of OPNET
models. They provide the simplest means of obtaining animations with an OPNET
simulation, since no additional specifications are required within the model.
Custom animation probes act as an enabling device for animation requests that are
generated by user-defined processes. Custom animations provide flexibility to
represent general information during an animation, but require programmatic
specification by the model developer.

Automatic Animation Probes

Animation probes can be placed on objects in both the network and node
domains. Depending on the type of object affected by the probe, different types of
animations will result, as summarized in the table below. For complete
descriptions of the functionality provided by each type of automatic animation,
refer to the op_vuanim Utility chapter in Utility Programs.

Supported Forms of Automatic Animation

Object Type Automatic Animation Type

Subnetwork Animation of packet flows over point-

to-point and bus links present within
the subnetwork. Animation of mobile
and satellite node movement within
the subnetwork

Node (fixed, mobile, or satellite) Animation of packet flows over packet

streams within the node

Processor or queue Animation of state-transitions of root-

level process within selected module

Each automatic animation probe includes attributes called subnet, node, and
module used to specify the affected object. The representation attribute is then
used to select the desired form of automatic animation. In addition, each probe
includes attributes to restrict the simulation time window during which it will be

491-Simde
Specifying Data Collection Modeling Concepts

active, and to control the positioning and dimensions of the resulting animation
window. For a description of the automatic animation attributes, refer to the Probe
Reference chapter of Modeling Reference.

Custom Animation Probes

If automatic animations do not provide all of the functionality required by the

model developer, OPNET allows the developer to create customized animations
that are better-suited to, or more complete for particular applications. Customized
animations are implemented using the Anim package Kernel Procedures (KPs) that
called from process models or pipeline stages. These procedures provide general
drawing and animation capabilities as well as functions related specifically to
displaying OPNET models. Refer to the Animation Package chapter of Simulation
Kernel for complete specifications.

Because animation can significantly degrade simulation performance, it is

important to be able to selectively enable its generation. In particular, during long
simulation runs, or sequences of simulation runs, animation is usually disabled
entirely. Since custom animation is generated by user-developed logic, it is
possible for developers to incorporate their own animation control mechanisms. In
general, such a mechanism could be based on the use of object or environment
attributes, queried using the KPs of the Ima package. Based on the values of these
attributes, animation code could be conditionally executed.

OPNET provides a built-in mechanism for selectively enabling animation,

called custom animation probes. Just like an automatic animation probe, a custom
animation probe is associated with an object from the network or node domain.
However, rather than resulting in the generation of a standard form of animation, a
custom animation probe serves as an enabling agent for the animation directives
that are executed within the context of the probed object. In other words, by
default, calls to animation-related Kernel Procedures are ignored, unless an
appropriate custom animation probe is defined to enable their actions.

The context of a custom animation probe, or the scope of animation directives

that it can enable, depends upon the type of object to which it is applied.
Ultimately, the source of custom animation directives must be either process model
logic, or transceiver pipeline stage logic, since these are the interfaces supporting
the integration of user-developed code. For a processor or queue to be the subject
of a custom animation probe implies that animation directives executed by any of
the processes contained within it can make use of the probe. This extends to the
procedures of a process’ function block and to procedures defined in external files,
while they are executed in the context of the probed module. Similarly, if a
transceiver (either point-to-point, bus, or radio) is the subject of a custom
animation probe, then animation directives issued from within associated pipeline
stages, including indirectly called procedures, are affected by the probe. The
following table summarizes the scope of custom animation probes for each
supported object type:

492-Simde
Modeling Concepts Specifying Data Collection

Scope of Custom Animation Probes

Type of Enabled Sources of
Probed Object Animation Directives

Subnetwork All processes executing within modules con-

tained at any level of depth; in addition, all pipe-
line stages associated with transceiver modules
or with links contained at any level of depth.

Simulation Design
Node (fixed, mobile, All processes executing within any processor or
or satellite) queue contained within the node; in addition all
pipeline stages associated with transmitter or
receiver modules within the node.

Processor or Queue All processes executing within the processor or

queue.

In the case of transceiver pipeline stages, there is a well-defined association

with either the transmitter that acts as the source, or the receiver that acts as the
destination during a pipeline execution. The following table summarizes this
association for the purposes of determining where to place animation probes. Note
that the radio pipeline stage “receiver group” is missing from the table because it is
not associated with any particular transceiver; thus, any animation directives
executed within this stage are ignored.

Transceiver Associations for Pipeline Stages

Pipeline Type Transmitter-Associated Receiver- Associated
Stages Stages

Point-to-Point transmission delay, error allocation,

propagation delay error correction

Bus transmission delay, collision,

closure, error allocation,
propagation delay error correction

Radio transmission delay, receiver antenna gain,

closure, received power,
channel match, background noise,
transmitter antenna gain, interference noise,
propagation delay signal-to-noise ratio,
bit-error-rate
error allocation
error correction

Custom animation probes have a set of attributes that is essentially the same as
that of automatic animation probes: attributes specifying the probed object, a time-
window of effectiveness, and the geometric properties of the display window. In

493-Simde
Specifying Data Collection Modeling Concepts

addition, an attribute called label can be used to specialize the applicability of the
probe. User-defined code can determine if a probe with a particular label exists,
and if so, which animation viewer (i.e., animation window) is associated with that
probe. The code can then enable appropriate animation requests and direct them to
the required windows. The label also serves as a rendezvous mechanism, allowing
different processes and pipeline stages to obtain the same animation viewer ID and
coordinate their activities within the same window. The meaning of probe labels
are user-defined, but the Simulation Kernel supports this feature with the KP
op_anim_lprobe_anvid(), which converts a label to an animation viewer ID. For
more information on the use of custom animation labels, refer to theAnimation
Package chapter of Simulation Kernel. For more information on the label
attribute refer to theProbe Reference chapter of Modeling Reference.

Statistic Animation Probes

Statistic animation provides the capability to dynamically view output vector

statistics as they evolve over the course of a simulation. The graph that is presented
in a statistic animation appears in an “analysis panel” that is similar to the one
displayed in the Analysis Tool. However, it adjusts dynamically by rescaling and
scrolling in order to accommodate the changing bounds of the output vector as
updated values are received from the simulation. Each statistic animation probe
uses the “scrolling” attribute to specify if a fixed-width time window of the statistic
should be displayed, or if instead, the entire history of the vector should be shown
by continually expanding the time axis as time progresses.

Statistic animation probes can only work in association with other statistic
probes. In other words, a statistic animation can only be provided for a statistic that
is already probed via a node, link, or global statistic probe. The statistic animation
probe uses its statistic attribute to establish an association with a statistic probe.
The value of this attribute must match the full hierarchical name of the statistic as
specified in the statistic probe (see example below), or the ordinate label of the
statistic probe, if one has been specified. Options of the corresponding statistic
probe, such as start and stop times, and capture mode, automatically apply to the
statistic animation probe. The final graph that is obtained at the end of a statistic
animation is therefore identical to the output vector that results from the statistic
probe.

494-Simde
Modeling Concepts Simulation Construction

Association of Statistic and Statistic-Animation Probes

The “statistic” attribute of the sta-

tistic animation probe associates it
with a statistic probe, from which it
“borrows” specifications for output

Simulation Design
vector options

Note: The window name attribute must have a unique value for each anima-
tion probe. You cannot view multiple animations in a single window.

Simde.3 Simulation Construction

OPNET simulations are obtained by executing a simulation program, which is

an executable file in the host computer’s file system. This section discusses the
constituent elements of a simulation program, and how they are assembled to
actually obtain the final program.

Simde.3.1 Simulation Components

A simulation program is a compiled program and takes the form of “object

code”. Object code consists of machine instructions that the host computer is
capable of executing directly, without any further translation. Each OPNET
simulation consists of many separate pieces of object code that are packaged
together in order to form a complete program. The different pieces of object code
play a variety of different roles in the simulation, as described in the following
table. Some of the object files are OPNET-provided, whereas others result from
user-specifications.

495-Simde
Simulation Construction Modeling Concepts

Types of Object Files Included in a Simulation Program

Object File Type Simulation Program

Simulation Kernel Provides the framework for all simulations including basic services
such as model loading, event scheduling and delivery, statistic col-
lection, memory allocations, etc. The Simulation Kernel contains all
Kernel Procedures (KPs) that are called by user-developed models.

Process Models Each process model that is included in a simulation is compiled into
a C language file with suffix “.pr.c”; this file is then compiled with the
host computer’s C compiler to generate an object file with suffix
“.pr.o”.

Pipeline Stages Relied on by link models to implement modular computations and

make decisions relating to the transfer of packets between transmit-
ters and receivers. Each pipeline stage is a C language procedure
within a single C file with suffix “.ps.c”. It is compiled using the host
computer’s C compiler into an object file with suffix “.ps.o”.

External Object Contain functions that play a supporting role for the process models
Files and pipeline stages in a simulation. This software may be devel-
oped in C or in other languages that are callable from C. They can
be compiled independently of OPNET and must have the suffix
“.ex.o”. External files can be made known to OPNET in two ways:
1) a process model’s dependency on an external file can be
expressed by declaring the external file in that model’s specifica-
tion; 2) a network model can express the dependency of any of its
included models on an external file, via a similar declaration.

External Archives Similar to external object files, but are packaged in the form of an
archive containing multiple object files. This is sometimes a more
convenient way of managing groups of object files that belong
together as part of a “package”.

Simde.3.2 Simulation Assembly

Given all of the simulation components referred to in the table above, opnet
provides the modeler with an executable program. This requires assembling the
components by ensuring that all references between them are satisfied and by
actually establishing “links” between references to data and code and the data and
code themselves. This operation is traditionally called linking the program; in
OPNET’s terminology, to avoid confusion with the term “link” which is commonly
used to describe objects in the network model, we use the term bind instead.

Binding Approaches

OPNET supports two approaches to binding simulation programs: static and

dynamic. These options correspond directly to the alternatives supported by the
compiler and linker of the host computer. In static binding, all of the references
between component files are resolved in advance and the entire group of files is

496-Simde
Modeling Concepts Simulation Construction

packaged together into a single large file which is the simulation program. The
program is ready to run at any time with no further assembly work to be done.
Dynamic binding uses a more sophisticated and complex process to assemble the
simulation at the time it is executed. Each approach offers its own advantages and
disadvantages, as summarized in the table below. Refer to the documentation
provided for your host computer’s compiler and linker for more information on
issues related to the underlying static and dynamic linking mechanisms.

Simulation Design
Static vs. Dynamic Binding of Simulation Programs
Issue Details Advantage

Portability Because a dynamically bound simulation is a loose Static

collection of object files, there is no guarantee that all
of the files can be located at the time of simulation exe-
cution. This particularly represents a concern when
transferring simulations to another computing environ-
ment (e.g., shipping simulations to another user) since
the inclusion of all relevant files must be ensured. Stat-
ically bound simulations experience this problem to a
lesser degree, but still require the presence of certain
model files in order to execute.

Binary Size Ultimately, once loaded into memory, dynamic simula- Dynamic
tions must include all of the object files that static simu-
lations include. However, they offer a significant
advantage in terms of disk storage space. This is due
to the fact that each static simulation incorporates
object files that are also in other simulation programs.
In particular the Simulation Kernel, which is a large file
is redundantly included by static simulations. In con-
trast dynamic simulations include object files by refer-
ence, meaning that each object file can be stored on
disk just once.

497-Simde
Simulation Construction Modeling Concepts

Static vs. Dynamic Binding of Simulation Programs (Cont.)

Issue Details Advantage

Automation As component object files change (e.g., due to revi- Dynamic

and sions to process models), dynamic simulations can
Adaptability automatically detect the changes and incorporate the
new files into the simulation program so that it is “up to
date” when executed. Users can simply save models
and run simulations without having to consider the
necessity of binding again. In contrast, statically bound
simulation programs must be discarded and bound
again from scratch if any of their components is no
longer up to date. In addition, because the simulation
program is entirely self contained, it can accidentally
be run without being re-built, and therefore without
reflecting the new information embodied within the
altered object files.

Permanence The advantage of adaptability presents a simultaneous Static

disadvantage for Dynamic simulations. The automatic
incorporation of new object files may be undesirable if
the behavior of an existing simulation needs to be pre-
served. For the same underlying reason, if several
“versions” of an object file are present in different direc-
tories, there may be some confusion on the part of the
user concerning which particular files are being loaded
into the simulation program. Static simulation programs
contain the object files within them and are therefore
impervious to future changes to the individual object
files

The advantages and disadvantages of the two approaches should be carefully

considered based on the requirements of the simulation project. OPNET’s default
approach is to use dynamic binding because the advantages of smaller binary sizes
and automation are so significant in most applications. The advantage of
automation is particularly important when component models are undergoing
frequent change, as is typically the case during the development phase of a
simulation project. Using dynamic binding, users can simply “save and run” their
models, without having to consider the necessity of a manual binding step. It is
important to realize that the binding approach can be changed at any time. So, for
example, it is possible to use dynamic binding during the entire development
phase, and then statically bind a simulation program in order to send it to a
customer.

OPNET’s bias toward dynamic binding is apparent in the fact that its graphical
user interface offers no support for static binding of simulations. In order to
statically bind a simulation, the op_mksim utility must be used. Refer to the
Program Descriptions chapter of External Interfaces for more information on
op_mksim.

498-Simde
Modeling Concepts Simulation Construction

Dynamic binding of simulations is implicitly supported by OPNET’s

Simulation Tool in the sense that execution of a simulation can automatically
trigger the binding process. The underlying utility that automates this process is
called op_runsim. This utility can be used to execute simulations from the host
computer’s “command line”, and OPNET’s Simulation Tool can use it to execute
simulations as well. op_runsim is essentially the “starting point” for all
dynamically bound simulation programs. Its role is to analyze a network model
and determine which component files are needed for the simulation; it then uses
the host computer’s linker in order to load all of the components and bind them
together. Finally, it begins executing the simulation. A later section of this chapter

Simulation Design
discusses the functions of op_runsim in more detail. Refer to the Program
Descriptions chapter of External Interfaces for more information on op_runsim.

Repositories

One advantage offered by statically bound simulations over dynamically bound

simulations is the fact that static simulations are ready to execute as is, whereas
dynamic simulations must still carry out a certain amount of “work” in order to
reach the point where they are ready to execute. This work consists of loading
object files and binding. Thus, dynamic simulations may take slightly longer than
static simulations to actually begin executing. In order to accelerate the dynamic
binding process, op_runsim can preserve some of the work that it performs on an
initial execution of a simulation. The work that is saved is the binding of the user-
defined components (process models, pipeline stages, etc.) into a single larger
object called a repository. From the linker’s point of view, a repository is
implemented as a shared object file. OPNET uses the “.nt.so” suffix for
repository files.

A repository can be maintained for each separate network model that is used
for simulation. When op_runsim is invoked to execute a simulation, it examines
the network model’s repository to determine if it is still up to date. It is considered
to be up to date if its last modification date is more recent than the modification
date of each of the source files that correspond to the repository’s object modules.
For example, for each process model included in the simulation, op_runsim
checks the repository date against the date of the process models’ portable
“.pr.m” file. If so, it can use it to save some portion of the time required to bind
the simulation. If not, it reconstructs the repository from scratch and leaves it in
place for future executions. Note that this approach partially negates the smaller-
size advantage that dynamic simulations have, since a repository file introduces
some redundant storage of object files. However, repositories are still significantly
smaller than statically-bound simulations because they do not include the
Simulation Kernel.

Note: Repositories are essentially interim files that are used for the binding
process. They can be deleted without losing model specification information.

499-Simde
Executing Simulations Modeling Concepts

Simde.4 Executing Simulations

Simulation execution is the final step in an “iteration” of a modeling

experiment. In general, based on the results observed during this step, changes are
made to the model’s specification or to the probes, and additional simulations are
executed. OPNET provides a number of options for running simulations, including
internal and external execution, and the ability to configure attributes that affect the
simulation’s behavior. This section introduces concepts, techniques, and features
that support simulation execution.

Simde.4.1 Simulation Input Control

Once a simulation model has been constructed, it is typically exercised under a

number of different conditions in order to characterize the system it represents.
While the model itself remains the same, aspects of its environment, or parameters
that it offers are varied in order to establish patterns of behavior or relationships
between certain inputs of the system and selected outputs. The inputs and outputs
vary with each system that is modeled and depend on the goals of the simulation
study. This section discusses how a model’s inputs can be controlled when running
simulations.

Simde.4.1.1 Stochastic Modeling

Many simulations rely on stochastic modeling of certain elements in order to

represent behavior that is not known in a precise fashion but that can be
characterized by associating probabilities with a set of outcomes. Some common
applications requiring this technique are as follows:

• Traffic loads of communication networks usually result from the aggre-

gation of many individual sources. These individual sources usually
correspond to users whose traffic submissions are not precisely predict-
able. In addition, these sources are generally not coordinated with each
other, leading to a traffic flow that appears random. Other user-deter-
mined properties of network traffic, such as selection of destinations
and service-quality parameters, are also often modeled in a stochastic
manner in order to reflect the variability of user choices.

• Certain computer operations require variable execution times to com-

plete. Some correspond to the use of physical devices with delays that
may change, such as disks or tape drives. In other cases, contention for
computer resources such as the bus, CPU, or memory may present a
particular task with variable delays in accessing these resources. These
delays may be modeled by explicitly representing all the tasks that con-
tend for the resources, or the presence of other tasks may be modeled in
a more abstract fashion by incorporating variable delays into operations
that access the resources of interest.

• The definition of certain communication protocols requires them to

perform operations on a random or pseudo-random basis. Common

500-Simde
Modeling Concepts Executing Simulations

examples include selecting random timer values for message retrans-

missions, and randomly selecting an order in which to service multiple
contending traffic sources.

• The quantity and placement of bit-errors affecting transmitted packets

are usually modeled as random processes. In fact, link quality is typi-
cally characterized in statistical terms by manufacturers or service pro-
viders, providing a straightforward mapping into a stochastically
parameterized OPNET model.

Simulation Design
Creating Variable Behavior

Stochastically modeled elements depend on a random number source on which

to base their behavior. By “drawing” from the source, these elements can
incorporate variability into appropriate actions or decisions as they are taken.

As mentioned earlier, it is impossible for a computer program, by its very

nature, to exhibit genuinely unpredictable behavior. If a simulation program
remains the same for multiple simulation runs, then any change in its behavior
must come from a change in its operating environment (i.e., its input). In
particular, even the random number stream used to implement stochastic behavior,
must be forced into a different mode in order to yield different results from
simulation to simulation.

The mechanism used to select new random number sequences relies on starting
the random number generator in a different state. Because it determines all future
output of the random number generator, this initial state is known as the random
number seed. For OPNET simulations the random number seed can be set with the
integer environment attribute seed; in addition, it may be designated from within
the Simulation Tool, on a per-simulation basis.

For a simulation that incorporates stochastic elements, each distinct random

number seed value will produce different behavior and yield new results. Each
particular simulation can then be thought of as representing one possible scenario
of events for the modeled system. However, no single simulation can necessarily
be used as an accurate gauge of “typical” system behavior, since it is conceivable
that even atypical behaviors, provided they are possible, may be achieved for some
random number seed. Therefore, a technique that is frequently used is to exercise
the simulation model multiple times while varying the random number sequence.
The results obtained from the separate simulations can be combined (usually
simply by averaging) to estimate typical behavior.

Random Number Generation

OPNET uses a random number generator in the following circumstances:

• Pipeline stages use random numbers to allocate bit errors to packets.

501-Simde
Executing Simulations Modeling Concepts

• The KPs op_dist_uniform() and op_dist_outcome(), used by many pro-

cess models, return results that are dependent on a random number se-
quence.

In both cases, random numbers are drawn from a single random number
sequence initialized with the value of the seed environment attribute. The random
number generator used to create this sequence is provided by the host computer’s
operating system and may vary on certain platforms. The following table
summarizes the random number generation sources used on each operating system
supported by OPNET. Contact OPNET Technologies for information on operating
systems other than those listed in this table.

Random Number Generators for

Supported Operating Systems
Operating System Random Number Generator

Sun Solaris random ()

Microsoft Windows random ()

(ported from UNIX BSD source distribution)

HP HP-UX random()

For models that require complete independence of random number sequences

used by different stochastic elements, processes and pipeline stages may make
independent calls to the host computer’s random number facility or other,
proprietary random number generators. The Dist package of the Simulation Kernel
provides a special KP, op_dist_outcome_ext(), which supports use of probability
distributions with proprietary random number generators. Refer to the Distribution
Package chapter of Simulation Kernel for more information on this KP.

Simde.4.1.2 Simulation Parameterization

In addition to varying random number seeds to obtain a range of stochastic

behaviors, many simulation studies also vary certain properties, or operating
conditions of the model. In this manner, the modeled system can be characterized
for a range of possible configurations in order to support trade-off analysis and
determine the system’s limitations and peak performance conditions.

The primary mechanism used to vary model configuration is based on the use
of promoted object attributes. Promoted attribute values can be altered at each
simulation, without modification of the simulation models or simulation program.
Promoted attributes are attributes of objects whose values have been left
unassigned, precisely so that these assignments could instead be completed at the
time of simulation execution. In other words, promoted attributes can be thought of
as simulation program parameters provided by the model designer. For more

502-Simde
Modeling Concepts Executing Simulations

information on attribute promotion, refer to the Modeling Framework chapter of

Modeling Concepts.

A second mechanism that supports variation of model configuration is based

on the use of variables that are not associated with any particular objects. These
variables are called simulation attributes and their values can be obtained by user-
defined logic via the KP op_ima_sim_attr_get(). Because simulation attributes have
no association with objects, they are well-suited to representing system-wide, or
global parameters. The interpretation and application of simulation attributes and
their values is left to the user-defined code; the Kernel merely provides an interface

Simulation Design
to facilitate this type of parameterization.
Both promoted attributes and simulation attributes are treated in the same
manner when a simulation’s parameters are specified. OPNET’s Simulation Tool
allows each simulation to complete a numerical attribute’s specification by
providing either a specific value, a range of values, or a set of discrete values. Non-
numerical attributes can only be assigned a specific value. When at least one
attribute is assigned a range or set of values, the user has implicitly specified
multiple simulation runs to be executed, each with a distinct value of the attribute.
When more than one attribute is assigned a range or set of values, then the
Simulation Tool executes a separate simulation for each combination of the
attribute values. Care should be taken not to launch an excessive number of
simulations in this manner. The following figure illustrates the specification of
simulation parameters in the Simulation Tool. For more information on using this
tool, refer to the Simulation Tool chapter of Editor Reference.

Attribute Value Specification in the Simulation Tool

“S1.Buffer Size” is a pro-

moted attribute of object
“S1”. It varies from 250 to
500 in increments of 50.

“S1.Processing Speed” is a “Congestion Control” is a sim-

promoted attribute of object S1 ulation attribute, unassociated
and takes on 3 distinct values. with any particular object

Note: When executing simulations outside the Simulation Tool, attributes can
be assigned via the full range of environment attribute mechanisms provided
for all OPNET programs and described in the System Environment chapter of
the External Interfaces manual . These mechanisms include assignment via the

503-Simde
Executing Simulations Modeling Concepts

command line, as well as use of one or more environment files, and the environ-
ment database (env_db) file.
Simde.4.2 Simulation Sequences

The main use of the promoted attribute and simulation attribute mechanisms
described above is for conducting studies where attributes are varied over a range
of values. For each new attribute configuration, a new simulation is executed, and
if stochastic behavior is involved in the model, multiple simulations may be run
with different random number seeds. Thus, the complete study is based on a
sequence of simulations.Each simulation in the sequence records simulation output
in vector, scalar, or animation form, for later analysis. In general, scalars are used
when sequences of simulations are executed because this is the form of output data
designed for parametric studies and that can be accumulated in a single output file
over the course of many simulations. However, it may be interesting to observe
dynamic behavior for certain simulations in the sequence by also storing vector
data.

Simulation sequences may of course be achieved by manually running

individual sequences, one at a time. However, in general, there can be many
simulations in the require sequence, and some automation of the process is
desirable. It is particularly useful to be able to run simulation sequences without
human intervention over long periods of time, such as over night, or over several
days.

There are two approaches to automating execution of simulation sequences.

The first is supported by OPNET’s Simulation Tool, which provides a graphical
user interface for configuring a sequence and running it. The second approach
relies on the fact that OPNET simulations are ordinary programs that can therefore
be executed under the control of other programs or scripts.

Simulation Tool Sequences

In the Simulation Tool, a sequence consists of one or more simulation objects.

Each object can represent one or more simulations for a particular network model.
Additional simulation objects can specify simulations for other network models, or
for the same, if needed. In general, because an object can represent more than one
simulation (due to attributes having multiple values or ranges), a simulation object
is also known as a simulation set. The simulation objects provide attributes that
configure various aspects of each simulation set. The primary attributes of the
simulation object are summarized in the following table:

504-Simde
Modeling Concepts Executing Simulations

Simulation Object Attributes

Attribute Description

Simulation Program Program to be executed. In general, this is op_runsim for

dynamically linked simulations. If a simulation program is stati-
cally linked, this is the name of the simulation (“.sim”) program
file.

Simulation Design
Network Model Name of the network model that will be simulated. The simula-
tion program loads the model to determine which objects are
present and how they are configured.

Probe File Name of an optional probe list which specifies which output
data should be collected during the simulation(s).

Vector File Name of the output vector (OV) file(s) that output vectors will
be directed to. OV files can later be loaded to create plots. For
simulation sets specifying more than one simulation, the “save
vector file for each run in set” option must be enabled in order
to specify an OV file name. This option causes a suffix to be
appended to the name in order to differentiate the OV files.

Scalar File Name of the output scalar (OS) file that all output scalars will
be directed to, for all simulations in the set. OS files can later
be loaded in the Analysis Tool to create plots. Note that output
scalar files accept cumulative data and therefore can be refer-
enced by multiple simulation objects without overwriting infor-
mation.

Duration The nominal duration of the simulation in simulated seconds.

Other events, such as the exhaustion of the event list, or a
specific request by user-defined code, may cause the simula-
tion to end earlier. However, the simulation cannot continue
beyond the time specified by this attribute.

Update Interval The interval of simulated seconds separating progress reports

issued by the simulation.

Seed The integer value of the random seed used to set the initial
state of the Simulation Kernel’s built-in random number gener-
ation.

Model Attributes Attributes promoted by the model, or provided as simulation

attributes. Each of these attributes’ values can be assigned a
specific value, a range of values, or a discrete set of values.

Animation Attributes Support the recording or “live” (simultaneous) playing of ani-

mation during the simulation. For live animation, parameters
related to communication with the animation utility can be
specified. For post-simulation animation, the animation history
file name is specified.

505-Simde
Executing Simulations Modeling Concepts

Simulation Object Attributes (Cont.)

Attribute Description

Environment Files A set of files that support specification of attributes for the sim-
ulation program. Primarily used for model attribute specifica-
tion, but other attributes can be specified in these files as well.
Environment files have the “.ef” suffix. Refer to the Envi-
ronment Attributes chapter in External Interfaces for details
on environment files.

Default Mode The “use default values for unresolved attributes” instructs
OPNET to automatically supply default values rather than
prompt the user when an attribute’s value has been left
unspecified. Default values for attributes are inherent in their
definition. Refer to the Modeling Framework chapter of
Modeling Concepts.

In typical simulation studies involving stochastic behavior, it is desirable to run

several differently-seeded simulations for each configuration of the model. As
explained above, changing the random number seed over several scenarios helps to
establish confidence in the results that are obtained. Since each simulation object
provides specification for only one seed value, such sequences require multiple
simulation objects. Each simulation object can still represent multiple simulations:
these correspond to the different configurations of the system independent of
random number generation. The following diagram illustrates such a simulation
sequence specification, and shows typical output scalar graphs that may result.

506-Simde
Modeling Concepts Executing Simulations

Use of Simulation Sequence to Generate

Output Scalars and Confidence Intervals

seed = 100 seed = 101 seed = 200 seed = 250

Simulation Design
Expansion of graph in the
region where “Processing
Speed” = 0.6,shows four
separate values of “Peak
Queue Size”, correspond-
ing to the four different
random seeds.

The same graph shown with

confidence intervals for the
means of the “Peak Queue
Size” values that are clustered
vertically. Here only, one point
is shown for each value of “Pro-
cessing Speed”; the queue size
value is the mean of each group
of points.

Scripted Sequences

Scripts or programs provide a convenient method of executing simulation

sequences when outside the Simulation Tool. A script provides a very general
environment for executing programs and commands and can be used to design
complex simulation drivers, possibly incorporating inputs from other programs.
However, for most simulation studies, scripts can be used in a very simple manner,
by executing a single simulation per line in the script, or by forming loops that vary

507-Simde
Executing Simulations Modeling Concepts

attribute values automatically. Examples appear below of each of these approaches

implemented in the UNIX C-shell environment. Refer to your host computer’s
documentation for more information on script programming.

Example Simulation Script with One Command per Simulation

#!/bin/csh

# script for executing fddi_net_32 model with range of values

# of TTRT parameter

op_runsim -net_name fddi_net_32 \

-ef fddi -TTRT 0.002 -ov_file fddi_0.0020 -os_file fddi
op_runsim -net_name fddi_net_32 \
-ef fddi -TTRT 0.003 -ov_file fddi_0.0030 -os_file fddi
op_runsim -net_name fddi_net_32 \
-ef fddi -TTRT 0.004 -ov_file fddi_0.0040 -os_file fddi
op_runsim -net_name fddi_net_32 \
-ef fddi -TTRT 0.005 -ov_file fddi_0.0050 -os_file fddi
op_runsim -net_name fddi_net_32 \
-ef fddi -TTRT 0.010 -ov_file fddi_0.010 -os_file fddi
op_runsim -net_name fddi_net_32 \
-ef fddi -TTRT 0.015 -ov_file fddi_0.015 -os_file fddi
op_runsim -net_name fddi_net_32 \
-ef fddi -TTRT 0.020 -ov_file fddi_0.020 -os_file fddi
op_runsim -net_name fddi_net_32 \
-ef fddi -TTRT 0.025 -ov_file fddi_0.025 -os_file fddi
op_runsim -net_name fddi_net_32 \
-ef fddi -TTRT 0.030 -ov_file fddi_0.030 -os_file fddi
op_runsim -net_name fddi_net_32 \
-ef fddi -TTRT 0.035 -ov_file fddi_0.035 -os_file fddi
op_runsim -net_name fddi_net_32 \
-ef fddi -TTRT 0.040 -ov_file fddi_0.040 -os_file fddi
op_runsim -net_name fddi_net_32 \
-ef fddi -TTRT 0.045 -ov_file fddi_0.045 -os_file fddi
op_runsim -net_name fddi_net_32 \
-ef fddi -TTRT 0.060 -ov_file fddi_0.060 -os_file fddi

508-Simde
Modeling Concepts Executing Simulations

Example Simulation Script using Loop and Attribute Value Table

#!/bin/csh

# script for executing fddi_net_32 model with range of values

# of TTRT parameter

# Loop through range of TTRT values

foreach TTRT (0.002 0.003 0.004 0.005 0.010 0.015 0.020 0.025 0.030 \
0.035 0.040 0.045 0.060)

Simulation Design
# Issue update statement indicating which sim. is about to happen
echo 'executing with TTRT = ' $TTRT

# Execute the sim.

op_runsim -net_name fddi_net_32 \
-ef fddi -TTRT $TTRT -ov_file fddi_$TTRT -os_file fddi

# end this iteration of the loop, begin next sim.

end

509-Simde
Executing Simulations Modeling Concepts

510-Simde