1—System Environment

1 System Environment
This section describes various aspects of the interface between
OPNET Modeler and its operating environment, including:

• File System Organization on page EI-1-2

• Installation Directory (<install_dir>) on page EI-1-3

• User Home Directories <HOME> on page EI-1-9

— Administration Directory (op_admin) on page EI-1-9
— Models Directory on page EI-1-7
— User Report Directory (op_reports) on page EI-1-17

• File Naming Conventions on page EI-1-20

• Customizing the User Interface on page EI-1-29

Note—Visit the OPNET Support Center (www.opnet.com/support) for the latest

system requirements.

Related Topics

• Licensing

OPNET Modeler/Release 16.1 EI-1-1

1—System Environment

File System Organization

For convenience, OPNET Modeler files are organized into at least three general
locations within the file system. These locations allow files of different types to
be stored separately, as follows:

• Installation Directory (<install_dir>) contains OPNET Modeler system

software and standard models.

• Administration Directory (op_admin) contains configuration and by-product

files.

• Models Directory contains user-developed models in one or more locations.

Components of the licensing system are not stored in the installation directory,
but rather locally, in one of the following locations:

• Windows: <primary_hard_drive>:\OPNET_license
The <primary_hard_drive> is the first drive letter (usually C:) that names
a non-removable, non-network local drive partition.

• Linux: /opt/OPNET_license

Figure 1-1 File System Organization

<install_dir
op_models
<reldir_1> <reldir_2> <reldir_n>
<user_models_1>

<user_models_2>
sys doc models
<user_models_n>
std
<arch> include
tutorial_ref
configs lib
vendor_models
etc reports

help schemas
op_admin
hpov tariff

icons utilities bk tmp

images web_reports

Components of the licensing system are stored locally

/opt (Linux) or <primary_hard_drive> (Windows)

OPNET_license

license_file license_server_log app_stats_log

EI-1-2 OPNET Modeler/Release 16.1

 1—System Environment

Installation Directory (<install_dir>)

The installation directory (<install_dir>) is the directory where the release
media contents are downloaded. The installation directory is an important
reference location on the disk. It is usually represented by the symbol
<install_dir>, especially when it appears as part of a path name, as in
<reldir>/sys/include.

The symbol <install_dir> represents an actual directory located

somewhere in the file system. The user (or system administrator) has the
freedom to select the location of <install_dir> and create the directory
there; no hardwired location is required. One of the typical locations for
<install_dir> is in the /usr directory (for example, /usr/opnet). This
location is beneficial when several users with different accounts need access to
OPNET Modeler. In this case, <install_dir> is owned by the root or system
administrator account, with read and execute permissions set up for other
accounts.

Another common location for <install_dir> is within a user home directory.

This location is useful when only one user requires access to OPNET Modeler
and it is preferred to handle all system administration tasks locally. In this case,
<install_dir> should not be given the name <HOME>/opnet, because this
name may conflict with execution of the opnet program in the home directory.
Instead, choose a neutral name such as <HOME>/opnet.

Because the installation directory stores all OPNET analysis software (including
software for different solutions, releases, and workstation architectures), there
typically is only one installation directory per installation site. Even when several
workstations are used to execute OPNET Modeler, all of the workstations can
share a single <install_dir> located on a file server (via the Network File
System, NFS, or a similar system).

The installation directory contains one or more release directories

(<install_dir>/<release>). These directories contain the system
software and standard models for a particular release of OPNET Modeler.
There is always at least one release directory.

When installed, new releases replace the existing files within the subdirectory,
but the top-level organization remains unchanged. The following figure depicts
this organization.

Figure 1-2 Installation Directory Organization

<install_dir>

<reldir_1> <reldir_2> <reldir_n>

OPNET Modeler/Release 16.1 EI-1-3

1—System Environment

Release Directory (<reldir>)

The release directory (<install_dir>/<release>, or simply <reldir>)
contains the complete software and model files for a specific release. A release
is a distinct version of OPNET Modeler that typically incorporates new features
or major bug fixes. A release directory is identified by a name such as 16.1.A.

Each release directory contains three subdirectories:

Table 1-1 Subdirectories in the Release Directory

This subdirectory... Contains...

sys system software for the corresponding release

doc data files used by the documentation viewer

models models supplied with OPNET Modeler

The following figure depicts this organization.

Figure 1-3 Release Directory Organization

<reldir>

sys doc models

If you download a release or software update into an existing <reldir>

directory, it replaces the existing files within these subdirectories, but the
top-level organization remains unchanged. Typically, however, a new release
goes into a new <reldir> directory, in which case any existing <reldir>
directories (and their contents) remain unchanged. The names and locations of
subdirectories under each <reldir> directory should not be modified after
installation.

System Directory (sys)

The system directory (<reldir>/sys) contains software and support files,
including all programs, libraries, and header files. The organization of sys is
copied from the release media and remains fixed. The contents of sys
subdirectories vary somewhat during installation and software updates, but
remain fixed during use of the software (that is, no non-installation programs
modify the contents of the sys directory and its subdirectories).

