Chapter 7 – Simulation Design

475-Simde

Simulation Design

Chapter 7

476-Simde

Modeling Concepts

477-Simde

Modeling Concepts

IntroductionS

imu

lation

Desig

n

Simde.1 Introduction

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

Simde.2 Specifying Data Collection

At various stages during model development, OPNET users may wish toconduct simulations in order to test correct operation of the model. When themodel has attained a complete form, simulations are run to actually study thesystem’s behavior and performance. However, before beginning simulations, theuser must consider what information is to be obtained. In certain cases mayOPNET may require some additional specifications in order to cause thatinformation to be generated. In this section, we will discuss what types of outputscan be offered by an OPNET simulation, and the mechanisms that are available toextract them.

Simde.2.1 Phases of Data Collection

Models of complex systems typically evolve through stages of increasingcomplexity. As the model developer progresses, new features are added to themodel until it converges on the desired level of realism. In the earlier stages, modeldevelopers typically run simulations for the purpose of verifying the specificationsthey have completed so far. In general, verification involves checking that some orall of the following criteria are met:

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.

478-Simde

Specifying Data Collection

Modeling Concepts

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

As a modeling project reaches later stages, model developers begin to focus onextracting information from the simulation that is specifically related to the goalsof 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 thefollowing table.

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.

479-Simde

Modeling Concepts

Specifying Data CollectionS

imu

lation

Desig

n

Simde.2.2 Classes of Simulation Output

OPNET simulations can generate a variety of types of output which areapplicable in different situations. Given that OPNET simulations can contain user-defined code, it is clearly also possible to define and compute new types ofsimulation output which can be reported during simulations or afterwards for post-processing. This section enumerates common forms of simulation output andindicates the type of support that OPNET provides for generating it.

Automaticsupport

means that OPNET computes and records the information with noprogramming required by the modeler.

Programmatic support

means that OPNETprovides programmatic interfaces that allow the modeler to record customizedoutput. Finally,

unsupported

means that the output the modeler can use the generalmechanisms of the programming language and the Operating System to generatethe output, but OPNET provides no specific implementation support.

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 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.

480-Simde


Modeling Concepts

Forms of Simulation Output

Form of Output Details Support

Output Vectors The history of a system vari-able can be captured as it var-ies over time in the form of an

output vector

. (OV) OVs pro-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.

Automatic for built-in statistics pro-vided by OPNET; programmatic for customized statistics computed by user-defined code.

Output Scalars Certain metrics of interest do not vary with time. Instead, they are a single value that is representative of the system’s 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.

Automatic for built-in statistics pro-vided by OPNET; programmatic for customized statistics computed by user-defined code.

481-Simde

Modeling Concepts


imu

lation

Desig

n

Output Files

As mentioned above, simulation results can take on several different formsincluding visual animations, time-dependent series of values, and parametricrelationships. For those forms of output that are not interactively utilized (i.e., asthe simulation continues to run), results are accumulated in files residing in thehost computer’s filesystem, until a simulation completes. These contents of thesefiles may be displayed at the user’s convenience using appropriate tools. There arethree types of output files that may be directly generated by the Simulation Kernel.

Animation Visualization of system activity can be a valuable tool for gain-ing insight into behavior and interactions between compo-nents. Simulations can gener-ate animations as they run or save them for playback after they complete.

Automatic for standard forms of animation provided by OPNET; programmatic for customized graphics computed by user-defined code.

Proprietary Reports and Files

Since OPNET allows inclusion of user-defined processes and 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.

Unsupported by OPNET; relies on C language and OS access.

Forms of Simulation Output

Form of Output Details Support

482-Simde


Modeling Concepts

opnet

also maintains a log of errors and significant events that occurred duringa simulation. This log (a tab-delimited ASCII file) may be examined using thesimulation log browser. For details, refer to the

Project Editor

chapter in

EditorReference

.

Simde.2.3 Statistic Collection Mechanisms

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

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.

483-Simde

Modeling Concepts


imu

lation

Desig

n

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

Simde.2.3.1 Probes

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

The purpose of a probe is to act as an enabler of output data that couldpotentially be stored in the simulation’s output files. Each source of data that is notexplicitly probed is essentially “shut off”. OPNET takes the approach that outputsources are off by default because the number of sources virtually always vastlyoutnumbers the number of sources of interest.

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

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

