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.
The <modelname>_io.json file, for example transport_io.json, is located in the <modelname>/conf_<modelname> directory. It contains the metadata of all input and output symbols defined between the
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.
This file is also generated when starting a MIRO app in development mode. It contains information for the startup of a MIRO app and should not be changed.
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 command line. In both cases current model-specific configuration files are written in binary format at startup. An app executable created with --mkapp=1 can access these files, so that the start up of this (non-development mode) approach is much faster.