Because sys contains all of the software, it is a resource that can be shared by
multiple users. It is also possible that more than one version of OPNET Modeler
will be present at a site, due to different machine architectures. The software for
different architectures is stored in individual subdirectories.

EI-1-4 OPNET Modeler/Release 16.1

 1—System Environment

The following table lists the subdirectories in the sys directory.

:
Table 1-2 Subdirectories in the System Directory
Directory Contains

configs Code for the menus called by .ets files

etc Files related to third party products

help HTML help files

hpov Registry setting for interaction with HP OpenView

icons Icon databases

images Maps, splash screens, and web images

include Header files used during the compilation of process models

lib Python files

reports Report templates for Flow Analysis functionality

schemas Report schemas for NetDoctor functionality

tariff Data files for Flow Analysis functionality

utilities Miscellaneous files that do not fall under any other category

web_reports Images and code used in web reports

The following figure shows this organization.

Figure 1-4 System Directory Organization

sys

<arch> include

configs lib

etc reports

help schemas

hpov tariff

icons utilities

images web_reports

OPNET Modeler/Release 16.1 EI-1-5

1—System Environment

Configuration Directory (configs)

The configuration directory (<reldir>/sys/configs) contains files used to
specify the configuration of the user interface, such as menu items and
shortcuts. These files have the file extension .ets.

Miscellaneous Directory (etc)

The miscellaneous directory (<reldir>/sys/etc) contains miscellaneous
files and utilities.

Icon Directory (icons)

The icon directory (<reldir>/sys/icons) is the standard location for files
containing icons used by GUI-based programs. (Another common location is
each user’s administration directory.) Icon databases can be stored anywhere,
however, so long as you specify the location by including the icon database
directory in the value of the mod_dirs preference.

Icon databases in directories listed earlier in mod_dirs override corresponding

databases in directories specified later in the list. Typically, the system and
program icon databases remain in the icon directory, unmodified and
unoverridden, and user’s special icons are stored in the user icon databases
within their administration directories. In this case, the administration directory
appears before the icon directory in the mod_dirs list.

The icon_dbs preference specifies which icon databases a particular application

should use. GUI-based OPNET programs use three types of icon databases.

Table 1-3 Types of Icon Databases

Icon database Contents

sys.icons System icon database contains icons used in most GUI-based programs.

<program>.icons Separate program icon databases exist for each GUI-based program
(such as modeler or op_vuanim). These databases contain icons specific
to the corresponding program.

<name>.icons User icon databases contain user-defined icons created with the Icon
Editor.

In addition to the icons in these databases, a special “missing” icon is built into
GUI programs. A program displays this icon when it can locate neither the
specified icon (usually a user-defined icon) nor an appropriate default icon.

Image Directory (images)

The image directory (<reldir>/sys/images) contains bitmap image files
used by OPNET Modeler programs, such as splash screens, maps, and various
images used by web reports.

EI-1-6 OPNET Modeler/Release 16.1

 1—System Environment

Include Directory (include)

The include directory (<reldir>/sys/include) contains the OPNET header
files. Header files are C language files that contain symbolic constants, data
structure definitions, and preprocessor macros. Each of the header files
contained in include has the conventional .h suffix. Explanations of individual
header files are not provided here because you do not need to individually
reference these files.

Help Directory (help)

The help directory (<reldir>/sys/help) contains HTML and related files
that describe dialog boxes.

Models Directory
The models directory (<reldir>/models) contains the models that are
included on the release media. The organization of models, like that of sys, is
initially obtained from the release media and generally remains fixed.

Table 1-4 Contents of the models Directory

This subdirectory... Contains...

module_ref Reference files used by optional product modules.

std Models of basic nodes and links, plus example network

models.

tutorial_ref Reference files showing correct results for models created

from the tutorials.

vendor_models Device models based on many different sources, including

studies conducted at the Harvard Network Device Test
Laboratory and product data from the device makers.

You can use the models in the std subdirectory as guides or as a basis for
developing your own network models.

Module Reference Models Directory (module_ref)

The module reference models directory (<reldir>/models/module_ref)
contains reference models used by optional product modules.

Standard Models Directory (std)

The standard models directory (<reldir>/models/std) contains models
developed for and shipped with OPNET Modeler. These models include the
basic nodes and links used to develop networks, as well as complete network
models.

The organization of std is initially obtained from the release media and
generally remains fixed.

OPNET Modeler/Release 16.1 EI-1-7

1—System Environment

Tutorial Reference Models Directory (tutorial_ref)

The tutorial models directory (<reldir>/models/tutorial_ref) contains
reference models for the tutorials. Reference models are completed examples
of the files created in each lesson. The required models for the tutorial exercises
are in the <reldir>/models/std/tutorial_req directory.

Vendor Models Directory (vendor_models)

The vendor models directory (<reldir>/models/vendor_models) holds
models based on a variety of sources, including studies conducted at the
Harvard Network Device Test Laboratories (HNDTL) and generally-available
product data from the device makers.

No proprietary information was provided by device manufacturers.

Documentation Directory (doc)

The documentation directory (<reldir>/doc) contains files for the
documentation and help. These files include product documentation and
tutorials.

EI-1-8 OPNET Modeler/Release 16.1

 1—System Environment

User Home Directories <HOME>

