Graphical User Interface

Suggest edits
Documentation > Documentation


1 - Overview
2 - Starting a project
3 - File Management
4 - Run and monitor executions
5 - Authentications
6 - Plugins

Overview 🔗

This GUI is an advanced editor for OpenMOLE experiment description through OpenMOLE scripts. It allows editing, managing and running them. The way to write these experiments is fully explained in the main documentation of OpenMOLE. We focus here on the way to manage them in the application.
In the OpenMOLE GUI, you can upload and edit files, run and monitor experiments, and store authentication credentials for distributed computation. The application runs in a browser (Firefox or Chrome). The first time you run it, you are asked for a password to encrypt your settings (server port, authentication credentials, etc). Your settings data (so not your projects, which are never wiped out) are preserved so long as your password do not change. For now, the OpenMOLE GUI looks like a web application but still runs as a heavy client one.

Starting a project 🔗

Clicking on the main red button New project in the menu bar offers 3 choices:

Empty project 🔗

Selecting this option creates a new script file called newProject.oms in the current folder and open the (empty) file for edition.

From Market Place 🔗

Selecting this option pops up a dialog box containing all the running projects contained in our Market Place. The Market Place is a collection of projects built by users which offers different aspects of experiments that can be run on the OpenMOLE platform with a large variety of programming codes, exploration methods. The sources can be found here. Just select one of the Market entries and click on the Download button to import it in the current folder.

From existing model sources 🔗

The model wizard is a tool designed to quickly import your model. It both uploads your model archive and prepares the OpenMOLE script for you. The wizard automatically distinguishes your model's programming language among JVM, NetLogo or native codes. Then it detects the potential inputs and outputs. For each input/output, the wizard generates a variable with a relevant name if possible. At the end of the import process, you should be able to run your script without having to do anything else!
To import your model, click on the Your Model button. A dialog box pops up where you can set your model path. The system should now display the programming language, a list of detected inputs/outputs and the command to launch your code. In most cases, you are almost done. Just press the Build button at the bottom: the wizard dialog box disappears and the OpenMOLE script is generated in your workDirectory with your uploaded code! However, you can also make some modifications to input/output names, or launching commands before building the script. For each input/output, three actions can be triggered using the icons located on the same line:
  • removes the current input/output
  • duplicates the current input/output, so that it is both defined as input and output
  • or switches an input to output and vice-versa.
The launching command uses the names of the previously defined input/output variables. It is reactive: if the name of the input/output changes, the launching command is updated with the corresponding name. For the native codes (C, C++, Python, R, ...), the following syntax is required (automatically used): ${}.
The NetLogo applications working with the .nls extension should be uploaded as a folder.

File Management 🔗

The OpenMOLE application essentially handles files: your model files, your model inputs our outputs, and the OpenMOLE scripts, where you describe your experiment.
We distinguish multiple kinds of resources:
  • oms (for Open Mole Script) is a file describing an OpenMOLE experiment according to the OpenMOLE language
  • external code used in OpenMOLE scripts. Codes written in some specific programming languages (Java, Scala, NetLogo, R, Python, ...) can be edited in the application. However, they will not be compiled.
  • other external resources used as input for a model are editable in the application (CSV files, text files, ...), while binary files like images cannot be modified.
These files are managed in a file system located in the left sidebar. This side bar offers basic tools for managing files. The current directory is shown at the top in the folder navigation area. When the folder hierarchy is too deep to fit in the bar, it will be replaced by "...". Clicking on one folder of the stack sets it as the current folder. In the image above, the current directory is for example Pi Computation.
The tool area at the top concerns the current folder and provides:
  • filtering this folder by number of entries or by names. It is especially recommended for folders containing a large number of files.
  • file or folder creation in the current folder.
  • copying files. Clicking this icon make entering in a blue multi-selection mode. Each file selected turns to green. The copy button on top permits to copy all of them. Then a paste button appears and just waits for being pressed from any other folder you go to.
  • deleting files. Clicking this icon make entering in a blue multi-selection mode. Each selected file turns to green. The red Delete button on top allows to wipe them out.
  • checking for plugins in the current folder.
  • uploading a file from your local machine to the current folder
  • refreshing the content of the current folder
Then, each file on each line has a settings button allowing to clone the current file, @b{download} it, edit its name or remove it. Other actions are available depending on the context (ie the file extension):
  • run for .oms file in order to run file without editing it.
  • extract for archives in order to produce a directory from an archive file.
  • to OMS for code source potentially carried by a Task (.jar, nlogo, .py, etc). It starts the model wizard.

Run and monitor executions 🔗

When a .oms file is edited, a Run button appears in the top right corner to start the execution of the workflow. Once the workflow has been started, the execution panel appears, listing information for each execution on a separate row. At any time, this execution panel can be closed (without aborting the current runs), and re-opened by clicking on the running icon The different statuses of the executions are:
  • preparing: the execution is getting ready before execution starts
  • running: some jobs are running
  • success: the execution has successfully finished
  • failed: the execution has failed, click on this state to see the errors
  • canceled: the execution has been canceled (by means of the button)

Authentications 🔗

In OpenMOLE, the computation load can be delegated to remote environments. When clicking on the authentication icon, a panel appears with the list (initially empty) of all the defined authentications.
To add one authentication, click on the @b{New} button. The currently supported authentications are:
  • SSH authentication with login and password (any environment accessed by means of SSH).
    Set the remote host name and your login on this machine (for example john on, as well as your password. Once saved, the authentication will be added to your list (by example:
  • SSH authentication with SSH private key (any environment accessed by means of SSH).
    Enter the same three settings as for the SSH Password. Now add your SSH private key by clicking on No certificate. A random name will be associated to your key. Once saved, the authentication will be added to your list (by example:
  • Grid certificate (.p12) for Grid Computing
    It only requires your EGI certificate file and the associated password. Click on No certificate to select your certificate file. It will be renamed to egi.p12. Note that only one EGI certificate is required (you will not need any other one!)
An authentication can be removed by clicking on the trash bin icon. An existing authentication can also be edited by clicking on the name of an authentication in the list.
Each time an authentication is added, a check is made on the mentioned environment (for the EGI ones, a list of VOs to be checked can be set in the EGI authentication settings). If it fails, a red label appears. When clicking on it, the error stack appears.

Plugins 🔗

New features can be dynamically inserted in the OpenMOLE platform through plugins. Advanced users build their own plugins to express concepts that might not be present (yet) in OpenMOLE. In OpenMOLE, plugins take the form of jar files. JVM based models can also be provided as plugins. The way to build plugins in OpenMOLE is fully described here
To add a plugin, open the plugin management panel. You can upload a new plugin by clicking on the blue top right-hand corner and selecting the corresponding jar file. Once uploaded, the plugin appears in the list.