Yes. You can write your own Custom Renderers in R using MIRO's R API.

yes. MIRO has an API that allows you to use e.g. charts to produce input data. We call this feature custom input widgets. These are not available in Configuration Mode, but must be implemented manually. You can find more information here.

Of course! You only have to make sure that you it is properly formatted. This means that you have to create a new sheet for every dataset and the data has to start in the cell A1 (upper left hand corner). Note further that the column headers are specified in the first row.

Yes. Besides the presented MIRO Desktop version we also develop a MIRO Server version, which will offer features like multi-application management, user access management, load balancing, rolling updates, etc.

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.

In GAMS MIRO both the log and the lst file of the current GAMS model run can be displayed. Any information about infeasibilities and unboundness is also visible here. Further checks on infeasibilities and unboundness are not performed. If a model is infeasible (or unbounded) this still leads to a normal completion of the GAMS job (unless you check the model status and trigger an abort based on an unexpected model status). A normal completion of GAMS is interpreted by GAMS MIRO as an error-free run. The view switches to the output section and will show the content of your output symbols (even if they are empty or show the infeasible solution provided by some first phase algorithm). If the GAMS model is aborted for any reason, this will also result in an abort in GAMS MIRO. A corresponding message is displayed in GAMS MIRO and no output is displayed.
Note: You can write an own report / log and integrate it into MIRO which is then visible in the GAMS interaction section. In such a custom report you can also deal with infeasibilities and unboundness.

We call any .gms file that you run with the command line option miro a model. Inside this .gms file you may include or call other files or applications, just as you would do with any GAMS program.

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.