The user home directories contain configuration and by-product files.

On Windows, the user home directories are located under the following
directory:

C:\Documents and Settings\<user name>

The user home directories include:

• Administration Directory (op_admin)

• Models Directory

• User Report Directory (op_reports)

Administration Directory (op_admin)

The administration directory (<HOME>/op_admin) contains configuration
information and files specific to an individual user, such as:

• program configurations

• model directory paths

• logical key definitions

• model backups

Because the installation directory serves as a centralized resource for all users
at a site, it is not an appropriate place to store files that are specific to a particular
user. Such files are best stored in the home directory of each user, where they
can be easily found and are protected by the user’s directory permissions. For
this reason, OPNET Modeler supports individual administration directories in
which users store their files.

The administration directory must be named op_admin so that programs can

access it via the shell variable-based path name <HOME>/op_admin. This
requirement stems from the overall file system organization. Because the
installation directory and model directories can be placed anywhere in the file
system, OPNET Modeler must have a fixed location from which to obtain the
locations of these directories. The administration directory serves as a fixed site
for this configuration information relative to the current user’s home directory.

OPNET Modeler/Release 16.1 EI-1-9

1—System Environment

The initial organization of op_admin is established at installation, as follows:

Table 1-5 Initial Contents of the op_admin Directory

Subdirectory Contents

bk The backup directory stores user model backups, which are

automatically created by the modeler program at
user-specified intervals.

tmp The temporary file directory stores any temporary files

created by OPNET Modeler programs.

opnet-<release>.prefs The preferences (environment database) file specifies user

(for example: configuration data and preferences for OPNET Modeler
opnet-16-0.prefs) programs (including the above-mentioned directory location
information).

Backup Directory (bk)

OPNET Modeler creates two types of backup files:

• time-based backup files preserve all model files being edited at the time the
backup occurs. You can specify the backup interval (by default set at 60
minutes) with the backup_interval preference.
Note—The backup operation is not performed if OPNET Modeler is
performing another operation (such as a simulation) when it is time to
perform a backup.

• version-based backup files are created each time you modify and save an
existing model file. You can specify the number of versions saved with the
backup_max_count preference.

Both types of backups are stored in the backup directory

(<HOME>/op_admin/bk) with file names based on the name of the
corresponding model.

Automatic backup behavior is specified by the following preferences:

• project_backup_disable—Specifies whether to suppress automatic backups

of open projects.

• project_backup_query_dialog_disable—Specifies whether to suppress the

Project Backup Prompt dialog box before performing automatic backups.

Version-based backups are named using the syntax:

<model_name>_bk.<n><file_type_suffix>

where n is a consecutive number, with a maximum value set by the

backup_max_count preference.

EI-1-10 OPNET Modeler/Release 16.1

 1—System Environment

Time-based backup files are named using the syntax:

<model_name>_bk.<file_type_suffix>

If a name has not been assigned to a model when a time-based backup occurs,
it has the default name unnamed. This file overwrites any older unnamed
model backups of that type.

The file suffix identifies the type of file. See File Naming Conventions on
page EI-1-20 for a list of these suffixes.

You can make a model backup a regular model file by moving or copying it into
a model directory, using one of the following commands:

• sample Linux command-line:

% mv net1_bk.nt.m net1.nt.m

• sample Windows command-line:

C:\> move net1_bk.nt.m net1.nt.m

The backup model then appears in the relevant model menus.

Temporary File Directory

The temporary file directory (<HOME>/op_admin/tmp) contains temporary
files generated by OPNET Modeler in the course of execution, such as the
graphics capture files and report files generated by printing operations.

Most of the files stored in tmp have value for a limited time only, after which they
can be removed. Typically, the only files worth keeping are captured graphics
or PostScript files that must be reprinted periodically. You should move such
files from tmp and store them elsewhere to avoid accidental removal.

During periods when a great deal of printing is being performed, the temporary
directory tends to fill up with files. It is a good idea to periodically clear out tmp
using the op_clrtmp utility described in op_clrtmp on page EI-3-4.

Related Topics

• User Home Directories <HOME>

OPNET Modeler/Release 16.1 EI-1-11

1—System Environment

Model Directory (op_models)

The models you develop are stored in one or more directories called user model
directories. The mod_dirs preference is stored in your preferences file
(<HOME>/op_admin/opnet-<rel>.prefs) and lists all model directories
that are visible to OPNET Modeler. The directories listed in your mod_dirs
generally fall into one of two categories:

• User model directories, which contain the models that you or other users
have created.
As a convenience, OPNET Modeler creates a directory named op_models
in your user home directory and adds this directory to the mod_dirs
preference. You can change this after installation, completely removing
op_models if desired.

• OPNET directories, which contain files that are included in the standard
installation. These directories include system and model files (under
<install_dir>/sys and <install_dir>/models, respectively).
These directories are described in Installation Directory (<install_dir>) on
page EI-1-3.

When the preferences file is first created, it generally lists one user model
directory as the first entry in the table. Then it lists all the standard directories in
subsequent entries:

Figure 1-5 Model Directories (mod_dirs) List: Example

"c:\users\modeler_user\op_models", /* User model directories */

