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.

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:

Determine whether the GAMS log file is displayed in the section GAMS interaction or not.

Determine whether the GAMS listing (lst) file is displayed in the section GAMS interaction or not.

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.

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:

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.

Defines the number of decimal places for numeric symbols in the MIRO application. This is a global setting and has an effect on all output tables, Big Data input tables and the table for loading scenarios in Hypercube Mode.

Note that this only applies to symbols that are treated as numerical values by MIRO. For example, elements of GAMS Sets may contain numbers, but they are not treated as such but as strings. These are therefore not affected by the maximum decimal place set.

For some charts, it may be desirable to use additional data that should not be displayed in the user interface. Currently, only custom renderers support using data from more than one symbol (also hidden ones). Note that the data of hidden symbols belongs to a scenario just like visible symbols and is therefore also stored in the database. They are only hidden in the user interface.

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.

This option allows you to use your own logo for your MIRO application, which is displayed in the upper left corner.

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:
  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.

  A list of all TeX functions supported by MIRO can be found here.

The readme file can be created or edited directly in Configuration Mode:

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.
  

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.

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:

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
  

If enabled, scenario data can be loaded via local files.

The metatdata sheet contains information about the user name, the scenario name and the time the scenario was created.

This option specifies whether empty sheets should be included when exporting a scenario. Sheets can be empty e.g. when a scenario contains only input data (has not been solved).

If you want to save the log and lst files of individual GAMS jobs, you can use this option to specify how long the files should be saved. 0 means files are not stored at all, 999 means files are stored indefinitely. This setting is ignored when the attachment module is not active. Note that this is currently only supported in the MIRO Base Mode.

Output attachments allow you to automatically attach files after a GAMS run has been successfully completed. This lets you store additional results alongside the ones displayed in the UI. In addition, MIRO gives you the option to choose what should happen when an attachment is not found after a successful GAMS run. Should the user be informed of this by an error message or should it be silently ignored. You can also choose to automatically extract the attachment to the working directory when you start another GAMS run with this scenario. This function adds a state to your scenarios. Per default, scenarios in MIRO are stateless. This means that running two consecutive GAMS runs with the same input data will result in the same output data. By adding an attachment to the scenario that GAMS is allowed to read on consecutive executions, the results may no longer be the same.

Let's have a look at a simple (toy) example:

$if exist report.put $abort "Report was found"

File report;
put report;
put "This is a report."
putclose;

When you run this GAMS model for the first time, it creates a file report.put. When running it a second time, it aborts with a compilation error: "Report was found". If you add the file report.put as an output attachment and select to extract it into the working directory whenever you run this scenario again, your scenario will carry a state. This gives you the possibility to implement processes of any complexity in your MIRO application.

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.

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.

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:

Sets the height of the table. If the table content is higher than the configured height, a scroll bar is displayed.

Sets all input tables to read-only. No manual edits can be made by the user. Database scenarios or local data can still be loaded.

Sets the general stretch behavior of columns. Available options are no stretch, stretch last column and stretch all columns. Stretched columns mean that the table always fills the entire window width. With large tables, this can have a negative effect on the performance of the application. Columns that are not set to stretch have a default column with of 200px.

Here, the default column with of 200px can be adjusted. It is recommended not to choose column widths that are too small, otherwise the table contents may not be displayed correctly.

Enables/disables the manual setting of the column width by the user.

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 can be changed regarding their design. Different designs are available. Example:

Table style: display (default)

Table style: compact

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.

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.

Determines whether line numbers should be displayed or not.

The export buttons copy, CSV, Excel, PDF and print are available. Additionally, you can hide/show individual columns with the column visibility button.

This option prevents the user from making manual changes in the input table of a scenario. If active, the table can only be filled with scenario data from the database/local files.

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.

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

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.

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.

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).

Option to hide indexing column in input tables.

Turns the table into a heatmap.

This option prevents the user from making manual changes in the input table of a scenario. If active, the table can only be filled with scenario data from the database/local files.

See previous section

A MIRO application can be supplied with data from various sources:

• Internal database: Import existing scenario data
• Local files: GDX, Excel
• Manually entered data

In addition to these default interfaces, the data can also come from or go to external sources.

