Binding to Data and Dimensional Flexibility

The optimization example model above includes the data - the x,y coordinates of six cities - in the RASON request. It's easy to change the data in JavaScript by referencing request.data.dx.value, but the request itself will find a solution only for the included data. What if you want to solve this model for many different sets of data? RASON makes that easy too. For a small problem like this one, if you change data as shown below, you can pass new data directly in the REST API call, via standard HTTP GET query string parameters.

"data" : {
   "dx" : { "dimensions": [6], "binding": "GET" },
   "dy" : { "dimensions": [6], "binding": "GET" }
}

$.get (https://rason.net/api/optimize?dx=1,0.5,2,2,2,0.5&dy=4,3,4,2,5,6...

But many realistic models use large tables of data, often drawn from multiple data fields or databases. Further, our example model is "fixed" to six cities, but we might want to solve this problem many times, each time for a different number of cities - changing the dimensions of parameters dx and dy, or even changing the dimensions of arrays of decision variables, uncertain variables or constraints.

Below is the same RASON optimization model with an added section, datasources. Our list of city coordinates is now located in a CSV file, however, our data could also have been located in an odbc database or an Excel file.

{
 modelName: "AirlineHubExample",
 modelType: "optimization",
 engineSettings : { engine : 'GRG Nonlinear' },
 datasources : {
    city_data: { 
      type: 'csv', 
      connection: 'AirlineHubData.csv', 
      indexCols: ['cities'], 
      valueCols: ['dx', 'dy'],
      direction: "import"
    }
 },
 variables : {
    x : { value: 1.0, finalValue: [] },
    y : { value: 1.0, finalValue: [] },
    z : { value: 1.0, finalValue: [] }
 },
 data : {
    dx : { binding: 'city_data',  valueCol: 'dx' },
    dy : { binding: 'city_data',  valueCol: 'dy' }
 },
 constraints : {
    c : { dimensions: ['cities', 1], upper: 0, formula: "sqrt((x - dx)^2 + (y - dy)^2) - z" }
 },
 objective : {
    obj : { type: 'minimize', formula: 'z', finalValue: [] }
 }
}

(We've used double and single quotes in this example, which are interchangeable.) The dataSources section defines a source for the data values, formerly in the data section, in this case a comma-separated-value (CSV) file named AirlineHubData.csv. The data source defines an index column, CITIES, which is used to dimension the array of constraints, c. In the data section of the model, we bind the names dx and dy to 1-dimensional arrays from the corresponding value columns dx and dy. Our model can now be used to solve many different instances of this facility location problem, for a variable number of cities. (For more information on indexed sets, please see the RASON Reference Guide.)

The CSV file looks like this. Other currently supported data source types are 'excel', 'access' and 'odbc' for Oracle, SQL Server, OData and other databases.

Since the data source gave no URL or path for AirlineHubData.csv, this file must be in the 'current folder' when the model executes on the RASON back-end server; you can upload files to this folder along with your REST request. To try this yourself, create a text file AirlineHubData.csv from the values shown above (or below), upload AirlineHubData.csv using the Choose Files button on the Editor page, retrieve the model above from the RASON Examples drop down menu (UGAirlineHubCSV.json), create a model resource using POST rason.net/api/model, then click POST rason.net/api/model/id/optimize and GET rason.net/api/model/id/result. (The "quick solve" POST rason.net/api/optimize endpoint doesn't accept uploaded files.)

Index columns and index sets are much more general than the 1 through 6 values in the example above. If our CSV file contained instead:

Our model would still solve. Further, we could refer to dx['Pomona'] -- "subscripting" the dx array with the index set element name, and get the value 0.5. More general references can return "slices" of multidimensional arrays, as we'll show in future examples.

Now that you have been introduced to the RASON modeling language and RASON REST API, continue reading for help registering to obtain a subscription to the RASON REST Server, defining a RASON model, and finally, calling the RASON REST API endpoints to solve your optimization, simulation, data science or decision table model.