"c:\Program Files\OPNET\12.0.A\sys\lib", /* System directories */
"c:\Program Files\OPNET\12.0.A\sys\icons",
"c:\Program Files\OPNET\12.0.A\sys\images",
"c:\Program Files\OPNET\12.0.A\sys\include",
"c:\Program Files\OPNET\12.0.A\sys\imagesmaps",
"c:\Program Files\OPNET\12.0.A\sys\configs",
"c:\Program Files\OPNET\12.0.A\sys\help",
"c:\Program Files\OPNET\12.0.A\sys\utilities",
"c:\Program Files\OPNET\12.0.A\sys\reports\stylesheets",
"c:\Program Files\OPNET\12.0.A\models\std\applications",
"c:\Program Files\OPNET\12.0.A\models\std\atm", /*Model directories*/
"c:\Program Files\OPNET\12.0.A\models\std\atv",
"c:\Program Files\OPNET\12.0.A\models\std\base",
....

You might find that your list of user model directories grows as you continue to
create and save models.There are two primary mechanisms for adding a model
directory:

• When you save a file in a directory that is not included in your mod_dirs list,
OPNET Modeler adds the directory automatically.

• You can also add a directory manually by choosing File > Model Files >
Add Model Directory.

EI-1-12 OPNET Modeler/Release 16.1

 1—System Environment

Project Subdirectories
In contrast with other types of models, a project model has multiple associated
files: the project file itself, as well as network scenario files, analysis
configurations, output files, and so on. For this reason, the behavior when
saving projects differs from the behavior for other types of models.

When you save a new project for the first time—or save an old project with a
new name—OPNET Modeler does not save the project in the current directory.
Instead, it creates a subdirectory (<project_name>.project) and saves all files
associated with that project in the subdirectory. This ensures that all files related
to a specific project reside in one directory, and that different projects do not
share the same directory.

Note—You cannot save other types of files in a project directory (that is, a
directory whose ends with “.project”) because project directories are reserved
for files created as part of that project.

The following figure shows a simple user models directory. The user saved two
projects (my_App_Config_project and my_IP_project) in
c:\users\jsmith\op_models. As a result, OPNET Modeler has created
two subdirectories and stored the corresponding project files in these
subdirectories.

Figure 1-6 User Directory with Project Subdirectories

OPNET Modeler/Release 16.1 EI-1-13

1—System Environment

Guidelines for Organizing Your User Files

You can save files in any non-project directory that is visible to your operating
system. It is good practice to organize your user models and other files in a
consistent manner; this will make it easier to browse, find, and keep track of all
your models and other files.

We suggest the following optional guidelines:

• Keep all files under one parent directory. This makes it easier to keep track
of all your files—you know that they are all located in that directory—and to
move them if necessary.

• Whenever you save a file in a directory that is not listed in your mod_dirs list,
OPNET Modeler adds the new directory to mod_dirs automatically. As you
add new directories, your models list becomes more complex and potentially
harder to navigate. Consider carefully where you want to save a new file. Do
you want to add a new, separate directory for this file, or store it with similar
files in an existing models directory?

• It might make sense to organize files into separate directories based on

model type. The following example shows one possible organization.

Figure 1-7 User Model Directories List: Example

/* parent directory for all projects */

c:\users\jsmith\op_models\project_files
c:\users\jsmith\op_models\project_files\project_1.project
c:\users\jsmith\op_models\project_files\project_2.project
...
/* ACE files for application XYX (all transactions): */
/* filters, import settings, etc. */
c:\users\jsmith\op_models\ACE\app_XYX
/* ACE files for application XYX (individual transactions): */
/* capture files, .atc files, etc. */
c:\users\jsmith\op_models\ACE\app_XYX\transaction_1
c:\users\jsmith\op_models\ACE\app_XYX\transaction_2
c:\users\jsmith\op_models\ACE\app_XYX\transaction_3
...
/* parent directory for Device Creator node models */
c:\users\jsmith\op_models\device_creator_nodes
...
/* parent directory for Model Assistant files (general use) */
c:\users\jsmith\op_models\ma_files
...

EI-1-14 OPNET Modeler/Release 16.1

 1—System Environment

Guidelines for Organizing Your Model Directories (mod_dirs) List

The order of directories in the mod_dirs list is very important because it
determines the precedence of model searches. When OPNET Modeler
searches for a model, it reads through the directories listed in mod_dirs (from
top to bottom) until it finds the model. If your model directories contain two
models that have the same model type and filename, OPNET Modeler always
uses the model in the directory that is listed first.

Suppose you have two models named “my_node_model” that are stored in two
different model directories. For any node based on “my_node_model,” an
analysis or design operation (such as a simulation or flow analysis) uses the
model in the first directory and ignores the file in the second directory.

Note—It is good practice to specify a unique name for every file of a specific file
type (project, node model, process model, ACE Analyst file, and so on). If
OPNET Modeler notifies you that your model directories contain multiple files
with the same file type and name, we recommend that you rename files so that
all filenames are unique. This ensures that the wrong model does not get used.

If you want to keep multiple versions of the “same” model in your model
directories, you might need to open the mod_dirs preference and edit the order
of your user model directories. This might occur, for example, if you want to run
discrete event simulations for a scenario using different versions of the same
node model.

