Changes made in the configuration are only effective after a restart of the MIRO application.
Configuration
Introduction
In this section you will learn how to customize GAMS MIRO. As you saw previously when creating your first app, MIRO launches without any further configuration. However, you will find that there are a lot of configuration possibilities to adapt MIRO to your specific model.
The configuration is 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 a JSON file. In fact, all the graphical Configuration Mode does is create this JSON file.
The Configuration Mode
This chapter shows how to configure MIRO using the graphical interface. For those who feel more comfortable writing JSON, section Configuration via JSON shows how to configure a MIRO app without using the graphical interface. However, we strongly recommend to use the Configuration Mode, especially when you just started using GAMS MIRO.
The Configuration Mode is directly accessible via GAMS Studio:
In order to launch the Configuration Mode via the command line, the environment variable MIRO_MODE=config needs to be set instead of MIRO_MODE=base. The other steps (see here) remain the same.
After starting, the following screen appears:
Visually, this mode is very similar to a classic MIRO app. The tabs on the left side lead to the following categories:
Note:
General settings
As the name suggests, general options can be set in this section (click on an item for more information).
General
Application title
This option allows you to customize the title of the application that is displayed in the browser window. If a $title has been defined in the GAMS model, this is used by default.
Color theme to use
Allows you to choose between MIRO light and dark mode as well as the dynamic adaptation of the theme based on the user's system settings.
Light mode:
Dark mode:
Show log file in UI
Determine whether the GAMS log file is displayed in the section GAMS interaction or not.
Show listing (lst) file in UI
Use custom MIRO log
You can write a custom MIRO log file and display this in MIRO. Per default, the GAMS log and listing (lst) files are visible in the GAMS interaction section. Besides these files generated by GAMS you can also write your own log (e.g. with the Put Writing Facility). If you already use your own report in your GAMS model, you can easily integrate it into MIRO with this option.
All you have to do is specify the name of this file. The file must be a text file and needs to be located in the MIRO working directory at the end of the model run in order to be included.
Tip:
In the general settings you can choose whether you want to see the GAMS log and/or the listing (lst) file in MIRO at all.
Example:
In this example we extend our transport model with a few
lines of code for creating a report
transport.dat:
File log /transport.dat/;
put log;
put '--------------------------------'/;
put ' Report'/;
put '--------------------------------'/;
put / / 'Transportation Model parameters' / /
'Freight cost ', f,
@1#6, 'Plant capacity'/;
loop(i, put @3, i.tl, @15, a(i)/);
put /'Market demand'/;
loop(j, put @3, j.tl, @15, b(j)/);
put / / 'Transportation Model Results' / / ;
loop((i,j), put i.tl, @12, j.tl, @24, x.l(i,j):8:4 /);
Now we want to integrate it into MIRO. In the Configuration Mode we specify the name of the report file in the general settings:
The next time the model is solved, this report is displayed in the GAMS interaction section in MIRO:
Note:
Be careful with logs that are not written with every GAMS run, but only if, for example, a data test in the model fails. MIRO does not know if a log belongs to the current or an earlier run. If a log file was specified, MIRO looks into the working directory and includes this file after each GAMS run.
Data validation
The MIRO log is particularly suitable for the validation of input data. Checking the consistency of input data and providing reports when inconsistencies are found is a critical factor in avoiding end-user frustration.
If a certain syntax is followed in the MIRO log, data found to be invalid can be marked directly above the respective input data sheet in MIRO:
This works as follows:
In the Pickstock model we create, as in the previous
transport example, a reporting file. We want to inform
the user when we detect invalid price data. We classify
a price as incorrect if it is negative, i.e. < 0.
Since the data validation should take place before
solving the model, the code must be placed before the
solve statement. If we find inconsistent data, we abort
the execution with an error message.
* input validation
set error01(date, symbol);
error01(date, symbol) = price(date, symbol) < 0;
file log / miro.log /;
put '------------------------------------'/;
put ' Data validation'/;
put '------------------------------------'/;
if(card(error01),
put log 'price:: No negative prices allowed!'/;
loop(error01(date, symbol),
put log / ' Symbol ' symbol.tl:4 ' has negative price at the date: ' date.tl:0;
);
abort "Data errors detected."
);
putclose log;
If the data validation log is integrated in MIRO, the following happens: If you now have a negative price in the input data and click solve, this negative price is detected in the data validation and the model run is aborted. Instead of remaining in the GAMS interaction section, MIRO now switches the view and displays the input table with the first validation error detected. The corresponding message specified in the log file is also displayed (see picture above).
The MIRO log file also displays further information about the incorrect data if defined accordingly:
This way, incorrect data can be quickly found and corrected by the user, before executing an expensive computation.
The syntax that must be used for MIRO to jump directly to the table with the incorrect data is as follows:
'symbolname:: Error message'
In the example above this was:
'price:: No negative prices allowed!'
The name of the symbol whose data is incorrect, followed by two colons, signals MIRO to jump to the table of the corresponding symbol if the model run is aborted. The specified error message that follows the colons is then displayed above the table.
Default scenario comparison mode
Generate graphs for each input sheet automatically (pivot tool)
Number of decimal places used for rounding numerical values
Symbol display
Symbols that should not be displayed but can be used in graphs etc.
Scalars that should not be displayed in the scalars table but can be used in graphs etc.
For some charts it may be desired to use additional (scalar) information. In the following example from the Pickstock model, the scalar output value "end of training phase" was integrated into the chart to mark the end of the training phase:
In this case you may not want to see the value in the scalars table, but it is required for this chart. With this option you can do exactly that, i.e. use scalar values in charts that are otherwise not visible in MIRO.
Should all input widgets (slider, dropdown menu, etc.) be aggregated on a single tab?
Logo
Upload a custom logo for your MIRO app: png/jpg file (best ratio: 4,6:1).
This option allows you to use your own logo for your MIRO application, which is displayed in the upper left corner.
README file
Create an individual start page
You have the possibility to integrate a README file into the MIRO application. Its content is displayed in the input section in the first tab and is therefore the first thing the user sees after starting the application. This tab can be used by the developer to introduce and explain the MIRO application or the underlying GAMS model before the user starts working with it.
Usage:
The readme file must be a
Markdown
or HTML document which is located in the model
directory. The README option must be activated in the
Configuration Mode. Three options are available:
-
README tab title (mandatory)
With this option you can customize the title of the README tab in the input section. Default: README -
README file name (mandatory)
With this option you specify the name of the readme file that you want to display (minimum 4 characters). -
Enable mathematical typesetting?
(optional)
In case you want to use mathematical notation in your README file, activate this checkbox. You can use inline math by wrapping your equations between $ signs. To render the equation centered on its own line, use two dollar signs: $$.Example:
A list of all TeX functions supported by MIRO can be found here.
This integral $\def\f#1{f(#1)} \f{x} = \int_{-\infty}^\infty\hat \f\xi\,e^{2 \pi i \xi x}\,d\xi$ is rendered inline. is rendered as: This integral $\def\f#1{f(#1)} \f{x} = \int_{-\infty}^\infty\hat \f\xi\,e^{2 \pi i \xi x}\,d\xi$ is rendered inline.
The readme file can be created or edited directly in Configuration Mode:
Note:
If you want to include images in your readme file, they must be located in the folder static_<modelname> in your model directory. In the Markdown/HTML file, the path of the images used must be pre-fixed with "static_<modelname>".
Symbol configuration: Naming, ordering, grouping
Naming
Under the heading Naming, the names of the GAMS symbols displayed in MIRO can be adapted. This includes the labels of the tabs displayed for each symbol as well as the table column headers.
-
Specify symbol alias:
Specification of the labels of the symbol tabs.
-
Specify column headers:
To adjust a column header, the corresponding element must be deleted and replaced with a new one.
Ordering
Here you can adjust the tab order in which the symbols are to be displayed in MIRO. To do this, simply drag and drop the symbols into the desired order.
Note:
If symbols have been grouped using the grouping option, only the individual symbols and not the configured groups are displayed here. If you want to change the position of a group, drag and drop the symbols that belong to this group to the desired position.
Tab grouping
Multiple tabs of input symbols (or output symbols) can be grouped together. All symbols in a group are either displayed in a separate tab or side by side on the same tab.
Input widgets can also be
grouped. The order of the widgets can be changed
directly when specifying the group members.
Note that adding or removing widgets does not
automatically update the dropdown menus for selecting
group members. You must restart the Configuration Mode
for these changes to be reflected here.
Example:
For the input data of the transport model, one might
want to group the symbols with geodata together:
Which is displayed in the MIRO App as follows:
Use output data as input data
In some situations you may want to run a model and use the results of the run as input for the next run. Such an iterative process is possible by creating a link between the output and input symbol. By doing so, input data for a symbol ("target") can be populated from an output sheet ("source").
Populating an input table from the linked dataset can be
initiated by clicking the
button.
The following rules must be observed when configuring symbol links:
- The source symbol needs to be an output symbol
- The number of dimensions of "source" and "target" symbol must be identical
- The header types (string / numeric) of linked symbols need to be identical
- Neither "source" nor "target" may be a table in which scalar values are grouped. This includes the input scalars table, the output scalars table and the table in which scalar variables and equations are summarized.
- An output dataset can only link to a single input table
-
An input table can be populated by different output
datasets
Scenario & data
Activate local data upload module?
If enabled, scenario data can be loaded via local files.
Use a default scenario that will be loaded on startup?
Include a metadata sheet in the Excel file (when exporting a scenario)?
The metatdata sheet contains information about the user name, the scenario name and the time the scenario was created.
Include empty sheets in the Excel file?
Should users be allowed to add attachments to scenarios?
Duration the GAMS log and lst files are stored in the database (in days)
Output attachments
Computation
Allow access to the temporary directory?
This option specifies whether all temporarily created
files of the model run (like solution reports or the
lst and
log files) can be accessed by
the user. If set to true, the files can be downloaded
individually or as a ZIP archive with a click on the
button.
Specify extra command line arguments that GAMS will be called with
Activate Hypercube module?
Analysis scripts
MIRO allows you to run custom analysis scripts. These scripts have to generate HTML or Markdown output which will be displayed in the interface once the script finished. Scripts need to be placed in a folder called scripts_<modelname>; this is also where MIRO executes them (important when you use relative paths in your script).
Note:
All software needed to run the script must be installed on the client's machine and added to the PATH, as it is not part of a MIRO application.
Base Mode
Batch analysis
Custom scripts can be used to run analyses on multiple scenarios at once from the Batch Load module. Let's consider the example that comes with the pickstock model: a Jupyter Notebook that tries to answer high-level questions like "How many training days should I use" and "How many stocks should I choose". You can find this script in scripts_pickstock/hcube_analysis.ipynb. First, we have to tell MIRO that we want to use a custom analysis script. The Configuration Mode allows us to set everything up:
Each script has to have a unique identifier. The identifier is only used internally and should not be changed. What's displayed in the user interface is the script alias. The command to run is "jupyter", because we want to run a Jupyter Notebook. Note that in order for this to work, Jupyter needs to be installed on the client's machine and added to the PATH.
Info:
For more information on how to set up the Python environment required to run this example and make MIRO aware of it, see here.
Jupyter allows us to run and convert our notebook to HTML. In order to do so, we specify the relevant arguments. The resulting call would be: jupyter nbconvert --to html --execute hcube_analysis.ipynb.
Now that we set everything up, we can start testing our script. We select a few scenarios that we want to analyze, and click on "Analyze". The following dialog opens:
We select the script we want to run and click on "Start script". MIRO will now generate GDX containers with the data for each scenario you selected to be analyzed and store them inside: scripts_<modelname>. Additionally, MIRO writes a file: hcube_file_names.txt. This file simply lists the filenames of the gdx containers to be analyzed (separated by a newline). Once the script finished, the results are read by MIRO and displayed:
Configure tables
In this section you can customize the general configuration of input and output tables (global settings) as well as the individual settings of multi-dimensional symbol tables.
Input tables (global settings)
Height of input tables (in px)
Restrict editing of tables? If activated, tables can not be modified by the user.
Default column stretching
Width of a single (non-streched) column.
Enable manual column resizing
Enables/disables the manual setting of the column width by the user.
Enable table context menu (accessible via right mouse click)
The context menu (accessible by right-clicking in the table) allows you to access various functions, such as adding or deleting a table row, or undoing the last modifications.
Output tables (global settings)
Table style
Output tables can be changed regarding their design. Different designs are available. Example:
Table style: display (default)
Table style: compact
Include column filters
Table filters can be used to search each table column individually for entries. If there are strings in the column, the filter is a text search. For numeric values, a numeric range can be specified as the filter with the help of a slider. The filters can be displayed above or below the table or can be deactivated completely.
Number of items to display per page
Specifies the default value of how many rows should be displayed per table sheet. The value can be changed by the user from the MIRO application.
Show row numbers?
Select buttons to use
The export buttons copy, CSV, Excel, PDF and print are available. Additionally, you can hide/show individual columns with the column visibility button.
Note:
Please note that only the currently visible data is exported! If a symbol contains multiple table pages, using a button only affects the currently visible table page! It is recommended to use the native export functionality of MIRO instead.
Symbol tables (symbol specific settings)
By default, every cell in an input table is editable and rows can be inserted and removed. If you only want to allow your users to edit certain tables or even only certain columns within a table, you can customize the visualization for the underlying GAMS parameter. You can also use a different type of table to enter your data. For example, if you have large amounts of data (>100,000 records) in your table, we recommend using either the Big Data Table or the pivot table. In addition, input tables can be annotated with Markdown syntax. This way you can give your users additional information, e.g. what kind of data should be entered here and in which format.
Also global table settings for output symbols can be overwritten for each individual symbol. The available options are almost identical. The only additional settings are the number of decimal places to display and an option to disable graphics for the symbol.
Note that in contrast to the global settings, a symbol-specific configuration needs to be applied by clicking on the corresponding save-button!
Available options for an input symbol table (type: Default):
This is the standard table in MIRO, which works similar to a spreadsheet.
Should table be read-only?
Select a column to pivot
This option allows you to pivot a table column of a symbol, i.e. to have a new column from each of the elements in this column:
Unlike the
table statement in
the GAMS model itself (Table symbolname;), this option does not affect the
data contract
between GAMS and MIRO. Hence, the columns of the symbol
remain variable, since the symbol itself is communicated
in list format. The pivoting of the configured column
then happens "live" in the MIRO application.
Variable columns do not only mean that the column
elements can change their names. It is also possible to
add or delete whole columns. On the GAMS model side,
this is equivalent to adding or deleting a set element
of the affected index.
Note:
Instead of pivoting a single column, the MIRO pivot table can be used in case you want to interactively filter, pivot or aggregate columns.
When using the pivot option, note the following:
- The table columns displayed with the pivot option can no longer be sorted alphabetically or numerically.
- Furthermore, it is not possible to add or delete columns in the symbol table if it is either read-only or displayed as a heatmap.
Now let's look at a case where we should probably
avoid using this pivot functionality: For this we
look at the parameter
Price of the
Pickstock model:
Set date 'date'
symbol 'stockSymbol';
$onExternalInput
Parameter price(date,symbol) 'Price';
$offExternalInput
If we decide to pivot the set symbol, we would end up with a table where all stock symbols (AAPL, AXP, BA, etc.) are displayed in a separate column:
A table width quickly increases when the number of set elements of the header index gets large. A total of - for example - 30 stocks to be represented in a table would lead to 30 additional columns. In this case, the list view might be more clear.
Fix columns that are not pivoted?
This option is available if a table has more than one value column. This can be the case for pivoted tables and for GAMS tables. When enabled, all columns that are not pivoted (i.e. all non-value columns) are fixed to the left side of the table and remain visible even when scrolling horizontally.
Select columns to be readonly
This option prevents the user from making manual changes in selected columns of the input table. Note that this option is only available for table columns that have not been pivoted (see option above).
Specify the number of decimal places for the column
Hide indexing column?
Turn table into a heatmap?
Turns the table into a heatmap.
Available options for an input symbol table (type: Big Data Table):
This table type is intended for situations in which large amounts of data are to be displayed within a table. Instead of a long, 1-page table, a multi-page table is displayed. Only the data currently visible on the client side is loaded in this table.
Should table be read-only?
Select a column to pivot
Available options for an input symbol table (type: MIRO Pivot Table):
This table type is also capable of handling large amounts of data (> 1 million records). It allows you to interactively filter, pivot or aggregate data. See here for more information about the MIRO Pivot Table. The configuration of this table can be done directly from the preview on the right side.
Note:
The MIRO Pivot Table has no concept of "order" because the table can be sorted interactively by changing the order of the rows. When you add or change UELs, they are always appended to the underlying data source. So when MIRO passes the data to GAMS, you cannot rely on the order of the elements coming from this table type. If you need UELs in a certain order, you should either use one of the other input table types or declare the sets you need sorted as additional external input (instead of using the implicit set definition).
Available Options for an output symbol table:
Number of decimal places to display
Only display the table and no graphic for this symbol
For all other options please consult the section for global table settings.
Configure widgets
Input widgets can be used instead of tables to enter scalar input data. Examples of such widgets include: sliders, dropdown menus, date selectors or checkboxes. In the configure widgets section of the Configuration Mode you can configure widgets for:
The section Configure widgets looks as follows:
The symbol type to be configured can be selected at the top. The options are:
-
Symbol
This option must be selected if we want to configure a GAMS symbol: scalars and 1-dimensional (singleton) sets.
Furthermore, already configured GAMS options and double dash parameters are listed here, so that the existing configuration can be changed / removed.
Note:After configuring a widget, the corresponding scalar is automatically removed from the Scalars table and rendered as a widget instead.
-
New GAMS option / New double dash parameter
As the name suggests, GAMS options and double-dash parameters can be configured here as an input widget.
Since those parameters are specified via the command line in GAMS, they can not be tagged in the GAMS code with$onExternalInput/$offExternalInput. So that they can be set for a GAMS run via MIRO, they must be explicitly specified in the configuration.If a GAMS option or a double dash parameter is set via MIRO, your GAMS model will automatically be called with these command line parameters. The values the user selected are therefore available to the GAMS model at compile time.
Tip:The GAMS options and double-dash parameters associated with a scenario are stored in MIRO's internal database. However, the information about them is lost when a scenario is exported as a GDX file. We therefore recommend using singleton sets instead of command line parameters. Both the element label and the element text of a set can be migrated to compile time variables using the Dollar Control Options eval.Set, evalGlobal.Set, and evalLocal.Set.
Read more here.
Example:
If we set the double dash parameter numberPeriods to 11 and for the GAMS option mip we select CPLEX from within MIRO, then the GAMS model is run with:gams <modelname>.gms --numberPeriods=11 MIP=CPLEXWarning:The following GAMS options are reserved by GAMS MIRO and can not be configured: idir1, curdir, trace, traceopt
The following widgets are available for scalar values:
Click on a widget to get more information
Example:
Let's now configure a widget for our
transport model. For the scalar value
freight a slider is a good choice.
From the
list of available symbols we choose the desired scalar,
select slider as widget tye and give it a label,
which then appears above the slider.
Next, we
specify the upper and lower bounds of the slider, the
default value as well as the step size.
When we are satisfied with the selected configuration, we click "save". A confirmation that the configuration has been updated successfully will appear:
Done!
Configure graphs
Besides the default tabular format, multidimensional GAMS symbols can be visualized as graphs. GAMS MIRO offers comprehensive visualization options. A lot of plotting types are available and only need to be configured, i.e. adapted to your model-specific data.
Advanced: Symbol dimensions
The following section shows some examples for different chart types you can use in MIRO. It is not useful to describe all possible options MIRO supports. Instead, you should just explore it yourself! Start the Configuration Mode and play around with the data until you get a satisfactory result.
Tip:
To create graphics that are perfectly tailored to your data and not available in MIRO yet, you can also use MIRO's R-API. More information can be found here.
Database management
Create database backups, restore a database, remove database tables.
Warning:
Deleting data from the database cannot be undone!
Options not available in Configuration Mode
With the Configuration Mode we pursue the goal that a user can completely configure a MIRO application without having to write any JSON code. However, there are a few advanced options that are not yet available in the Configuration Mode and will have to be configured manually when desired. The following section describes these options.
Remote data import and export
Custom input widgets
Drop-down menu in input table
An input table can be configured so that the cells are not freely editable by the user, but can only be modified via a drop-down menu. This can greatly simplify the usability of input tables. When used properly, another advantage of providing dropdown menus is the prevention of invalid or inconsistent user input data.
The configuration of the drop-down menus is done column
by column. In the following figure the column 'canning
plants' (GAMS symbol
Table d(i,j) 'distance in thousands of miles') has been configured to use a drop-down menu:
The choices of a drop-down menu can be either predefined (static choices) or filled dynamically:
-
Static choices:
Static choices are predefined in the <modelname>.json file by the app developer. The following configuration results in the drop-down menu in the figure above:{ "inputWidgets": { "d": { "widgetType": "table", "alias": "distance in thousands of miles", "pivotCols": "j", "dropdownCols": { "i": { "static": ["Seattle", "San-Diego", "Los Angeles", "Houston", "Philadelphia"], "colType": "dropdown" } } } }The configuration is done in section "inputWidgets" for each input table (here: d) separately. In "dropdownCols" the individual table columns are specified (here: column "i"), which should have drop-down menus. The key "static" followed by an array defines the static drop-down choices. For the "colType" key you can choose between "dropdown" and "autocomplete" (default). While "dropdown" always displays all choices at once, "autocomplete" updates the displayed choices according to an autocomplete.
Tip:If your configuration file does not yet have any entries for the table to be configured, you can simply create an initial configuration using the Configuration Mode. Select the desired symbol under "Configure tables" → "Symbol tables" and click on save. Make sure that "default" is selected as table type to be used.
-
Dynamic choices:
Choices are dynamically filled by the cells of a column in another table. In the following example, the GAMS symbol
Table d(i,j) 'distance in thousands of miles'is configured so that the column i ("canning plants") displays a drop-down menu whose choices are fetched from the entries in the column of the same name in the symbol table a ("Capacity").This is what happens in the app: In the table "Capacity" the user can make any entries. If she edits the column "canning plants", the entries there are passed as choices to the dropdown menu of the "distance in thousands of miles" table:
The configuration of this table looks as follows:
{ "inputWidgets": { "d": { "widgetType": "table", "alias": "distance in thousands of miles", "pivotCols": "j", "dropdownCols": { "i": { "symbol": "a", "column": "i", "colType": "dropdown" } } } }Instead of a "static" key, there are now two keys "symbol" and "column". The value of the "symbol" key ("a" → "capacity" table) defines the symbol table whose "column" ("i" → "canning plants") is to be used to fill the drop-down menu.
Advanced: JSON validation schema for dropdown menu columns
Column width of an input table
With the colWidths option it is possible to adjust the column width of individual tables (in pixels). Note that this a configuration always affects all columns of a table.
Example:
{
"inputWidgets": {
"d": {
"widgetType": "table",
"alias": "distance in thousands of miles",
"pivotCols": "j",
"dropdownCols": {
"i": {
"symbol": "a",
"column": "i",
"colType": "dropdown"
}
}
}
}Results in:
Configuration via JSON files
The entire configuration of MIRO is done via JSON files. After the first start of a MIRO app, the following files are located in <modeldirectory>/conf_<modelname>:
-
<modelname>_io.json
This file describes the data contract between MIRO and GAMS and is generated automatically each time MIRO is run in development mode. All GAMS symbols that are marked in your GAMS model with the$onExternalInput/$offExternalInputand$onExternalOutput/$offExternalOutputtags are listed here. You won't ever have to modify this file! -
<modelname>.json
All the configuration of MIRO happens in the other JSON file <modelname>.json, e.g. transport.json. When you use the Configuration Mode to configure your app, this file is generated and modified. Here you can customize the general appearance of MIRO, set symbol-specific options, adjust the functionality and much more. Furthermore, all the graphics and widgets are specified here. If you're using a version control system like Git, you should check this file in to keep track of any changes made to the configuration of your app.
Note:
If you don't start MIRO via GAMS Studio but via the command line, the JSON files are not created automatically. Read more about this here.
In case you want to change the language of MIRO or display a scalar input symbol as a slider, this information must be stored in the <modelname>.json file in JSON syntax. When you first launch MIRO for a new model, the <modelname>.json file is almost empty:
{}Each adjustment you want to make must be captured within the curly braces of this file.
To ensure that the configuration is correct in terms of
syntax and content, all JSON files are validated against
schema in the background. Only if the validation is
successful the application starts. If a schema is
violated, an error message is displayed.
The schemas are located in
<MIRORoot>/miro/conf. For
the
<modelname>_io.json this
is the schema
<MIRORoot>/miro/conf/io_config_schema.json
and for the
<modelname>.json the
schema
<MIRORoot>/miro/conf/config_schema.json
is used. Since the latter file is used for the
configuration, only the corresponding schema is of
interest. You can have a look at it
here.
Tip:
In the sections on configuring widgets and charts, you can also find examples of what the configuration looks like in JSON.
Example: tables
Let's get back and extend our demo model transport. We will do this by adjusting the file transport.json in order to to adapt MIRO to our needs.
GAMS MIRO comes with several options on how you can feed your model with input data. By default, GAMS input parameters, sets and scalars are displayed in an editable table:
The corresponding GAMS declaration statement looks like
this:
Parameter d(i,j) 'distance in thousands of
miles';. By default, every cell in the table is editable and
rows can be inserted and removed. If you only want to
allow your users to edit certain tables or even only
certain columns within a table, you can customize the
visualization for the underlying GAMS parameter. You do so
by adding this kind of information to the
transport.json file. For
example, if we decide that the table for our parameter
d should not be editable, this
information needs to be added to our JSON file as follows:
{
"inputWidgets": {
"d": {
"widgetType": "table",
"readonly": true
}
}
}Example: scalars
As with all MIRO customizations, the information about the
type of visualization of a GAMS scalar is configured via
the file <modelname>.json.
Let's get back to our transport app. In the
previous section
we configured the table of parameter
d so that it is no longer
editable. We achieved this by writing the corresponding
information into the
transport.json file. Now we
extend the configuration of our app further by adding
information about how to display the scalar value
f ('freight in dollars per case per thousand miles'). Instead of displaying it in a table, we want to use a
slider:
{
"inputWidgets": {
"d": {
"widgetType": "table",
"readonly": true
},
"f": {
"widgetType": "slider",
"alias": "Freight in dollars per case per thousand miles",
"label": "Select the freight costs",
"min": 1,
"max": 500,
"default": 90,
"step": 1
}
}
}When we restart our app, the scalar is now automatically removed from the Scalars table and instead rendered as a separate widget:
In the sections on widgets and charts you will find a JSON example for each widget or chart type.
Command line parameters
We have already mentioned the possibility of
setting GAMS command line parameters via MIRO. Since
GAMS Options
and
Double Dash Parameters
are specified via the command line in GAMS, they can not
be tagged in the GAMS code with
$onExternalInput /
$offExternalInput . To
be able to set them from MIRO, they can be specified in
the <modelname>.json file.
In order for MIRO to recognize whether your symbol is a
double dash parameter or a GAMS option, you must prefix
the symbol name with either _gmspar_ for double
dash parameters or _gmsopt_ for GAMS options.
Note:
Command line parameters can not be displayed as a table, but only as a widget. Both, GAMS options and double-dash parameters can be displayed as a slider, dropdown menu, checkbox, text input or numeric input. For double-dash parameters date(-range) selector and slider range are also available.
Let's assume you want MIRO to call your GAMS model with the double dash parameter --numberPeriods, which can be set to a value between 1 and 14. You also want to be able to select the MIP solver to use. As you have licenses for CPLEX, Gurobi and XPRESS, you can only use either of these three solvers. Thus, your <modelname>.json file could look as follows:
{
"inputWidgets": {
"_gmspar_numberPeriods": {
"widgetType": "slider",
"alias": "Number of time periods",
"label": "Select the number of time periods to solve",
"min": 1,
"max": 14,
"default": 11,
"step": 1
},
"_gmsopt_mip": {
"widgetType": "dropdown",
"alias": "MIP Solver",
"label": "Solver to use for MIP models",
"choices": [
"CPLEX",
"GUROBI",
"XPRESS"
],
"multiple": false,
"selected": "CPLEX"
}
}
}The resulting interface in MIRO now looks as follows:
Advanced topics
Widgets with ranges
Tip:
In the MIRO Base Mode, widgets with ranges are only available for double-dash parameters!
We covered the basics of how to use widgets for your scalar inputs as well as command line parameters. Let's now take a look at how widgets that return two scalars instead of one are treated. Those widgets include a slider with two handles (also referred to as a slider range) and a date range selector:
The lower value (or starting date of the date range) is postfixed with _lo and the upper value (or end date of the date range) is postfixed with _up. This means that if you specified a slider range for your double dash parameter --RANGE, you can access the lower value of the range with %RANGE$LO% and the upper value with %RANGE$UP% while %RANGE% will not be set at all. Let's look at the following example: We would like to specify a time window that we want to fetch stock data for. Thus, we define a new double dash parameter --TW that we want to be visualized in the form of a date range selector. We add the following JSON snippet to our <modelname>.json configuration file:
{
"inputWidgets": {
"_gmspar_TW": {
"alias": "time window",
"widgetType": "daterange",
"label": "Time window",
"start": "2018-02-20",
"end": "2019-02-20",
"min": "2017-01-01",
"max": "2019-12-31",
"autoclose": true,
"noHcube": true
},
[...]
In our model, we can access the lower and upper value of this slider via the compile time variables %TW$LO% and %TW$UP%.
Dependencies among widgets
One special feature of GAMS MIRO is that you can define interdependencies between different parameters. Scalars can take two forms of dependencies to other parameters: They can feed their attributes from them; and they can manipulate the content of those parameters. Let's look at an example: we have a set of scenarios that can be selected as well as a singleton set with the currently selected/active scenario. A singleton set is suited to be represented as a dropdown menu, hence we choose that type of widget here. We would like to filter our parameters based on the currently selected scenario so that we only see data that is relevant for this scenario (this type of dependency is also referred to as a backward dependency). This means that in case scenario 1 is selected via our dropdown menu, we only want to display data relevant to scenario 1 to the user. Additionally, we want the choices of our dropdown menu to be the elements of all available scenarios (also referred to as a forward dependency).
Similar dependencies can also be considered for sliders. An example is the pickstock model. Here, the number of stocks you can select for your portfolio can not be larger than the number of stocks in your dataset. Similarly, the number of days you can use to train your model must not be larger than the number of days you have in the stock price dataset. The slider attributes - namely the maximum value that can be selected - should change according to the price data the user uploads. Thus, we also have forward dependencies here.
A table that shows the currently supported forms of dependencies for the different input widgets is shown below.
| Input widget type | Forward dependency | Backward dependency | Example model |
|---|---|---|---|
| Dropdown menu | - | ||
| Slider | pickstock | ||
| Checkbox | - | ||
| Date selector | - | ||
| Daterange selector | () | - |
Note:
You need dependency support for a type of widget which is currently not available? Please feel free to contact us at: miro@gams.com. You added dependency support for another type of widget yourself? Send us a pull request on GitHub!
Custom Renderers
GAMS MIRO allows you to use your own custom renderers for your datasets. In this section we will show you how to create really sophisticated custom graphics.
How to use a custom renderer
In order to visualize a dataset, you will need to write two functions: a placeholder where your graphs etc. will later be rendered as well as the rendering function itself. To learn more about the concepts of this dual component approach, visit the website for the R Shiny framework that GAMS MIRO is based upon: https://shiny.rstudio.com/. In particular, we are using Shiny Modules to realize the interface between MIRO and your custom renderer functions. The template for the two components of every custom renderer is as follows:
mirorenderer_<symbolName>Output <- function(id, height = NULL, options = NULL, path = NULL){
ns <- NS(id)
}
renderMirorenderer_<symbolName> <- function(input, output, session, data, options = NULL, path = NULL, rendererEnv = NULL, views = NULL, outputScalarsFull = NULL, ...){
}
Note that you need to replace <symbolName> with the name of the GAMS symbol you want to use this renderer for. Let's go through this code step by step. As mentioned, for each custom renderer we need to specify two functions: one that generates the placeholder and one that fills this placeholder with data. The name of the placeholder function must be postfixed with "Output" and the name of the function that specifies the actual rendering must be prefixed with the keyword "render". Let's get back to our transport example. We would like to see the flow of goods visualized on a map. The GAMS symbol that contains the flow data is called optSched. Thus, our initial template looks like this:
mirorenderer_optschedOutput <- function(id, height = NULL, options = NULL, path = NULL){
ns <- NS(id)
}
renderMirorenderer_optsched <- function(input, output, session, data, options = NULL, path = NULL, rendererEnv = NULL, views = NULL, outputScalarsFull = NULL, ...){
}
Note:
MIRO expects your renderer names to follow this strict convention. Note that the symbol name in your renderer name should be converted to all lowercase. Even if the symbol in GAMS is called optSched, the renderer function name should be mirorenderer_optschedOutput and renderMirorenderer_optsched.
Note:
Custom renderer scripts must be located in a folder named: renderer_<modelname> in your model directory. The name of the renderer file should be: mirorenderer_<symbolname>.R.
Both functions take a number of parameters. Let's start with the placeholder function: Each custom renderer has its own ID. In order to avoid name collisions with other custom renderers or functions of GAMS MIRO, we need to prefix our input and output elements with this ID. How should we prefix our custom input and output functions, though? Fortunately, Shiny provides us with the function: NS(). This function takes the ID of our custom renderer as its input and returns a function (functions that return functions are often called closures in R) that does the prefixing for us. Thus, whenever we want to specify a new input or output element, we simply hand the ID we would like to use for this element over to this prefixing function (which in our case is bound to the ns variable). We can also specify a height for our renderer as well as the path where the renderer files are located. We can also pass additional options to our renderer functions.
Let's get back to our example. As we would like to visualize our optimized schedule on an interactive map, we choose the popular Leaflet library. Fortunately, there is already an R/Shiny interface for this library: Leaflet for R. This R package comes with the two functions: leafletOutput() that generates the placeholder and renderLeaflet() that renders a Leaflet map object created by the leaflet() function which takes our dataframe as its first argument. So let's put the pieces together and extend our code:
mirorenderer_optschedOutput <- function(id, height = NULL, options = NULL, path = NULL){
ns <- NS(id)
leaflet::leafletOutput(ns("map"), height = height)
}
renderMirorenderer_optsched <- function(input, output, session, data, options = NULL, path = NULL, rendererEnv = NULL, views = NULL, outputScalarsFull = NULL, ...){
output$map <- leaflet::renderLeaflet(leaflet::leaflet(data))
}Note that we used the aforementioned ns() function to prefix the ID ("map") that we chose for our Leaflet element. Just like any other placeholder element, the function leafletOutput() generates an element that can be accessed via the list-like output object.
Inside our rendering function we assign this object the
Leaflet map that is created by the
renderLeaflet() function. In case you find the
whole concept of having an output function, a rendering
function, an output object etc. still very confusing, you
should take a look at the
official tutorial series
for the Shiny framework.
To summarize: elements that generate data can be accessed
by the input object; elements that transform
data to some form of visualization via the
output object and any user-specific information
via the session object.
Note:
If you use functions from packages other than shiny, DT, rhandsontable, dplyr, readr or the R base packages, make sure you specify the package/namespace that exports this function. In our example, the functions leafletOutput, renderLeaflet and leaflet are exported from the package leaflet. So we need to use the double colon operator to access them (e.g. leaflet::leafletOutput).
The data that you want to visualize is supplied to your rendering function by the data argument - an R tibble, a data structure that is very similar to a Data Frame. In case you specified additional datasets to be communicated with your custom renderer, data will be a named list of tibbles where the names are the GAMS symbol names. In addition, the values of all input and output scalars can be accessed via the argument outputScalarsFull (a tibble with the columns scalar, description, value). The function argument path is a string (a one-dimensional character vector) that specifies the absolute path to your renderer_<modelname> directory. This is useful if you want to include external files in your custom renderer functions. Optional parameters that you want to pass to the renderer can be accessed via the argument options - a (nested) list.
Tip:
The list options always has a nested list
with the key _metdata_, which gives you
access to the metadata of the symbol to render, such
as the symbol type (set, parameter, ...) and header
information (header name, alias, type). For example,
the symbol type can be accessed as follows:
options[["_metadata_"]][["symtype"]].
Now that we are familiar with the template that every custom renderer builds upon, we are still missing one fundamental concept so that we can use our custom renderer: binding the renderer to dataset(s) we wish to visualize.
This binding of GAMS parameter to renderer function is specified - just like any other renderer binding - in the <modelname>.json file; more precisely the dataRendering section. Let's assume that in our transportation example the GAMS parameter that specifies the optimal schedule is defined as optSched(lngp, latp, lngm, latm, plant, market) where (lngP,latP) and (lngm, latm) are the coordinates of the plants and markets respectively. Our transport.json file should then look like this:
{
"dataRendering":{
"optSched":{
"outType":"mirorenderer_optsched",
"height":"700",
"options":{
"title":"Optimal transportation schedule"
}
}
}
}As you can see we bound the GAMS parameter optSched to our new custom renderer mirorenderer_optsched. Furthermore, we specified a parameter: title that can be accessed by our custom renderer via the options list.
If we decided to run our MIRO app now, we still would not be able to see anything other than a blank area. Thus, we will need to fill our renderer with some life:
mirorenderer_optschedOutput <- function(id, height = NULL, options = NULL, path = NULL){
ns <- NS(id)
tagList(
textOutput(ns("title")),
leaflet::leafletOutput(ns("map"))
)
}
renderMirorenderer_optsched <- function(input, output, session, data, options = NULL, path = NULL, rendererEnv = NULL, views = NULL, outputScalarsFull = NULL, ...){
output$title <- renderText(options$title)
output$map <- leaflet::renderLeaflet(leaflet::leaflet(data) %>%
leaflet::addTiles() %>%
leaflet::addMarkers(~lngp, ~latp, label = ~plant)
)
}We have added a new placeholder for the title. Note the use of the tagList() function. Since every R function has a single return value which is either the last evaluated expression of the function or the argument to the first return() function that is encountered in the function body, we need to return a list object. A tagList() is simply a list with an additional attribute to identify that the elements are html tags.
Within our rendering function, we set the title, add the default OpenStreetMap tiles as well as some markers for our plants.
Note:
The syntax ~lngp that you see here is simply a shorthand for data$lngp - the pipe operator a(x) %>% b(y) a shorthand for tmp <- a(x); b(tmp, y)
If you read until this point, you might have noticed that there is a parameter in the renderer function that we did not talk about yet: rendererEnv. This parameter is a static R environment that is persistent across different calls to the renderer function. Each time the data of your widget is updated (e.g. due to the user loading a new scenario from the database), your renderer function is called. One case where this can become problematic is when you make use of observers in your renderer functions. Every time your renderer function is called, all observers are re-registered, which leads to duplicated observers. To avoid this problem, you must ensure that observers are cleaned up when they are no longer needed. You do this by assigning them to the rendererEnv environment. An example where this is extensively used is the model tsp, which can be found in the MIRO model library.
You now know everything you need in order to get started writing your own custom renderers! Congratulations! In case you create a new renderer that you would like to share so that others can benefit from your work as well, please contact us!
Additional datasets
A custom renderer for an output symbol can use the data of
other GAMS symbols. For example - let's stay with the
above example of a map - the geographical information can
come from other symbols than the transport data. For a
custom renderer to access this data, the corresponding
symbols must be specified in the
<modelname>.json file
under "additionalData":
{
"dataRendering":{
"optSched":{
"outType":"mirorenderer_optsched",
"height":"700",
"options":{
"title":"Optimal transportation schedule"
},
"additionalData": ["symbol_a", "symbol_b"]
}
}
}
Note:
All symbols that a custom renderer should use must be included in the GAMS/MIRO data contract.
Additional R packages
In a custom renderer you can include any R packages that
are not part of MIRO. This allows you to use all data
visualization and data processing capabilities of R. In
order for such packages to be installed when starting a
MIRO application, they must be specified in the
<modelname>.json file at
the configuration of the corresponding symbol under
"packages":
{
"dataRendering":{
"optSched":{
"outType":"mirorenderer_optsched",
"height":"700",
"options":{
"title":"Optimal transportation schedule"
},
"additionalData": ["symbol_a", "symbol_b"],
"packages": ["package_a", "package_b"]
}
}
}Note that these additional packages are installed but not loaded! This means that when you call the function, you must explicitly specify the package name using the Double Colon Operator: pkg::name(...). See also the info box in the previous section.
Tip:
Additional R packages are installed in the workspace of GAMS MIRO the first time a MIRO application is started.
Views
In cases where your renderers are interactive, you might want to allow users to store the current state of your renderer and load it later with a single click. This is what MIRO views were designed for. A MIRO view can be any (nested) list that is JSON serializable. Views are bound to a particular GAMS symbol and each view has a unique id. One example of a renderer where the MIRO views API is used is the pivot table renderer.
You might have already seen that there is another argument in the renderer function that we have not yet talked about: the views argument. This is a reference to an instance of the views R6 class. You can get, add and remove views as well as register callbacks via this object. The following section explains how to use the API.
Get view data
views$get(session, id = NULL)
Arguments
| session | The session object passed to the custom renderer |
|---|---|
| id | id of the view to load |
Value
In case id is NULL: a named list where the names are the ids of the views and the values are the view data.
In case id is not NULL: a list with the data of the view. Will throw an error in case the id provided does not exist.
Description
This method allows you to retrieve the data of views registered for the symbol. You can retrieve either the data of all views (id is NULL) or the data of a specific view (id not NULL).
Example
# myViews <- list(filter1 = list(filter = list(element1 = "Value 1", element2 = c("Value 2", "Value 4"))),
# filter2 = list(filter = list(element3 = "Value 7")))
views$get(session, "filter1")
#> $filter
#> $filter$element1
#> [1] "Value 1"
#>
#> $filter$element2
#> [1] "Value 2" "Value 4"
views$get(session)
#> $filter1
#> $filter1$filter
#> $filter1$filter$element1
#> [1] "Value 1"
#>
#> $filter1$filter$element2
#> [1] "Value 2" "Value 4"
#>
#>
#>
#> $filter2
#> $filter2$filter
#> $filter2$filter$element3
#> [1] "Value 7"
views$get(session, "filter3")
#> Error: View with id: filter3 could not be found.
Get view ids
views$getIds(session)
Arguments
| session | The session object passed to the custom renderer |
|---|
Value
Character vector with the view ids registered for the symbol.
Description
Retrieves the view ids that are currently registered for
the symbol. It is equivalent to
names(views$get(session)).
Example
# myViews <- list(filter1 = list(filter = list(element1 = "Value 1", element2 = c("Value 2", "Value 4"))),
# filter2 = list(filter = list(element3 = "Value 7")))
views$getIds(session)
#> [1] "filter1" "filter2"
Add view
views$add(session, id, viewConf)
Arguments
| session | The session object passed to the custom renderer |
|---|---|
| id | id of the view to add |
| viewConf | The view configuration |
Description
Adds/registers a new view. The view configuration can be
any JSON serializable list. If a view with the same id
already exists for the symbol, the previous view is
replaced. In case the current renderer is read-only (not a
sandbox scenario), an error is thrown. You can test
whether the renderer is read-only with the method
views$isReadonly(session).
Example
# myViews <- list(filter1 = list(filter = list(element1 = "Value 1", element2 = c("Value 2", "Value 4"))),
# filter2 = list(filter = list(element3 = "Value 7")))
views$add(session, "filter3", list(filter = list(element4 = "Value 10")))
Remove view
views$remove(session, id)
Arguments
| session | The session object passed to the custom renderer |
|---|---|
| id | id of the view to remove |
Description
Removes a view with the specified id. If no view with this
id exists, an error is thrown. In case the current
renderer is read-only (not a sandbox scenario), an error
is thrown. You can test whether the renderer is read-only
with the method
views$isReadonly(session).
Example
# myViews <- list(filter1 = list(filter = list(element1 = "Value 1", element2 = c("Value 2", "Value 4"))),
# filter2 = list(filter = list(element3 = "Value 7")))
views$get(session)
#> $filter1
#> $filter1$filter
#> $filter1$filter$element1
#> [1] "Value 1"
#>
#> $filter1$filter$element2
#> [1] "Value 2" "Value 4"
#>
#>
#>
#> $filter2
#> $filter2$filter
#> $filter2$filter$element3
#> [1] "Value 7"
views$remove(session, "filter2")
views$get(session, "filter1")
#> $filter
#> $filter$element1
#> [1] "Value 1"
#>
#> $filter$element2
#> [1] "Value 2" "Value 4"
views$remove(session, "filter2")
#> Error: View with id: filter2 does not exist, so it could not be removed.
Register update callback
views$registerUpdateCallback(session, callback)
Arguments
| session | The session object passed to the custom renderer |
|---|---|
| callback | a callback function |
Description
You can register a callback function that is triggered
whenever the view data of a symbol is modified
outside the renderer. This happens when a user
modifies the view data via the
metadata dialog.
Note that the callback function is not triggered by the
methods views$add or
views$remove described
above.
Example
updateCallback <- function(){
print(sprintf("View data changed from outside! New view ids: %s.",
views$getIds(session)))
}
views$registerUpdateCallback(session, updateCallback)
Migrate renderers from MIRO 1.x
The custom renderers you created with MIRO 1.x will also work with MIRO 2.0. You will only encounter problems if you try to use these renderers in the Configuration Mode. To make your old renderers compatible with the Configuration Mode of MIRO 2.0, you must follow the rules below:
- A renderer is now bound to a specific symbol.
- Renderers can be shared by different symbols, but they always belong to one of them.
- This means that the name of the output and renderer functions should be: mirorenderer_<symbolName>Output and renderMirorenderer_<symbolName> respectively.
- Renderer files must be named mirorenderer_<symbolname>.R.
- Only one output/render function may be declared per file.
Language Files
GAMS MIRO comes with the ability to change the preferred language. Setting your preferred language results in MIRO embedding the corresponding language file where all the language specific components are specified via JSON syntax. MIRO currently ships with three of those language files: English, German and Chinese. If you would like to add another language to this list, you are more than welcome to translate one of the existing language files. The language files are located at: <MIRORoot>/miro/conf/en.json and are validated against the JSON Schema file: <MIRORoot>/miro/conf/language_schema.json. Note that there are sometimes placeholders in the language files. Let's take the error message: "The value '%s' for the slider: '%s' is not of numeric type." for example. %s will then be replaced with the value and name of the slider by MIRO. Thus, if you create a new language file, be sure to include these placeholders there!
If you would like to contribute your language file, so that other people can profit from your work as well, send us an email: miro@gams.com.