"remoteImport": [
    {
    "name": "Importer",
      "templates": [
        {
          "symNames": "price",
          "url": "http://127.0.0.1:5000/io",
          "method": "GET",
          "authentication": {
            "username": "@env:API_USER",
            "password": "@env:API_PASS"
          },
          "httpBody": [
            {
              "key": "filename",
              "value": "/Users/miro/Documents/importer/pickstock/price_data.csv"
            }
          ]
        }
      ]
    }
  ]

The configuration of external data sources is template-based. This means that you can specify one and the same template for multiple input symbols. First, we have to specify which input symbols this template should apply to. Then we have to tell MIRO about the endpoint to connect to (in this case a server running on localhost on port 5000). Supported protocols are HTTP and HTTPS.

When the user requests to import data via this data source "Importer", the resulting HTTP request looks as follows: GET /io?filename=%2FUsers%2Fmiro%2FDocuments%2Fimporter%2Fpickstock%2Fprice_data.csv&modelname=pickstock&dataset=price HTTP/1.1. When observing the request, you will notice that in addition to the filename key that you specified, MIRO sends two more key-value pairs: modelname and dataset set to the name of the model and dataset being requested. These will always be appended to the body provided by you.

MIRO waits for the REST endpoint to respond with the requested dataset. Before we talk about the format in which MIRO expects the data, let's look at how the data is exported from MIRO to a remote destination. The format MIRO exports data is the same as data should be sent to MIRO!

One more aspect worth talking about is authentication. When your API is not running on the local machine, but a remote server, you might want to provide credentials with your request. In the example above, we provided the username and password used to authenticate to the API. However, instead of hardcoding these credentials in the configuration file (which is possible), it is recommended to use the special prefix @env: that instructs MIRO to read the credentials from environment variables. Currently, the only supported authentication method is basic access authentication. In case you need another method, send us an email or a pull request!

Instead of importing data from a remote data source, you can also export data to a remote destination. In this example the data of the symbol stock_weight should be exported to a CSV file: export_stock_weight.csv. As we now push data to the API, we use the POST HTTP method. The structure of the JSON configuration is identical to that of remote importers you have seen before:

"remoteExport": [
    {
      "name": "Exporter",
      "templates": [
        {
          "symNames": "stock_weight",
          "url": "http://127.0.0.1:5000/io",
          "method": "POST",
          "authentication": {
            "username": "@env:API_USER",
            "password": "@env:API_PASS"
          },
          "httpBody": [
            {
              "key": "filename",
              "value": "/Users/miro/Documents/exporter/pickstock/export_stock_weight.csv"
            }
          ]
        }
      ]
    }
  ]

What's more interesting is the request body that MIRO sends to the remote server:

{"data":[{"symbol":"AXP","value":0.472295069483016},{"symbol":"MMM","value":0.316292266161662},{"symbol":"MSFT","value":0.406195141778428}],"modelname":"pickstock","dataset":"stock_weight","options":{"filename":"/Users/miro/Documents/importer/pickstock/price_data.csv"}}

MIRO sends data serialized as JSON. The modelname and dataset keys are sent along just like in the GET request we saw previously when importing data. In addition, we get the custom key-value pairs we specified in a special object called options as well as the actual data of the symbol in data. Note how the table is serialized. In case you need MIRO to serialize tables in a different format, send us an email or a pull request.

MIRO has an API that allows you to use custom input widgets such as charts to produce input data. This means that input data to your GAMS model can be generated by interactively modifying a chart or any other type of renderer.

Before reading this section, you should first study the chapter about custom renderers. Custom widgets are an extension of custom renderers that allow you to return data back to MIRO.

To understand how this works, we will look at an example app that allows you to solve Sudokus. We would like to visualize the Sudoku in a 9x9 grid that is divided into 9 subgrids - 3x3 cells each. We will use the same tool that we use to display input tables in MIRO, but we could have used any other R package or even a combination of those. Let's first look at the boilerplate code required for any custom input widget:

mirorwidget_<symbolName>Output <- function(id, height = NULL, options = NULL, path = NULL){
  ns <- NS(id)
}

renderMirowidget_<symbolName> <- function(input, output, session, data, options = NULL, path = NULL, rendererEnv = NULL, views = NULL, outputScalarsFull = NULL, ...){
  return(reactive(data()))
}
                                        

The other important difference from custom renderers is that the data argument here is also a reactive expression (or a list of reactive expressions in case you specified additional datasets to be communicated with your widget), NOT a tibble.