You should observe the following guidelines when organizing your model
directories (and icon database directories, which are also listed in mod_dirs):

• Do not change the “sys” and “models” sections of the table (that is, the
directories beneath <reldir>/sys and <reldir>/models. Edit only the
user model directories at the start of the list. These three sections are
illustrated in Figure 1-5 on page EI-1-12.

• Place the directory that takes precedence for new models first in the user
model directories list. The first directory in the list is the default models
directory; in some cases, OPNET Modeler saves new files here
automatically, without prompting you for a location. For more information,
see Default Model Directory on page EI-1-16.

• Place more actively used model directories, and directories with custom icon
databases, before less actively used directories. This ensures that their
contents will take precedence in the event of name conflicts.

• If you have duplicate versions of the same model (same model type and
same filename), place the directory with the “highest-priority” models before
the other directories. This ensures that any simulation, flow analysis, or other
process uses the correct version of that model.

• Place the icon directory (icons) last in the user model directories section.

OPNET Modeler/Release 16.1 EI-1-15

1—System Environment

Default Model Directory

The default model directory is the first model directory in the mod_dirs list. When
you save a file, OPNET Modeler might simply save the file in the default
directory instead of prompting you for a location. If you save a file without getting
prompted for a location, and you are not sure where the file got saved, choose
Edit > Preferences, open the mod_dirs preference table, and check the first
directory listed.

This behavior applies to new models only, not to previously saved models: when
you save a previously saved model, OPNET Modeler writes the file to its original
location when the program started or the last time a Refresh Model Directories
operation was invoked.

There are some enforced “coupling” relationships between models that can
cause new models to be stored in non-default model directories. Model coupling
applies to all model types that are derived from other model types. The following
table lists model coupling relationships.

Table 1-6 Model Coupling Relationships

Source Model Derivative Model

Process Model Process C or C++ File

Process C or C++ File Process Object Code File

Network Model Simulation Archive

Network Model Simulation C File

Network Model Network Repository

Network Repository Output Vectors

Network Repository Output Scalars

Ema Application C or C++ File Ema Application Object Code File

Ema Application Object Code File Ema Application Executable

Related Topics

• User Home Directories <HOME>

EI-1-16 OPNET Modeler/Release 16.1

 1—System Environment

User Report Directory (op_reports)

OPNET Modeler can generate a wide variety of reports. All reports are
organized into subdirectories beneath a parent directory (specified by the
“reports dir” preference). By default, the parent directory is located in your user
home directory as <HOME>/op_reports (next to op_admin and
op_models).

The following sections describe how reports are organized within the parent
directory. The overall directory organization is illustrated in Reports Directory
Organization on page EI-1-18.

Project/Scenario Reports
Reports generated from a specific project and scenario are organized into
subdirectories based on project and scenario name. Within each
project/scenario-specific subdirectory, reports are organized by report type. For
example, the reports directory for a specific scenario might look like this:

<reports_dir>
<project_name>
<scenario_name>
DES Reports
Flow Analysis Reports
Scenario Web Reports
<project_name>-<scenario_name>/
Obj-Attr Diff/

ACE Analyst Reports

When you generate a report in ACE Analyst, a file browser appears and
prompts you for the location of the report. By default, reports are organized as
follows:

• For web reports, the default directory is a time-stamped subdirectory (under

<reports_dir>/ACE Reports) based on the ACE Analyst file name
and the time the report was generated:
<reports_dir>/ACE Reports/<ace_file_name>@<time_stamp>

• For ACE Analyst comparison and multiple-transaction reports, the default

directory is the <reports_dir>/ACE Reports

• For all other ACE Analyst reports, the default directory is based on the
ACE Analyst file name: <reports_dir>/ACE
Reports/<ace_file_name>

NetDoctor Reports
Reports generated by NetDoctor are organized into subdirectories based on
report type, as follows:

OPNET Modeler/Release 16.1 EI-1-17

1—System Environment

<reports_dir>
<project_name>
<scenario_name>
NetDoctor Reports
<template>-RTF Report/
<template>-Web Report/
Security Report@<date><time>/

Reports for Workflows that Span Multiple Scenarios

Reports generated by workflows that span multiple scenarios—such as
Capacity Planning and VoIP Readiness Assessment—are stored in separate
directories under the project directory, based on workflow type (for example,
<reports_dir>/<project_name>/Capacity Planning Reports).

<reports_dir>/
Capacity Planning Reports/
VoIP Readiness Assessment Reports/

Reports Directory Organization

The user reports directory is organized as follows:

<reports_dir>/
ACE Reports/ 1
2
<ACE Analyst_file_name>@<date><time>/
3
<ACE Analyst_file_name>/
ICI Format Reports/
Mainframe Characterization Reports/
Packet Format Reports/
Process Model Reports/
<project_name>/
Capacity Planning Reports/
VoIP Readiness Assessment Reports/
<scenario_name>/
DES Reports/
graphs@<date><time>/
tables@<date><time>/
Flow Analysis Reports/
tables@<date><time>/
NetDoctor Reports/
<template>-RTF Report/
<template>-Web Report/
Security Report@<date><time>/
Object-Attribute Difference Reports/
Compared Against <project><scenario>/
Scenario Web Reports/
User-Defined Reports/
tables@<date><time>/

Notes

1) This is the default directory for ACE Analyst Multiple Transaction Word
reports and ACE Analyst Comparison reports.

