DOME (Distributed Object-based Modeling
Environment) - User Guide
Table of Contents



1 Introduction
o 1.1 DOME Project
o 1.2 What is DOME?
o 1.3 Traditional System Design
o 1.4 Distributed, Declarative, Emergent System Design
o 1.5 Protecting Proprietary Models
o 1.6 A Product Development Service Marketplace
o 1.7 Funding
2 DOME Installation
3 Building Models
o 3.1 Starting a new model and building mathematical relations
 3.1.1 Introduction
 3.1.2 Create a new model
 3.1.3 Add parameters to the relation
 3.1.4 Change parameter names and units
 3.1.5 Add a mathematical relation
 3.1.6 Edit the causality
 3.1.7 Test the model
o 3.2 Building interfaces for the model
 3.2.1 Create a new interface
 3.2.2 Add context items to organize the interface
 3.2.3 Add parameters to the interface
o 3.3 Deploying a model
 3.3.1 Start a local DOME Server
 3.3.2 Check model files into a server



o
3.3.3
3.3.4 Figure 69
3.3.5 Select available interfaces and assign permissions
3.4 Running the model
Introduction
DOME Project
The DOME (Distributed Object-based Modeling Environment) project, initiated at the MIT
CADlab in early 1996, is focused on creating usable design tools for exploring large-scale,
systems-oriented design problems while accommodating the physics, heterogeneity, exceptions,
uncertainties, context-dependencies, and rapid change associated with real-world problems.
DOME provides a common Internet-based computational infrastructure that makes the exchange
and coordination of related parameters between different simulations a transparent process.
DOME enables a new distributed, declarative, emergent system definition process that does not
require an explicit master integration model. DOME allows design teams to rapidly create
integrated design models in a spontaneous, ad-hoc manner, allowing them to focus on
developing and analyzing design scenarios rather than being constrained by a rigidly defined
integrated design environment.
DOME's implications for changing how products and services are designed may rival how the
World-Wide Web (WWW) transformed the process of disseminating information. In contrast to
the web, which allows users to both navigate and contribute to a network of static documents,
DOME allows users to utilize, and contribute to, networks of collaborating dynamic
computational processes or simulations. In simple terms, one can imagine DOME as a
simulation-web that allows users to join models and create distributed spreadsheet-like
simulations that can span the globe. For example, an industrial designer might publish into the
DOME environment key parameters of a geometric CAD model, much like one can publish a
web page in the WWW. Then an engineer, working in another location, might subscribe to
parameters offered by the CAD model and link them to parameters in their own cost analysis
spreadsheet. Consequently, if either the industrial designer makes changes in the CAD model or
the engineer makes parameter changes in the cost model, appropriate changes are automatically
triggered in the respective software applications. DOME automatically solves relationships
between distributed simulations and synchronizes the execution of parametric models, regardless
of what software application they are implemented in. System designers need only focus on
defining integrative relationships between simulation parameters without worrying about the
order in which relationships must be executed to correctly coordinate the underlying simulations.
Further, the tacit system knowledge embodied in relationships defined by integrators is not
revealed to the disciplinary applications to which they subscribe.
In practice, large-scale integrated simulation is often deemed implausible and many researchers
have noted that difficulties arise because of the large scale, complexity, rate-of-change,
heterogeneity, and proprietary barriers associated with comprehensive product design simulation.
Since integrated analytical models are difficult to change, some researchers believe that
integrated systems can actually have negative effects by prematurely freezing the system level
architecture of a product.
While there are many issues to address, we believe that a root-cause of these difficulties is that
the method for defining and building integrated systems does not suit the product design and
product evolution process. Integrated simulation environments apply explicit procedural system
definition techniques, while design synthesis can be viewed as a distributed, emergent, system
building process. The DOME project has developed a new World-Wide-Simulation-Web
concept for synthesizing emergent computational simulations. DOME is a technological
innovation that enables an emergent model integration process in a WWW-like simulation
environment. This new integration process overcomes the difficulties long associated with
traditional efforts to create large integrated product simulations. A federated solving architecture
allows individuals to declare local relationships between sub-system parameters without
knowledge of the overall system structure.
A publication describing the DOME project received the 1998 ASME International Design
Engineering Division, Design for Manufacturing Committee IBM Best Paper Award and there is
an industry driven working group that meets quarterly to share their DOME experiences. The
information provided in the DOME Project section draws upon ideas from a number of published
academic papers (available through CADlab publications). Some key references are cited below.
Pahng, Francis; Nicola Senin, and David R. Wallace, "Distributed object-based modeling and
evaluation of design problems", Computer-aided Design 30, pp. 411-423, 1998.
Abrahamson, Shaun; David R. Wallace, Nicola Senin, and Peter Sferro, "Integrated Design in a
Service Marketplace", Computer-aided Design 32, pp. 97-107, 2000.
Borland, Nicholas; and David R. Wallace, "Environmentally-conscious Product Design: A
Collaborative Internet-based Modeling Approach", Journal of Industrial Ecology 3, 2000.
Senin, Nicola; David R. Wallace, and Nicolas Borland, "Distributed Object-based Modeling in
Design Simulation Marketplace", accepted for publication, ASME Journal of Mechanical
Design, 2000.
Wallace, David R; Elaine Yang, and Nicola Senin, "Integrated Simulation and Design
Synthesis", accepted for publication, Journal of Concurrent Engineering, 2002.
Xia, Hao-Xiang, "Toward Emergent Problem Solving on the World-Wide-Simulation Web",
MIT CADlab Report, 2002.
What is DOME?
There are three key aspects of the DOME concept and DOME3 implementation.
A new philosophy of how to build integrated networks: Just as the hypertext concept
underlies the WWW's model for building information networks, the concept of distributed,
declarative, emergent system synthesis anchors DOME as our vision for a World-WideSimulation-Web (WWSW).
An architectural representation that supports the integration philosophy: In order to realize
the hypertext concept in the WWW, a number of enabling protocols and standards were needed,
such as http, html, xml, etc. Likewise, DOME3 exploits many of these same protocols and
standards, but also includes an object representation necessary to support the WWSW and
system simulation.
A software implementation to allow the use of the integration philosophy: In order to use the
hypertext concept/WWW several applications are required: authoring tools to generate content
(e.g., DreamWeaver, FrontPage); tools to move html files to web accessible computers (e.g., FTP
applications), tools that serve html to remote users in the WWW (e.g., Apache, iis), and tools to
view/browse the content of the WWW (e.g., Safari, Netscape, Internet Explorer). DOME3
provides a precisely analogous set of software applications: build; deploy; server; and run.
Traditional System Design
There have been many efforts to develop integrated modeling environments in both academia
and industry. However, it does not appear that the process for defining integrated systems has
been questioned. Available integration tools employ a wide variety of architectures, data models
and communication technologies, but all appear to rely on some form of a consolidated explicit
description for the complete integrated system model. However, we believe that the significant
difficulties associated with scale, complexity, rate-of-change, heterogeneity, and proprietary
barriers arise because explicit system definitions are required.
We propose that large integrated simulation efforts have had limited success because the
methods used for structuring and building integrated simulations do not support the nature of
design activities and the product evolution process. There is a mismatch between the nature of
large-scale design synthesis activities and integrated simulation model building techniques.
The 'V' system engineering approach and other similar methods patterned after IDEF (Integration
DEFinition for Function Modeling) are widely used in industry for structuring integrated design
simulation environments. Starting from the top left of the V, the system is first fully defined or
scoped through a top-down, cascading decomposition of subsystem requirements. Then,
individual subsystems are constructed, individually tested, and integrated by working back up the
V. When one reaches the top right of the V, the system is complete and ready for deployment or
use.
This is an explicit, procedural process for defining and building systems. The method assumes
that the definition of the overall system and control of its execution is consolidated. The system
is usable when it is deployed in a complete form and as a result the architecture of the system is
fixed. Designers can set the values of parameters but not change the 'plumbing' of the integrated
system simulation. It is often very difficult and expensive to change the underlying system
architecture.
Although explicit procedural system definition methods can be readily applied to design or
simulation synthesis problems that are addressed by a single individual or small number of
individuals, when addressing larger products (even ones that are quite stable and mature)
organizations struggle to explicitly define and order their functional system model.
Distributed, Declarative, Emergent System Design
In contrast to traditional system definition techniques, design practice involves rapid
synthesize/test/evaluate cycles. This may occur in a bottom up, top down, or middle out fashion.
During these cycles many discoveries are made and the design or system undergoes many fluid
transformations. Many participants interact and make local decisions during the process, and the
collective result defines a complex whole.
These characteristics of design synthesis are all consistent with the properties of emergent
systems. In fact, most complex systems occurring in nature or involving human behavior are
emergent in nature. The economy is often cited as an example of an emergent system.
Managing the development of emergent systems using the almost universally-adopted, strict,
explicit, consolidated approaches is very inefficient. In contrast, effective organizations can arise
through an emergent process within appropriate environments where individuals can understand
the implications of their actions on overarching goals. Therefore, the goal of DOME is to provide
a new integrated simulation building technology that allows system simulations to emerge
throughout the design activity. The traditional difficulties associated with scale, complexity, rate
of change, heterogeneity, and proprietary information can be resolved through a distributed,
declarative, emergent simulation synthesis process that, without consolidated control, can
maintain parametric consistency between the distributed simulation models.
Distributed: control and execution of models and resources are in many locations.
Declarative: one can define local interactions with a larger system without requiring detailed
knowledge of the entire system or the system-level causal implications of the local connections
that are being made
Emergent: a system of models maintain parametric consistency without an overall system-level
controller model or meta model.
Protecting Proprietary Models
Much of the integrated modeling community has focused on data model integration. The goal is
to achieve a data model that allows everyone to interpret and reconstruct a complete
representation of the problem in different environments. In other words, integration is achieved
by exchanging models or having shared access to a common data model. While standardization
is necessary at some level, it is very difficult to achieve this at a modeling level. As such, the
most frequent strategy is to standardize on specific proprietary tools so individuals can exchange
files, often leading to problems with unnecessary rework, the inability to choose suppliers with
flexibility, and the need to share detailed proprietary models.
DOME focuses on parameter or data-type level integration by creating an infrastructure so it is
easy for people to make connections and maintain consistent states between different
simulations, regardless of the type of software tool, simulation or data model that resides behind
the services. Individuals can provide Internet accessible service interfaces to simulations while
maintaining full ownership of the underlying models. When necessary, entire files or data
models can also be bundled as DOME parameters.
A Product Development Service Marketplace
DOME is a modeling infrastructure intended to create a global community, or marketplace, of
individuals offering access to simulation services related to their own specialties, much as the
WWW has enabled world-wide access to information. Within the envisioned simulation
marketplace, it will be possible to quickly create and holistically assess technology systems from
many viewpoints, allowing individuals to design and understand complex technology systems.
Participants and product development organizations are empowered to publish their geometric
design, CAE, manufacturing, or marketing capabilities as live services that are operable over the
Internet. Product developers, small or large, can subscribe to and flexibly inter-relate these
services to embody a distributed product development organization, while simultaneously
creating system models that allow the prediction and analysis of integrated product performance.
We believe that product development services will become commodities, much like many
component-level products are today. It will be possible to rapidly interchange equivalent design
service providers so that the development of the product and the definition of the product
development organization become part of the same process. Computer-aided design tools will
evolve to facilitate the publishing of live design services.
Funding
The DOME project is grateful for the research funding provided by its sponsors. The initial seeds
funds for the project were provided in 1996 by the Alliance for Global Sustainability (AGS) and
the Leaders for Manufacturing Program. Ford Motor Company and the Center for Innovation in
Product Development have been very strong supporters since 1998. Additional support has been
received from LG Electronics, and Bose.
DOME Installation
Follow the below instructions or refer to the following flowchart
Open a Terminal window (Mac/Linux) or a Command Prompt or PowerShell window
(Windows).
The kernel will run on any platform supporting Java Virtual Machine (JVM) version 1.6.0.45 or
higher.
You can test the version of Java with the command:
$ java -version (Mac/Linux)
> java --version (Windows)
If the version number is lower than 1.6.0.45, Windows & Mac users, please download a new
Java (TM) SE Runtime Environment from https://java.com/en/download/. Linux users can install
the openjdk with a command such as "sudo apt-get install openjdk-7-jdk" (tailored to your
distribution).
Mac Issue: Does not run from the directory. Mac runs from the home directory. The .sh path
assumes you start in BIN directory. <Not sure what to say here – we need to fix the script>
For Windows OS users, if you upgrade the Java version, change the java_home and
CLASSPATH in the System Environment variables to point to the updated java folder, logout,
and log back in. To change the system environment variables, follow the below steps. From the
desktop, right-click My Computer and click Properties. In the Advanced section, click the
Environment Variables button.
Once you are sure about having java 1.6.0.45 or higher do the following:
1. Download the latest file from Amazon simple store service (Amazon S3) by copying the
following link and pasting it in your browser: http://dmc-domedistribution.s3.amazonaws.com/index.html
2. Save the zip file on your machine. This step might take several minutes.
3. Unzip/extract the file in Windows. Mac will download and extract the files
automatically. In Linux, execute the following commands:
cd ~/Downloads
mkdir ~/dome
# this directory placement is convenient, but not necessary
unzip domeInstall-[date].zip -d ~/dome
# if unzip is not already installed: $ sudo apt-get install unzip
4. Open the folder in a graphical environment, or navigate to it in a terminal ($ cd ~/dome).
You will see four directories: bin, client, dome3, and server.
5. Go into the bin directory ($ cd bin).
6. Launch the appropriate file:
1.
1.
2.
3.
4.
5.
Windows: DOMEClient.bat
Mac: DOMEClient.sh (permissions/path might be wrong)
Linux: $ sudo sh DomeClient.sh
Click Run.
When the DOME3 Copyright pop up opens, accept the Terms and Conditions.
At this point, the DOME Client will open. Do not close the Terminal, Command Prompt, or
PowerShell window.
The DOME Client is the thin toolbar shown in Figure 1. At the right of the bar you see Build to
indicate the mode. The four modes are Build, Deploy, Run, and Server. The rest of the tool bar
changes automatically to reflect the mode.
Figure 1. DOME Window
Build is used to build a model, enter variables, and build the interface.
Deploy is used to deploy a model interface to the server so that other users can access it.
Run is used to run a model interface found on the server.
Server is used to manage the server.
Building Models
Starting a new model and building mathematical relations
You will learn how to:






Create a new model;
Add parameters to the relation;
Change parameter names and units;
Add a mathematical relation;
Edit the causality;
Test the model.
Introduction
We will build a simple DOME model to compute velocity given initial velocity, acceleration,
and time using the equation v = v0 + a*t.
The following client will appear when you start DOME (Figure 2). We call it the DOME
Window.
Figure 2 DOME Window
As mentioned before, the DOME toolbar tabs will change according to the active mode. There
are four options.
Click on the mode dropdown menu at the top right and the four modes will appear (Figure 3).
Figure 3
Build is used to build a model, enter variables, and build the interface.
Deploy is used to deploy a model interface to the server so that other users can access it.
Run is used to run a model interface found on the server.
Server is used to manage the server.
Create a new model
To build a new model, you must be in build mode.
Click on Build > New Model on the left side (Figure 4).
Figure 4
You can choose from many different types of models. For this example, click on Dome Model
(Figure 5). A Dome Model allows you to execute a Python script. In this tutorial we will build a
Dome Model.
Figure 5
The DOME window will change to show more options and a model window appears with the
default name Dome Model (Figure 6).
Figure 6. Model Window
While the DOME window is a fixed menu bar, the Model Window size can be changed.
Change the name to the model name you want, we chose “Velocity Dome Model”. Hit
Enter/Return to update the name (Figure 7). The name field will change from yellow to white to
show the change has been accepted. Save the model to save the new name.
Figure 7
Now we will add a relation to the model. Click Add in the DOME window (Figure 8).
Figure 8
Click on Procedural Relation (Figure 9).
Figure 9
A Procedural Relation will appear inside the model window (Figure 10).
Figure 10
Double click on the name and change the name of the relation to something that reflects the
model you are building. We chose “Velocity Relation” (Figure 11). The name will be updated
when you press enter or click elsewhere in the window, again changing color from yellow to
white. Save the model to save the new name.
Figure 11
Note that changing names will update them but not save them. You can save the model at any
time. From the DOME window, click on DOME Model > Save (Figure 12), and follow the
instructions. A .dml file and a folder will be created.
Figure 12
Add parameters to the relation
From the model window add four Real parameters (data with the “real” type). These will
represent velocity, initial velocity, acceleration and time in the model.
To do this, click on the yellow triangle to the left of "Velocity Relation" to expand the relation (if
you just created it, it's already expanded), and then expand the Inputs and Outputs folders as well
(they will be empty). Your window should look like Figure 13 when all are expanded. From the
DOME window choose Add > Real four times to add four Reals to the relation (Figure 13). The
parameters will be added under Inputs. In a later step you will tell the model which are outputs
by defining the relation’s causality; right now, with no causality defined, the model considers
them all to be inputs.
Figure 13
The model with the four Real parameters is shown in Figure 14.
Figure 14
Change parameter names and units
Double click on the name of the parameters to change them to something meaningful for the
model you are building. In this case use v for velocity, v0 for initial velocity, a for acceleration
and t for time.
Click on “no unit” and then “change unit” to choose the correct units for each parameter. A unit
chooser window opens (Figure 15).
Figure 15
Choose a dimension in the left column and then a unit in the right column (Figure 16). For more
information on how to use the unit chooser window see the special topic section on Units. For
this example, select “meter per second” for the velocities, “second” for the time, and “meter per
second square” for acceleration. Note the "All" on the bottom right. It is used to switch from all
units to just metric units.
Figure 16
You can use units from different standards in one model as long as they have the same base
dimensions (such as choosing “meter per second” and “foot per minute” for two velocities);
DOME will convert internally when the model is run. Once the Units are chosen they are
updated (Figure 17). Remember to save frequently.
Figure 17
Add a mathematical relation
Double click on the red and yellow cube icon to the left of “Velocity Relation” that represents
your procedural relation (
) (Figure 18).
Figure 18
The relation icon will open (
) and a relation window will appear (Figure 19).
Figure 19
In the body editor write
v = v0 + a*t
as shown in Figure 20. The variables will turn blue to indicate that a matching input or output
parameter exists.
The body editor follows Python (need to specify which version) syntax. For more detail, see the
special topic section on Relation Body Editor, or reference the syntax in the Python
documentation at https://docs.python.org/2/library/index.html.
Figure 20
Edit the causality
Click on the causality tab inside the relation window (Figure 21).
Figure 21
The view will switch to show the causality (Figure 22).
Figure 22
Click “Edit causality information” at the bottom right (Figure 23).
Figure 23
The Edit Causality Information window will open (Figure 24).
Figure 24
In the Edit Causality Window, check boxes where the parameter listed in the row is dependent
on the parameter in the column.
In this case, v depends on v0, a and t, so check only the three squares in the first row (Figure 25).
Figure 25
Click ok to accept (Figure 26).
Figure 26
The causality Information Window closes, and the selected causality relations are shown in the
relation window (Figure 27).
Figure 27
The causality is how you define your parameters to DOME. Based on your causality matrix,
DOME will determine which parameters are the inputs and which are the outputs of your system.
Close the Causality Information Window clicking on the X. The velocity relation will show
that v0, a and t are input parameters and v has moved to the Outputs folder (Figure 28).
Figure 28
Test the model
If you have closed the Velocity Relation window, reopen it by double-clicking on the icon left of
Velocity Relation in the Model window.
Go to the interface parameters tab in the relation window (Figure 29). You can move the divider
bar up and down to increase the viewing size.
Figure 29
Change the values of the inputs in the velocity relation window. This example set v0=1, a=2, and
t=3 (Figure 30). To do this click on the value (default 0.0) and enter a new number.
Figure 30
In the DOME Window, click Edit procedural relation> Test (Figure 31).
Figure 31
If the model is set up properly, the model will execute the Python script with the variables equal
to the value column. The value of the output parameter(s) will then display the values returned
by the script. If you used the values suggested earlier, the model will return v=7 (Figure 32).
Testing the model also confirms that you have chosen units with the correct dimensions; if not,
the model will give a unit error.
Figure 32
You may wish to close the procedural relation window before continuing.
Building interfaces for the model
Interfaces are the exposed views of a model made available through the server to users in Run
mode. You will learn how to:



Create a new interface;
Add context items to organize the interface;
Add parameters to the interface.
Create a new interface
First, close the velocity relation window and click somewhere in the velocity model window to
bring it into the foreground. The menu options in the DOME window will change.
Click on Tools (Figure 33).
Figure 33
Choose Interfaces (Figure 34).
Figure 34
The Interfaces window will appear. It has been pre-populated with a Default interface (Figure
35).
Figure 35
From the DOME window click Interfaces > New (Figure 36).
Figure 36
A new DOME Model Interface appears (Figure 37).
Figure 37. Interface Window
Double click on the name to change it to something meaningful, such as Velocity Model
Interface (Figure 38).
Figure 38
Add context items to organize the interface
Click to the arrow next to the name (
) to expand the interface (Figure 39).
Figure 39
Double click the book icon (
) next to the name of the interface (Figure 40).
Figure 40
The velocity model interface window appears (Figure 41).
Figure 41
Click Add > Context to add a context item to the interface (Figure 42). A context organizes your
interfaces, analogous to a folder in a file system.
Figure 42
A new context item appears in the interface window (Figure 43).
Figure 43
Double click on the context item to change its name to Input Dimensions (Figure 44).
Figure 44
Collapse the Input Dimensions item (the triangle icon should point right), and add a second
context item named Output Dimensions. Collapsing the first ensures that the new context won't
be added inside it instead of at the highest level. Click Add > Context (Figure 39) and a second
context item will appear (Figure 45).
Figure 45
Double click on the name to rename the second item Output Dimensions (Figure 46).
Figure 46
Add parameters to the interface
Next, the interface needs to be linked to the model parameters. With the model window in the
foreground, select the three input parameters, holding Ctrl to multi-select (Figure 47).
Figure 47
In the DOME window select Edit Definition > Copy (Figure 48).
Figure 48
Bring the interface window to the foreground (Figure 49).
Figure 49
Click the yellow arrow to expand Input Dimensions, and then select the name Input Dimensions
(Figure 50).
Figure 50
From the DOME window click Add > Add and Map > Last selection (Figure 51), which will
add the parameters to the Input Dimensions context item (Figure 52).
Figure 51
Figure 52
Repeat these steps for the output parameter. With the model window in the foreground select the
output parameter, v (Figure 53).
Figure 53
In the DOME window select Edit Definition > Copy (Figure 48). Bring the interface window in
the foreground (Figure 49). Expand the Output Dimensions context item (Figure 54). And click
on Output Dimensions
Figure 54
From the DOME window Click Add > Add and Map > Last selection (Figure 51) to add the
parameter.
Click Dome Model > Save to save the model. The interface window may be closed.
At this point you have built a model and you have created an interface for it.
Deploying a model
When working in build mode, DOME models reside in one's local file space—not on a DOME
server—and thus they are not available for use by others. The model needs to be deployed to a
server to be used by others.
The tutorial is written assuming that you will be logging into a server running locally on the
same machine as your client application. Here you will move the model and interface files that
you saved to a server where they can be executed by remote users.
You will learn how to:



Check model files into a server using a deploy mode wizard;
Select which interfaces will be available to users;
Assign permissions.
Before starting this process make sure that the DOME Server is running.
Start a local DOME Server
If you do not have a remote DOME server available to log in to, you can set up a local server for
testing purposes.
Open a new terminal window (if using a command line interface) or explorer window, and
navigate to the dome/bin directory where DomeClient.sh and DomeClient.bat were located.
Windows: launch DomeServer.bat
Mac/Linux: launch DomeServer.sh in a graphical interface, or "$ sudo sh DomeServer.sh".
If you launch the file from a terminal, you will see various output appear; one of the last lines
will be "DomeServer started on port [number] at [timestamp]". Note the port number to log in
with later.
Check model files into a server
In the DOME window select Deploy in the mode menu at right (Figure 55).
Figure 55. DOME Window
Choose Deploy > Model (Figure 56).
Figure 56
A Deploy Model window will open (Figure 57).
Figure 57. Deploy Model Window
Click on login (Figure 58).
Figure 58
A login to DOME Server window will open (Figure 59).
Figure 59
In the Login to DOME Server window, enter your username, password and server name and then
click login (Figure 60). If you started a local server earlier, your credentials will be:
user name: ceed
password: ceed
server: localhost:[port number]
After you connect for the first time, your credentials will be stored.
Figure 60
After logging in, the Login to DOME Server window disappears and information about the
server is shown in the Deploy model window (Figure 61). Click next on the bottom right.
Figure 61
The window will change to Figure 62. Leave the default option, “deploy as new model,”
selected. Click on browse on the right.
Figure 62
Now a window will open and you will navigate to find the model you want to deploy (Figure
63).
Figure 63
Once you find the model you want to deploy, select it and click Open (Figure 64).
Figure 64
Now the name and location of the model appears in the Deploy model window (Figure 65). Click
next.
Figure 65
At this point you will choose where on the server to store your model (Figure 66).
Figure 66
To create a new folder, click on the name of the parent folder and then click on the “+” sign in
the bottom right corner (Figure 67).
Figure 67
At this point the new folder windows appear and you chose the name of the folder. In this
example the name of the folder is ForTutorial (figure 68).
Figure 68
Navigate to that folder and click next.
Figure 69
Select available interfaces and assign permissions
The next screen in the wizard allows you to set permissions (Figure 69). For more details about
permissions, see the special topic section on permissions.
Figure 69
Choose the permissions you want for this model and click next (Figure 70).
Figure 70
In the “available” column, select which interface(s) you want to make available.This example
selected the Velocity Model Interface (Figure 71). Click next.
Figure 72
The next screen allows you to set permissions specific to each interface (Figure 73). For more
information on setting permissions, read the related special topic.
Figure 73
Now a summary window will appear (Figure 74). Click deploy.
Figure 74
DOME will confirm the deployment was successful (Figure 75).
Figure 75
Now that the model has been deployed to the server, its selected interface(s) are available to
others.
Running the model
Now you will learn how to


Connect to a model;
Run a model.
From the DOME window choose Run mode in the right menu (Figure 76).
Figure 76
Click on Run > New Window, upper left, Figure 77.
Figure 77
A Browser window opens. Click login at the top right (Figure 78).
Figure 78
A Login to DOME Server window opens (Figure 79). Either select a stored set of credentials or
enter new credentials and then click “login.”
Figure 79
The server folders appear in the Browser window (Figure 80). Browse to the model you want to
run.
Figure 80
Click on the yellow rectangle to the left of the model name to expand it (Figure 81).
Figure 81
Double click on the book icon next to the interface you want to open (Figure 82).
Figure 82
A new interface window opens, showing the Input Dimensions and Output Dimensions context
items. Expand these using the yellow triangles (Figure 83).
Figure 83
Parameters with a green background are consistent between the server and the model, but the
model has not been run yet. Fields that will update when the model runs have a red background.
Fields displayed with a yellow background have been updated locally, but not yet submitted to
the server. The fields will become white when the model has run (Figure 84).
Figure 84
For example, enter v0=6, a=1, t=3 (Figure 85). Click submit.
Figure 85
When the model has finished running, the value of v changes to reflect the calculated value, v=9
(Figure 86). The values and background colors will update as the model runs, so in more
complex models, changes may appear over time.
Figure 86
Continue with the next article in the DOME User Guide series: How to build Dome Integrated
Models.
Articles in this series:
DOME (Distributed Object-based Modeling Environment) - User Guide
How to build Dome Integrated Models