The configuration can be done via a graphical configuration interface, with which you can create plots and widgets or change certain settings with a few mouse clicks, visually supported by a live preview. In addition, the configuration can also be done manually via the <modelname>.json file inside the directory: <modeldirecory>/<modelname>.json.
Just like the Base Mode, the Hypercube Mode can be started directly from GAMS Studio or the command line. For the latter, the environment variable MIRO_MODE=hcube needs to be set instead of MIRO_MODE=base. The other steps (see here) remain the same. MIRO automatically processes and adjusts your Base Mode configuration so that it will work in Hypercube Mode.
Currently, when executing Hypercube jobs locally (without GAMS Engine), your model must be prepared to work with idir. MIRO creates a local working directory for each scenario and executes your model from this directory, while referring to the main gms file via idir1.
You can debug your model by submitting a Hypercube job, navigating to the directory of your Hypercube job (C:\Users\<username>\.miro\hcube_jobs\<modelname>\1 on Windows, ~/.miro/hcube_jobs/<modelname>/1 on macOS/Linux) and executing the file jobsubmission.gms file from GAMS Studio.
The <modelname>_io.json file, for example transport_io.json, holds the GAMS/MIRO data contract and is located in the <modelname>/conf_<modelname> directory. It contains the metadata of all input and output symbols defined between the $onExternalInput
/ $offExternalInput
and $onExternalOutput
/ $offExternalOutput
tags in the corresponding GAMS model. The <modelname>_io.json file is created each time a MIRO app ist started via GAMS Studio and should not be changed. If you use the command line, please follow these steps.
The <modelname>.json file, for example transport.json, is located in the <modelname>/conf_<modelname> directory. It contains the configuration of graphics, input widgets, language and all other model-specific configurations for a MIRO app.
This file can be filled manually by the user. However, the easiest way for the configuration is the Configuration Mode.
Like the <modelname>_io.json file, the structure of this file is based on a schema with which the file is validated when a MIRO app is started.
Every time you start a MIRO app via GAMS Studio or the command line (i.e. in development mode), a gdx container is created in the directory data_<modelname>. This file contains data extracted from the GAMS model and will be stored in the MIRO database under the scenario name: default at the next start of your app.
These files are generated when starting a MIRO app in development mode. They contain the configuration and initialization steps of an app and can by used by an executable for a fast startup of MIRO. Learn more here.
We call the collection of input and output datasets that result from a particular model run and which are communicated with MIRO a scenario.
A Job describes the submission of one or more GAMS runs.
Hypercube Mode is a mode in GAMS MIRO that automatically generates scenarios. Input widgets you defined for your scalars in the Base Mode are automatically expanded in the Hypercube Mode (e.g. a slider is expanded to a slider range and a single-dropdown menu is expanded to a multi-dropdown menu etc.). This now lets you configure multiple scenarios at once. MIRO will now automatically compute the cartesian product (or, as we call it, the Hypercube) over scalars you expanded. The results can then be filtered, analyzed, downloaded etc. For more information see the section about the MIRO Hypercube Mode.
A Hypercube Job describes a set of scenarios for a particular model which MIRO generated automatically by expanding the cartesian product over all selected scalars. For more information see the section about the MIRO Hypercube Mode.
A Hypercube job tag is an identifier attached to all scenarios of a Hypercube job. Job tags can help you find scenarios of a particular Hypercube job. They can also be useful for scenario analysis. In case a model run is characterized by data that is not part of the input data specified via MIRO, job tags are important to distinguish different runs with the same input data. Suppose you are interested in finding out how sensitive your model is with regard to computing power. Thus, you run the same set of scenarios once on a high performance computing cluster and once on your local machine. As both times you used the exact same set of scenarios, MIRO can't distinguish both runs. However, you can attach different tags to the two jobs. This lets you discriminate a scenario that ran on the cluster from one that ran on your local machine. The same can be applied in case you use different solver option files.
You are in development mode when you start a MIRO app from GAMS Studio (or via the command line with the environment variable MIRO_DEV_MODE set to true). Every time you launch MIRO in development mode, your app resources (configuration, README file, data files etc.) are loaded and validated, so your application is always in sync with your current GAMS source. Once you want to share your application with other people you can deploy it. Deployed apps work with a compiled version of your resources, so they tend to launch faster. However, this also means that you can no longer change your app without deploying a new version.