EI-1-18 OPNET Modeler/Release 16.1

 1—System Environment

2) This is the default directory for ACE Analyst web reports.

3) This is the default directory for all other ACE Analyst reports.

Related Topics

• User Home Directories <HOME>

OPNET Modeler/Release 16.1 EI-1-19

1—System Environment

File Naming Conventions

OPNET Modeler looks for models in the model directories, which are listed in
the mod_dirs preference. Within each model directory, models are stored as
ASCII, binary data, or object code files, on a “one file per model” basis.

Versioning in File Names

Certain model files might be updated from one release to the next, so a version
number (v<n>) is included in the file name. For example:
ams_aal1_conn_v3.pr.m
ams_support_v2.ex.c

Refer to the version number to verify that you are using the most recent version
of a particular model. Version numbers might be included in the following file
types:

• process model files (.pro.m)

• header files (.h)

• packet format files (.pf.m)

• ici format files (.ic.m)

• external code files (.ex.c, .ex.h)

File Names for Compiled Code

Files that contain compiled code (such as object files) are specific to a particular
kernel or machine architecture. Thus, the names of such files contain suffixes
to characterize the code contained in the file. The format for a file name is
<file name>.<environment>.<architecture>.<file type>

The <environment>, <architecture>, <file type> suffixes are described in the

following topics.

Environment Suffix
The file names for object files, repositories, and simulation executables include
a suffix that identifies what kind of code the file contains. This suffix is used to
prevent different compilation modes from overwriting one another’s files. The
environment suffix appears before the architecture suffix, as in
sink.mtdev32.i1.o.

EI-1-20 OPNET Modeler/Release 16.1

 1—System Environment

Simulations

• Sequential
— Development: dev32, dev64
— Optimized: opt32, opt64

• Parallel
— Development: mtdev32, mtdev64
— Optimized: mtopt32, mtopt64

Graphical tools

• gui32, gui64

Architecture Suffix
All model files are portable across different machine architectures. However,
simulation executables, object code files, and simulation archives are specific
to a given machine architecture.

Architectures are characterized by CPU type (which determines the object code
format) and OS type (which determines the variations of library functions). The
architecture suffix incorporates these data items in a two-character code, as
follows:
<CPU_char><OS_number>

The following table lists the architecture suffixes:

Table 1-7 Architecture Suffixes

Suffix CPU Type Operating System Vendor

i0 Intel x86 or x86-64 Windows Microsoft

i1 Intel x86 or x86-64 Linux various

The architecture suffix is optional. It’s use is controlled by the arch_suffix

preference. The following examples show the names of files created with
arch_suffix set to both FALSE and TRUE.

arch_suffix = FALSE arch_suffix = TRUE

eth_mac.dev32.pr.obj eth_mac.dev32.i0.pr.obj
eth_net.opt32.sim eth_net.opt32.i1.sim

OPNET Modeler/Release 16.1 EI-1-21

1—System Environment

File Type Suffix

OPNET Modeler determines the type of each model file from a unique file name
suffix associated with each type. A file type suffix comprises two parts:
<OPNET type>.<OS type>

The OS type is a standard suffix used by the operating system, as follows:

Windows

• Object files: .obj

• Libraries: .dll

Linux

• Object files: .o

• Libraries: .so

The following table lists the defined OPNET file types.

Table 1-8 OPNET File Types

File Type Suffix Description Format

.ac Analysis Configuration binary data

.ace.f ACE Filter Definition ASCII text

.ace.hm ACE Host Mapping (obsolete) ASCII text

.ace.i ACE Import Definition (obsolete) ASCII text

.ace.ic.txt ACE Import Configuration Files ASCII text

.ace.mt.txt ACE Multi-Transaction Report Settings ASCII text

.ace.qpb ACE QuickPredict Bar Chart Templates ASCII text

.ace.qps ACE QuickPredict Graph Templates ASCII text

.ace.rt.txt ACE MS Word Report Settings ASCII text

.ace_dict ACE Protocol Dictionary ASCII text

.ad.m Public Attribute Description binary data

.adt Application delay tracking data binary data

.aed.m ACE Whiteboard file binary data

.af Automation Settings File binary data

EI-1-22 OPNET Modeler/Release 16.1

 1—System Environment

Table 1-8 OPNET File Types (Continued)

File Type Suffix Description Format

.afldviz.xml Antenna Field Visualization XML

.agents ACE Agents files ASCII text

.ah Animation History binary data

.alias Alias Modifications ASCII text

.antn.so Antenna gain shared library

.as Animation Script ASCII text

.atc.m ACE Application Task Characterization binary data

.bkg.i Background map Image binary data

.bmp BMP Image binary data

.bu_dict Background Utilization import dictionary ASCII data

.cds Cartographic Data Set binary data

.cml Custom Model List ASCII text