484-Simde


Modeling Concepts

Each probe is an object with a set of attributes that specify which output sourceit applies to, as well as various options concerning how to collect the data. Theattributes vary for each type of probe. For details on the use of each attribute, referto the

Probe Reference

chapter of

Modeling Reference

.

Simde.2.3.1.1 Statistic Probes

OPNET supports local and global statistics. Local statistics are associated withparticular 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, butthey are promoted to the node level by the node model specification (refer to the

Node Domain

chapter of

Modeling Concepts

for more information on statisticpromotion). This mechanism allows users of node models (such as ITDecisionGuru users) to access these statistics without having internal knowledgeof the node model’s components. Node and module statistics are supported by the

node statistic probe object

, which provides attributes for specifying the physicalobject being probed, down to the submodule level if necessary. Node statisticprobes support both built-in statistics of objects, as well as the user-definedstatistics that are declared by process models.

Link statistic probes

provide accessto 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 byOPNET for each object, refer to the

Node Reference

and

Network Reference

chapters of

Modeling Concepts

.

Supported Probe Types

Probe Type Applications Varieties

Statistic Collect data of a numerical form generated either by built-in object statistics, or by user-defined local and global statistics. Can gener-ate both output vectors and out-put scalars.

NodeCoupled NodeLinkGlobal

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-mands to be issued by the simula-tion. Animations describe various aspects of system behavior. They can apply to particular objects, models, and statistics, or can be completely customized.

AutomaticCustomStatistic

485-Simde

Modeling Concepts


imu

lation

Desig

n

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

Coupled node statistic probes record information relating to a particularobject’s activity with respect to its interaction with another object. Only a smallnumber of statistics in OPNET support coupled probing. Currently, these are allstatistics of the radio receiver channel object. The coupling mechanism allows theprobe to focus only on the performance of a link between the receiver channel anda particular transmitter elsewhere in the model. For example, a coupled nodestatistic probe allows the

received power

statistic of a receiver channel tomeasure only the power of the signal incident upon the receiver from a specifictransmitter. The same statistics can be collected using an ordinary node statisticprobe, 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.

Objects that Generate Statistics

Processors Application-specific (defined by developer)

Queues andSubqueues

Application-specific (defined by developer), and statis-tics related to queue size, available queue space, over-flow occurrences, queuing delays, etc.

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

Transmitterchannels

Throughput, utilization, queue size

Receiver channels

Throughput, utilization, collisions, error rates,radio statistics (radio receivers only)

Links Throughput, utilization, error rates; collisions

Radio Receiver ChannelCoupled Statistics

signal-to-noise ratio

bit error rate

packet error rate

486-Simde


Modeling Concepts

All statistic probes offer a set of common options that are specified via theirattributes. Each probe can act as the source of both output vector and output scalarstatistics, as specified by their

vector data

and

scalar data

toggle attributes.Both may be simultaneously enabled. If

vector data

is enabled, all of the valuesof the statistic are collected in an output vector in the simulation’s output file. Thevector’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. Thisis 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.

If a statistic probe’s

scalar data

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

bit errors per packet

received power

Radio Receiver ChannelCoupled Statistics (Cont.)

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.

487-Simde

Modeling Concepts


imu

lation

Desig

n

specified using the

scalar start

and

scalar stop

attributes of the probe. Thesupported metrics are specified using the

scalar type

attribute and aresummarized in the following table:

In certain cases, statistics experience such frequent change during a simulationthat collecting all of their values in output vector form becomes problematic.Specifically, one or more vectors may require a prohibitive amount of disk storageto be collected in their entirety. In addition, the frequent saving of the statistic mayreduce the performance of the simulation, even though OPNET uses mechanismsto minimize this effect. In such cases, it may be desirable to reduce the size of thedata that is being collected, even at the cost of a certain amount of accuracy orcompleteness. One mechanism that can be used is to limit the window of time overwhich collection is performed, as was described earlier in this section. Anotherapproach, which can be applied separately or combined with windowing, is toreduce the values of the statistic at a specified rate in order to generate a less denseoutput vector. Statistic probes support “on-the-fly” processing of statistics, andparticularly reduction of statistics, via their

capture mode

