executecommands need to be executed with absolute paths instead of relative ones. GAMS MIRO is providing you the path to your model via idir1. This means, in order to import e.g. an Excel file test.xlsx, GDXXRW needs to be called like this: $call gdxxrw i=%gams.idir1%test.xlsx. Alternatively, you can also use absolute paths (e.g. via
$setNames "%gams.input%" fp fn fe(see here).
Graphics, tables as well as other customization options are specified via the <modelname>.json file inside the directory: <modeldirecory>/<modelname>.json. In order to generate the <modelname>.json file you can use our Configuration Generator.
The <modelname>_io.json file, for example transport_io.json, is located in the <modelname>/conf 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 or the command line and should not be changed.
The <modelname>.json file, for example transport.json, is located in the <modelname>/conf directory. It contains the configuration of graphics, input widgets, language and all other model-specific configurations for a MIRO app.
This file has to be filled manually by the user.
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 generated when starting a MIRO app in development mode. It contains configuration data and should not be changed.
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.
An app of a GAMS model can be started via command line or via GAMS Studio (e.g. gams transport.gms miro=launch). However, there is the possibility to create an executable file for a GAMS MIRO app. By adding the double-dash parameter --mkapp=1 to the GAMS call, a cmd file (Windows) / app file (MacOS) is created which can execute the app. 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 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.