.csv Comma Separated Values Data File ASCII text

.demand.d Derived Demand Model binary data

.demand.m Demand Model binary data

.dict TIF Dictionary binary data

.edge Edge Devices Information ASCII text

.ef Environment File ASCII text

.el Iso-Line/Cartographic Data Set binary data

.em.c EMA C code C code form

.em.cpp EMA C++ code C++ code form

.em.o/.em.obj EMA code object code form

.em.x EMA Application executable form

.esd.m External System Definition Model binary data

.ets External Tool Support File ASCII text

.ets.c External Tool Support C code C code form

OPNET Modeler/Release 16.1 EI-1-23

1—System Environment

Table 1-8 OPNET File Types (Continued)

File Type Suffix Description Format

.ets.cpp External Tool Support C++ code C++ code form

.ets.o/.ets.obj External Tool Support object object code form

.ets.so External Tool Support shared library

.ex.c External C Code C code form

.ex.cpp External C++ Code C++ code form

.ex.h External Code Include File C/C++ header file

.ex.o/.ex.obj External Code object code form

.fl.m Filter Model binary data (editable form)

.fl.x Filter Model binary data (executable form)

.gdf General Purpose Data File ASCII text

.gif GIF Image binary data

.grf Grouping Rules File ASCII text

.gsf Generic Settings file ASCII text

.h/.hpp Header File C/C++ code

.hcon.l Hardware Configuration Library ASCII text

.hlp Help File ASCII text

.html HTML File ASCII text

.ia Import Assistance File ASCII text

.ic.m ICI Format binary data

.icons Icon Database binary data

.image Generic Image binary data

.imp.log Import Log ASCII text

.lib.xml i18n Library XML

.lk.d Derived Link Model binary data

.lk.m Link Model binary data

.lvdf Link utilization Visualization Plug-in Definition ASCII data

EI-1-24 OPNET Modeler/Release 16.1

 1—System Environment

Table 1-8 OPNET File Types (Continued)

File Type Suffix Description Format

.m.conv Model Conversion Script

.ma Model Assistance File ASCII text

.map.i Image Map binary data

.mce.m Mainframe Workloads binary data

.md.m Modulation binary data

.mid MapInfo Data Interchange Format File ASCII text

.mif MapInfo Data Interchange Format File ASCII text

.nd.d Derived Node Model binary data

.nd.m Node Model binary data

.ndr.xkwd NetDoctor Keyword File ASCII text

.nds Network Diff Selection ASCII text

.nt.log Simulation Log ASCII text

.nt.m Network Model binary data

.nt.so/.nt.dll Network Repository shared library

.nvism.dll/s0 Visualization Mappling Library shared library

.of Output Fragments binary data

.orb Satellite Node Orbit binary data

.ot Output Tables binary data

.otf Fragmented Output Tables binary data

.ov Output Vectors binary data

.ovd Output Vector Dictionary ASCII text

.pa.m Antenna Pattern binary data

.path.d Derived path object binary data

.path.m Path object binary data

.pb.m Probe List binary data

.pbr.m Report Probe Model binary data

OPNET Modeler/Release 16.1 EI-1-25

1—System Environment

Table 1-8 OPNET File Types (Continued)

File Type Suffix Description Format

.pbs.m SLA Probe Model binary data

.pd.m Probability Density Function (PDF) binary data (editable form)

.pd.s Probability Density Function (PDF) binary data (simulation loadable form)

.pdf Portable Document Format (Adobe Acrobat file) binary data

.pf.m Packet Format (obsolete) binary data

.pff.c Packet Field Conversion C code

.pff.o Packet Field Conversion Stage Mode object code

.pfp.c Packet Field Conversion C code

.pfp.o/.pfp.obj Packet Conversion Stage Model object code

.pk.m Packet Format binary data

.ppl.m Public Profile Model binary data

.pps.m Private Profile Storage binary data

.pr.c Process Model C C code form

.pr.cpp Process Model C++ C++ code form

.pr.m Process Model binary data form

.pr.o/.pr.obj Process Model object code form

.prj Project Model object code form

.prop.d Propagation Model binary data

.prop.p Propagation Parameter Set binary data

.prop.r.so TMM Propagation Model shared library

.ps.c Pipeline Stage Model C C code form

.ps.cpp Pipeline Stage Model C++ C++ code form

.ps.o/.ps.obj Pipeline Stage Model object code form

.py ETS Code Python source code

.pyc ETS Code Python byte code

.repos Repository shared library

EI-1-26 OPNET Modeler/Release 16.1

 1—System Environment

Table 1-8 OPNET File Types (Continued)

File Type Suffix Description Format

.repos.so/.repos.dll Simulation Repository shared library

.rspdb Response database binary data

.sce.f Server Workload Filter Library binary data

.sce.m Server Workloads binary data

.sce.t Server Workload Template binary data

.sce.x Server Workload Export XML

.scf Satellite Configuration binary data

.sched Task Scheduler data (Automation module) binary data

.sched.log Scheduled Tasks Log ASCII text

.sd Simulation Description ASCII text

.sddb Self Description database binary data

.sdi Services Definition File ASCII text

.scr OPNET Debugger script file ASCII text