Let's get back to the Sudoku example we mentioned earlier. We place a file mirowidget_initial_state.R within the custom renderer directory of our app: <modeldirectory>renderer_sudoku. The output and render functions for custom widgets should be named mirorwidget_<symbolName>output and renderMirowidget_<symbolName> respectively, where symbolName is the lowercase name of the GAMS symbol for which the widget is defined.

To tell MIRO about which input symbol(s) should use our new custom widget, we have to edit the sudoku.json file located in the <modeldirectory>/conf_<modelname> directory. To use our custom widget sudoku for an input symbol named initial_state in our model, the following needs to be added to the configuration file:

{
"inputWidgets": {
    "initial_state": {
      "widgetType": "custom",
      "rendererName": "mirowidget_initial_state",
      "alias": "Initial state",
      "apiVersion": 2,
      "options": {
        "isInput": true
      }
    }
  }
}

We specified that we want an input widget of type custom for our GAMS symbol initial_state. Furthermore, we declared an alias for this symbol which defines the tab title. We also provided a list of options to our renderer functions. In our Sudoku example, we want to use the same renderer for both input data and output data. Thus, when using our new renderer for the input symbol initial_state, we pass an option isInput with the value true to our renderer function.

Let's concentrate again on the renderer functions and extend the boilerplate code from before:

mirowidget_initial_stateOutput <- function(id, height = NULL, options = NULL, path = NULL){
  ns <- NS(id)
  rHandsontableOutput(ns('sudoku'))
}

renderMirowidget_initial_state <- function(input, output, session, data, options = NULL, path = NULL, rendererEnv = NULL, ...){
  output$sudoku <- renderRHandsontable(
    rhandsontable(if(isTRUE(options$isInput)) data() else data, 
                  readOnly = !isTRUE(options$isInput), 
                  rowHeaders = FALSE))
  if(isTRUE(options$isInput)){
    return(reactive(hot_to_r(input$sudoku)))
  }
}
                                        

Let's disect what we just did: First, we defined our two renderer functions mirowidget_initial_stateOutput and renderMirowidget_initial_state. Since we want to use the R package rhandsontable to display our Sudoku grid, we have to use the placeholder function rHandsontableOutput as well as the corresponding renderer function renderRHandsontable. If you are wondering what the hell placeholder and renderer functions are, read the section on custom renderers.

Note that we use the option isInput we specified previously to determine whether our table should be read-only or not. Furthermore, we only return a reactive expression when we use the renderer function to return data - in the case of a custom input widget. Note that for input widgets, we need to run the reactive expression (data()) to get the tibble with our input data. Whenever the data changes (for example, because the user uploaded a new CSV file), the reactive expression is updated, which in turn causes our table to be re-rendered with the new data (due to the reactive nature of the renderRHandsontable function). The concept of reactive programming is a bit difficult to understand at first, but once you do, you'll appreciate how handy it is.

A detail you might stumble upon is the expression hot_to_r(input$sudoku). This is simply a way to deserialize the data coming from the UI that the rhandsontable tool provides. What's important is that we return an R data frame that has exactly the number of columns MIRO expects our input symbol to have (in this example initial_state).

That's all there is to it! We configured our first custom widget. To use the same renderer for the results that are stored in a GAMS symbol called result, simply add the following lines to the sudoku.json file. Note that we do not set the option isInput here.

"dataRendering": {
    "results": {
      "outType": "mirowidget_initial_state"
    }
  }

The full version of the custom renderer described here as well as the corresponding GAMS model Sudoku can be found in the MIRO model library. There you will also find an example of how to access values of (other) scalar input widgets from within your code. Note that MIRO currently supports only scalar input widgets as "additionalData".

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:

• 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

"dropdownCols":{
  "description":"Columns where only certain values are allowed to be selected (only supported for default tables)",
  "type":"object",
   "additionalProperties":{  
      "type":"object",
      "properties":{
        "colType":{
          "description": "Column type (default is 'autocomplete')",
          "type":"string",
          "enum":["autocomplete", "dropdown"]
        },
        "static":{
          "description": "Arrays of static choices allowed for this column",
          "type":["array", "string"],
          "minLength":1,
          "items":{
            "type":"string",
            "minLength":1
          }
        },
        "symbol":{
          "description": "Symbol to fetch choices from",
          "type":"string",
          "minLength":1
        },
        "column":{
          "description": "Column (of symbol) to fetch choices from",
          "type":"string",
          "minLength":1
        }
      }
   }
}

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"
        }
      }
    }
}