attribute. A probe’scapture mode specifies a method by which a statistic’s values can be modified asthey 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 aresupported, as described 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 (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

488-Simde


Modeling Concepts

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

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.

Normal mode data includes all up-dates of the queue size, showing detailed changes over time.

Bucket mode data is a time average of up-dates every 25 seconds. It is much sparser, but captures the general trends over time.

Comparison of Normal Mode and Bucket Mode with Time-Average Option

489-Simde

Modeling Concepts


imu

lation

Desig

n

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

Simde.2.3.1.2 Attribute Probes

Attributes specify characteristics of objects. Since they are part of thespecification of a model, they can be viewed as “inputs” to the simulation. This isparticularly clear when an attribute is promoted past the network level of the modeland requires an assignment to be provided at the time of simulation execution. It isuseful to introduce certain simulation inputs into the output files in order tofacilitate studying the dependencies that exist between simulation outputs andinputs. For example, we may wish to analyze how the throughput of a networkvaries as a function of the traffic load that is submitted. Or, we may be interested inthe end-to-end delay of traffic as a function of the speed of the network’stransmission lines. In these cases, traffic load and transmission line speed aremodel inputs that we would vary over a series of simulation experiments. In eachexperiment we would record these inputs as well as the throughput and end-to-enddelay. By recording the input and output quantities together we can establish therelationship that exists between them.

The maximum size option of the bucket mode provides a sparse vector that is an upper-bound “envelope” for the actual queue size.

Comparison of Normal Mode and Bucket Mode with Maximum Value Option

490-Simde


Modeling Concepts

Since user-defined code can access the values of attributes and has the ability toalso write values into the simulation output files, it is of course possible for processmodels to save attribute values in the simulation output files. Process models canalso perform computations that combine or otherwise process the values ofmultiple attributes. However, in cases where the values of numerical attributes areof interest without further processing, special probes called

attribute probes

can beused. Numerical attributes include the

integer

,

double

,

toggle

, and

toggle

double data types. Each attribute probe applies to one object or simulation attributeand generates a corresponding scalar value in the output scalar file. The attributeprobe has an attribute called

object

that allows it to refer to any object at thenetwork or node level in the model. If a simulation attribute is declared by any ofthe process models in the system, an attribute probe can refer to it simply byleaving the

object

attribute blank. The following graph shows an example of aplot 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.

491-Simde

Modeling Concepts


imu

lation

Desig

n

Simde.2.3.1.3 Animation Probes

OPNET provides a mechanism called an

animation probe

which is used toenable 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 typicalsimulation, while only a small part of it may actually be of interest. By specificallyindicating which aspects or physical parts of a model should be animated, the flowof resulting information can be kept manageable.

Three types of animation probe objects, called automatic animation probes,custom animation probes, and statistic animation probes, may be placed in asimulation’s probe file to enable generation of animation data. Multiple probes ofeach type may coexist within the same probe file. Automatic animation probes andstatistic animation probes both enable built-in animation capabilities of OPNETmodels. They provide the simplest means of obtaining animations with an OPNETsimulation, since no additional specifications are required within the model.Custom animation probes act as an enabling device for animation requests that aregenerated by user-defined processes. Custom animations provide flexibility torepresent general information during an animation, but require programmaticspecification by the model developer.

Automatic Animation Probes

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

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

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

492-Simde

Specifying Data Collection Modeling Concepts

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

Custom Animation Probes

If automatic animations do not provide all of the functionality required by themodel developer, OPNET allows the developer to create customized animationsthat are better-suited to, or more complete for particular applications. Customizedanimations are implemented using the Anim package Kernel Procedures (KPs) thatcalled from process models or pipeline stages. These procedures provide generaldrawing and animation capabilities as well as functions related specifically todisplaying OPNET models. Refer to the Animation Package chapter of SimulationKernel for complete specifications.

Because animation can significantly degrade simulation performance, it isimportant to be able to selectively enable its generation. In particular, during longsimulation runs, or sequences of simulation runs, animation is usually disabledentirely. Since custom animation is generated by user-developed logic, it ispossible for developers to incorporate their own animation control mechanisms. Ingeneral, such a mechanism could be based on the use of object or environmentattributes, queried using the KPs of the Ima package. Based on the values of theseattributes, 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 customanimation 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, acustom animation probe serves as an enabling agent for the animation directivesthat are executed within the context of the probed object. In other words, bydefault, calls to animation-related Kernel Procedures are ignored, unless anappropriate custom animation probe is defined to enable their actions.

The context of a custom animation probe, or the scope of animation directivesthat 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 modellogic, or transceiver pipeline stage logic, since these are the interfaces supportingthe integration of user-developed code. For a processor or queue to be the subjectof a custom animation probe implies that animation directives executed by any ofthe processes contained within it can make use of the probe. This extends to theprocedures 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 atransceiver (either point-to-point, bus, or radio) is the subject of a customanimation probe, then animation directives issued from within associated pipelinestages, including indirectly called procedures, are affected by the probe. Thefollowing table summarizes the scope of custom animation probes for eachsupported object type:

493-Simde

Modeling Concepts Specifying Data CollectionS

imu

lation

Desig

n

In the case of transceiver pipeline stages, there is a well-defined associationwith either the transmitter that acts as the source, or the receiver that acts as thedestination during a pipeline execution. The following table summarizes thisassociation for the purposes of determining where to place animation probes. Notethat the radio pipeline stage “receiver group” is missing from the table because it isnot associated with any particular transceiver; thus, any animation directivesexecuted within this stage are ignored.

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

Scope of Custom Animation Probes

Type ofProbed Object

Enabled Sources ofAnimation 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.

Node (fixed, mobile, or satellite)

All processes executing within any processor or 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.

Transceiver Associations for Pipeline Stages

Pipeline Type Transmitter-Associated Stages

Receiver- Associated Stages

Point-to-Point transmission delay,propagation delay

error allocation,error correction

Bus transmission delay,closure,propagation delay

collision,error allocation,error correction

Radio transmission delay,closure,channel match,transmitter antenna gain,propagation delay

receiver antenna gain,received power,background noise,interference noise,signal-to-noise ratio,bit-error-rateerror allocationerror correction

494-Simde

Specifying Data Collection Modeling Concepts

addition, an attribute called label can be used to specialize the applicability of theprobe. 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 thatprobe. The code can then enable appropriate animation requests and direct them tothe required windows. The label also serves as a rendezvous mechanism, allowingdifferent processes and pipeline stages to obtain the same animation viewer ID andcoordinate their activities within the same window. The meaning of probe labelsare user-defined, but the Simulation Kernel supports this feature with the KPop_anim_lprobe_anvid(), which converts a label to an animation viewer ID. Formore information on the use of custom animation labels, refer to theAnimationPackage chapter of Simulation Kernel. For more information on the labelattribute refer to theProbe Reference chapter of Modeling Reference.

Statistic Animation Probes

Statistic animation provides the capability to dynamically view output vectorstatistics as they evolve over the course of a simulation. The graph that is presentedin a statistic animation appears in an “analysis panel” that is similar to the onedisplayed in the Analysis Tool. However, it adjusts dynamically by rescaling andscrolling in order to accommodate the changing bounds of the output vector asupdated values are received from the simulation. Each statistic animation probeuses the “scrolling” attribute to specify if a fixed-width time window of the statisticshould be displayed, or if instead, the entire history of the vector should be shownby continually expanding the time axis as time progresses.

Statistic animation probes can only work in association with other statisticprobes. In other words, a statistic animation can only be provided for a statistic thatis already probed via a node, link, or global statistic probe. The statistic animationprobe 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 asspecified in the statistic probe (see example below), or the ordinate label of thestatistic probe, if one has been specified. Options of the corresponding statisticprobe, such as start and stop times, and capture mode, automatically apply to thestatistic animation probe. The final graph that is obtained at the end of a statisticanimation is therefore identical to the output vector that results from the statisticprobe.

495-Simde

Modeling Concepts Simulation ConstructionS

imu

lation

Desig

n

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 isan executable file in the host computer’s file system. This section discusses theconstituent elements of a simulation program, and how they are assembled toactually obtain the final program.

Simde.3.1 Simulation Components

A simulation program is a compiled program and takes the form of “objectcode”. Object code consists of machine instructions that the host computer iscapable of executing directly, without any further translation. Each OPNETsimulation consists of many separate pieces of object code that are packagedtogether in order to form a complete program. The different pieces of object codeplay a variety of different roles in the simulation, as described in the followingtable. Some of the object files are OPNET-provided, whereas others result fromuser-specifications.

The “statistic” attribute of the sta-tistic animation probe associates it with a statistic probe, from which it “borrows” specifications for output vector options

Association of Statistic and Statistic-Animation Probes

496-Simde

Simulation Construction Modeling Concepts

Simde.3.2 Simulation Assembly

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

Binding Approaches

OPNET supports two approaches to binding simulation programs: static anddynamic. These options correspond directly to the alternatives supported by thecompiler and linker of the host computer. In static binding, all of the referencesbetween component files are resolved in advance and the entire group of files is

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 Files

Contain functions that play a supporting role for the process models 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”.

497-Simde


imu

lation

Desig

n

packaged together into a single large file which is the simulation program. Theprogram 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 thesimulation at the time it is executed. Each approach offers its own advantages anddisadvantages, as summarized in the table below. Refer to the documentationprovided for your host computer’s compiler and linker for more information onissues related to the underlying static and dynamic linking mechanisms.

Static vs. Dynamic Binding of Simulation Programs

Issue Details Advantage

Portability Because a dynamically bound simulation is a loose 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.

Static

Binary Size Ultimately, once loaded into memory, dynamic simula-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.

Dynamic

498-Simde

Simulation Construction Modeling Concepts

The advantages and disadvantages of the two approaches should be carefullyconsidered based on the requirements of the simulation project. OPNET’s defaultapproach is to use dynamic binding because the advantages of smaller binary sizesand automation are so significant in most applications. The advantage ofautomation is particularly important when component models are undergoingfrequent change, as is typically the case during the development phase of asimulation project. Using dynamic binding, users can simply “save and run” theirmodels, without having to consider the necessity of a manual binding step. It isimportant to realize that the binding approach can be changed at any time. So, forexample, it is possible to use dynamic binding during the entire developmentphase, and then statically bind a simulation program in order to send it to acustomer.

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

Automation andAdaptability

As component object files change (e.g., due to revi-sions to process models), dynamic simulations can 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.

Dynamic

Permanence The advantage of adaptability presents a simultaneous 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

Static

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

Issue Details Advantage

499-Simde


imu

lation

Desig

n

Dynamic binding of simulations is implicitly supported by OPNET’sSimulation Tool in the sense that execution of a simulation can automaticallytrigger the binding process. The underlying utility that automates this process iscalled op_runsim. This utility can be used to execute simulations from the hostcomputer’s “command line”, and OPNET’s Simulation Tool can use it to executesimulations as well. op_runsim is essentially the “starting point” for alldynamically bound simulation programs. Its role is to analyze a network modeland determine which component files are needed for the simulation; it then usesthe host computer’s linker in order to load all of the components and bind themtogether. Finally, it begins executing the simulation. A later section of this chapterdiscusses the functions of op_runsim in more detail. Refer to the ProgramDescriptions chapter of External Interfaces for more information on op_runsim.

Repositories

One advantage offered by statically bound simulations over dynamically boundsimulations is the fact that static simulations are ready to execute as is, whereasdynamic simulations must still carry out a certain amount of “work” in order toreach the point where they are ready to execute. This work consists of loadingobject files and binding. Thus, dynamic simulations may take slightly longer thanstatic simulations to actually begin executing. In order to accelerate the dynamicbinding process, op_runsim can preserve some of the work that it performs on aninitial 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 largerobject called a repository. From the linker’s point of view, a repository isimplemented as a shared object file. OPNET uses the “.nt.so” suffix forrepository files.

A repository can be maintained for each separate network model that is usedfor simulation. When op_runsim is invoked to execute a simulation, it examinesthe network model’s repository to determine if it is still up to date. It is consideredto be up to date if its last modification date is more recent than the modificationdate 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_runsimchecks 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 bindthe simulation. If not, it reconstructs the repository from scratch and leaves it inplace for future executions. Note that this approach partially negates the smaller-size advantage that dynamic simulations have, since a repository file introducessome redundant storage of object files. However, repositories are still significantlysmaller than statically-bound simulations because they do not include theSimulation Kernel.

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

500-Simde

Executing Simulations Modeling Concepts

Simde.4 Executing Simulations

Simulation execution is the final step in an “iteration” of a modelingexperiment. In general, based on the results observed during this step, changes aremade to the model’s specification or to the probes, and additional simulations areexecuted. OPNET provides a number of options for running simulations, includinginternal and external execution, and the ability to configure attributes that affect thesimulation’s behavior. This section introduces concepts, techniques, and featuresthat support simulation execution.

Simde.4.1 Simulation Input Control

Once a simulation model has been constructed, it is typically exercised under anumber of different conditions in order to characterize the system it represents.While the model itself remains the same, aspects of its environment, or parametersthat it offers are varied in order to establish patterns of behavior or relationshipsbetween certain inputs of the system and selected outputs. The inputs and outputsvary with each system that is modeled and depend on the goals of the simulationstudy. This section discusses how a model’s inputs can be controlled when runningsimulations.

Simde.4.1.1 Stochastic Modeling

Many simulations rely on stochastic modeling of certain elements in order torepresent behavior that is not known in a precise fashion but that can becharacterized by associating probabilities with a set of outcomes. Some commonapplications requiring this technique are as follows:

• Traffic loads of communication networks usually result from the aggre-gation of many individual sources. These individual sources usuallycorrespond to users whose traffic submissions are not precisely predict-able. In addition, these sources are generally not coordinated with eachother, leading to a traffic flow that appears random. Other user-deter-mined properties of network traffic, such as selection of destinationsand service-quality parameters, are also often modeled in a stochasticmanner 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 thatmay change, such as disks or tape drives. In other cases, contention forcomputer resources such as the bus, CPU, or memory may present aparticular task with variable delays in accessing these resources. Thesedelays may be modeled by explicitly representing all the tasks that con-tend for the resources, or the presence of other tasks may be modeled ina more abstract fashion by incorporating variable delays into operationsthat access the resources of interest.

• The definition of certain communication protocols requires them toperform operations on a random or pseudo-random basis. Common

501-Simde

Modeling Concepts Executing SimulationsS

imu

lation

Desig

n

examples include selecting random timer values for message retrans-missions, and randomly selecting an order in which to service multiplecontending traffic sources.

• The quantity and placement of bit-errors affecting transmitted packetsare 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 stochasticallyparameterized OPNET model.

Creating Variable Behavior

Stochastically modeled elements depend on a random number source on whichto base their behavior. By “drawing” from the source, these elements canincorporate variability into appropriate actions or decisions as they are taken.

As mentioned earlier, it is impossible for a computer program, by its verynature, to exhibit genuinely unpredictable behavior. If a simulation programremains the same for multiple simulation runs, then any change in its behaviormust come from a change in its operating environment (i.e., its input). Inparticular, even the random number stream used to implement stochastic behavior,must be forced into a different mode in order to yield different results fromsimulation to simulation.

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

For a simulation that incorporates stochastic elements, each distinct randomnumber seed value will produce different behavior and yield new results. Eachparticular simulation can then be thought of as representing one possible scenarioof events for the modeled system. However, no single simulation can necessarilybe used as an accurate gauge of “typical” system behavior, since it is conceivablethat even atypical behaviors, provided they are possible, may be achieved for somerandom number seed. Therefore, a technique that is frequently used is to exercisethe simulation model multiple times while varying the random number sequence.The results obtained from the separate simulations can be combined (usuallysimply 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.

502-Simde


• 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 numbersequence initialized with the value of the seed environment attribute. The randomnumber generator used to create this sequence is provided by the host computer’soperating system and may vary on certain platforms. The following tablesummarizes the random number generation sources used on each operating systemsupported by OPNET. Contact OPNET Technologies for information on operatingsystems other than those listed in this table.

For models that require complete independence of random number sequencesused by different stochastic elements, processes and pipeline stages may makeindependent calls to the host computer’s random number facility or other,proprietary random number generators. The Dist package of the Simulation Kernelprovides a special KP, op_dist_outcome_ext(), which supports use of probabilitydistributions with proprietary random number generators. Refer to the DistributionPackage 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 stochasticbehaviors, many simulation studies also vary certain properties, or operatingconditions of the model. In this manner, the modeled system can be characterizedfor a range of possible configurations in order to support trade-off analysis anddetermine the system’s limitations and peak performance conditions.

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

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()

503-Simde


imu

lation

Desig

n

information on attribute promotion, refer to the Modeling Framework chapter ofModeling Concepts.

A second mechanism that supports variation of model configuration is basedon the use of variables that are not associated with any particular objects. Thesevariables 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 haveno association with objects, they are well-suited to representing system-wide, orglobal parameters. The interpretation and application of simulation attributes andtheir values is left to the user-defined code; the Kernel merely provides an interfaceto facilitate this type of parameterization.

Both promoted attributes and simulation attributes are treated in the samemanner when a simulation’s parameters are specified. OPNET’s Simulation Toolallows each simulation to complete a numerical attribute’s specification byproviding 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 oneattribute is assigned a range or set of values, the user has implicitly specifiedmultiple 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 theSimulation Tool executes a separate simulation for each combination of theattribute values. Care should be taken not to launch an excessive number ofsimulations in this manner. The following figure illustrates the specification ofsimulation parameters in the Simulation Tool. For more information on using thistool, refer to the Simulation Tool chapter of Editor Reference.

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

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 promoted attribute of object S1 and takes on 3 distinct values.

“Congestion Control” is a sim-ulation attribute, unassociated with any particular object

504-Simde


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 mechanismsdescribed above is for conducting studies where attributes are varied over a rangeof values. For each new attribute configuration, a new simulation is executed, andif stochastic behavior is involved in the model, multiple simulations may be runwith different random number seeds. Thus, the complete study is based on asequence of simulations.Each simulation in the sequence records simulation outputin vector, scalar, or animation form, for later analysis. In general, scalars are usedwhen sequences of simulations are executed because this is the form of output datadesigned for parametric studies and that can be accumulated in a single output fileover the course of many simulations. However, it may be interesting to observedynamic behavior for certain simulations in the sequence by also storing vectordata.

Simulation sequences may of course be achieved by manually runningindividual sequences, one at a time. However, in general, there can be manysimulations in the require sequence, and some automation of the process isdesirable. It is particularly useful to be able to run simulation sequences withouthuman intervention over long periods of time, such as over night, or over severaldays.

There are two approaches to automating execution of simulation sequences.The first is supported by OPNET’s Simulation Tool, which provides a graphicaluser interface for configuring a sequence and running it. The second approachrelies on the fact that OPNET simulations are ordinary programs that can thereforebe 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, orfor the same, if needed. In general, because an object can represent more than onesimulation (due to attributes having multiple values or ranges), a simulation objectis also known as a simulation set. The simulation objects provide attributes thatconfigure various aspects of each simulation set. The primary attributes of thesimulation object are summarized in the following table:

505-Simde


imu

lation

Desig

n

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.

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.

506-Simde


In typical simulation studies involving stochastic behavior, it is desirable to runseveral differently-seeded simulations for each configuration of the model. Asexplained above, changing the random number seed over several scenarios helps toestablish confidence in the results that are obtained. Since each simulation objectprovides specification for only one seed value, such sequences require multiplesimulation objects. Each simulation object can still represent multiple simulations:these correspond to the different configurations of the system independent ofrandom number generation. The following diagram illustrates such a simulationsequence specification, and shows typical output scalar graphs that may result.

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.

Simulation Object Attributes (Cont.)

Attribute Description

507-Simde


imu

lation

Desig

n

Scripted Sequences

Scripts or programs provide a convenient method of executing simulationsequences when outside the Simulation Tool. A script provides a very generalenvironment for executing programs and commands and can be used to designcomplex 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

Use of Simulation Sequence to Generate Output Scalars and Confidence Intervals

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

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.

508-Simde


attribute values automatically. Examples appear below of each of these approachesimplemented in the UNIX C-shell environment. Refer to your host computer’sdocumentation for more information on script programming.

#!/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













Example Simulation Script with One Command per Simulation

509-Simde


imu

lation

Desig

n

#!/bin/csh

# script for executing fddi_net_32 model with range of values# of TTRT parameter

# Loop through range of TTRT valuesforeach 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)

# Issue update statement indicating which sim. is about to happenecho '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

Example Simulation Script using Loop and Attribute Value Table

510-Simde


Chapter 7 – Simulation Design

Documents

Transcript of Chapter 7 – Simulation Design