.sel.f Logical Object Selection Filter ASCII text

.selset Selection Set file

.seq Simulation Sequence binary data

.si.a Simulation Archive object code archive

.si.c Simulation Main Procedure C code form

.si.o/.si.obj Simulation Main Procedure object code form

.sim Simulation Executable executable program

.srg.d Shared Risk Group, derived binary data

.srg.m Shared Risk Group binary data

.srgi Shared Risk Group Import File ASCII text

.supr.xml NetDoctor Suppressions XML

.tim Traffic Import Model object code

.trj Mobile Node Trajectory ASCII text

OPNET Modeler/Release 16.1 EI-1-27

1—System Environment

Table 1-8 OPNET File Types (Continued)

File Type Suffix Description Format

.ts.xml Terminal Script ASCII text

.tsf Time Settings File ASCII text

.urep.xml User Report Table XML

.val.r NetDoctor Rule (Pre-10.0) ASCII text

.val.rpt NetDoctor Report Template (Pre-10.5) ASCII text

.val.rr NetDoctor Rule ASCII text

.val.xrpt NetDoctor Report Template XML

.vd.m OPNET Vector Drawing binary data

.vdf View Definition File ASCII text

wb.xml Network Whiteboard XML File ASCII text

.wdomain.c Wireless Domain Code C code

.wdomain.cpp Wireless Domain Code C++ code

.wdomain.d Derived Wireless Domain binary data

.wdomain.m Wireless Domain binary data

.wdomain.o/.wdomain.obj Wireless Domain Code object code

.wrc UI Configuration Resource binary data

.xml XML File XML

.xs OPNET Stylesheet Specification ASCII text

.xsl XSL file XML

End of Table 1-8

EI-1-28 OPNET Modeler/Release 16.1

 1—System Environment

Customizing the User Interface

You can customize the following user interface items:

• Editing Keyboard Shortcuts on page EI-1-29

• Adding Optional Operations on page EI-1-30

These changes are made by editing the files that control the interface. These
are text files with the file name extension .ets (external tool support).

Editing Keyboard Shortcuts

Shortcuts are key combinations that substitute for selecting a particular menu
item. For example, pressing F1 has the same effect as choosing Product
Documentation from the Help menu. You can change the defined shortcuts or
add new ones.

Procedure 1-1 Adding or Changing a Shortcut

1 From the system prompt, move to the <reldir>/sys/configs directory.

2 Locate the .ets file that contains the operation definition of the operation you will
create a shortcut for. Check each of the following files in turn, until you find the
desired operation definition:

• std_modeler_project_operations.ets

• std_help_operations.ets

• std_edit_operations.ets

• std_shortcut_operations.ets

➥ Each of these files consists of numerous operation definitions, as shown in the

following example.

# button list for Project Editor

File format: operation list

start_operation
menu header: “File”
menu string: “Close Project”
operation: exec_builtin close_project
position: 2
shortcut: “ctrl-w”
separator “yes”
end_operation

start_operation
menu header: “File”
menu string: “Save Project”
operation: exec_builtin save_project
position: 4
shortcut: “ctrl-s”
end_operation

OPNET Modeler/Release 16.1 EI-1-29

1—System Environment

3 Use the text editor’s search capability to locate the operation you want to modify.
The text string shown as “menu string” duplicates the menu item shown in
OPNET Modeler.

4 Change the shortcut defined, or add a line for a new shortcut. Shortcut keys can
be function keys (<F1>, <F2>) or control key combinations (specified as ctrl-<key>
in the operation definition).

5 Save the changes to the file, close the text editor, and start OPNET Modeler.

6 Test the new shortcut. Ensure that the shortcut

• appears on the menu list next to the operation

• has the intended functionality

End of Procedure 1-1

Adding Optional Operations

OPNET Modeler includes code for some optional operations that are not
normally included in the menus, such as the Edit Comment Log operation. You
can add action buttons or menu items for these operations.

Procedure 1-2 Adding an Optional Operation

1 From a system prompt, move to the <reldir>/sys/configs directory.

2 In a text editor, open the std_modeler_project_operations.ets file.

3 Add operation definitions for the optional operations to the file.

For example, the definitions below create the following effects:

• User lock and comment log operations are added to the File menu. User lock is
the last item in the list; comment log is next to last. The position of the menu item
in the list is controlled by the position variable.

• Buttons for both operations appear in the button bar. The position of the button
in the button bar is determined by the order of the operation definition in the file
(for example, the first operation listed will be the left-most button).

start_operation
menu header: “File”
menu string: “Comment Log”
operation: exec_builtin open_comment_log
position: 9998
icon: comments
end_operation

start_operation
menu header: “File”
menu string: “User Lock”
operation: exec_builtin toggle_user_lock
position: 9999
icon: lock_unlock
end_operation

EI-1-30 OPNET Modeler/Release 16.1

 1—System Environment

4 Save the changes to the file, close the text editor, and start OPNET Modeler.

5 Test the new operation. Ensure that the operation

• appears on the menu list in the desired position

• appears in the button bar in the desired position

• has the intended functionality

End of Procedure 1-2

OPNET Modeler/Release 16.1 EI-1-31