Formatos de dados de entrada e saída para Decision Optimization modelos OPL

Para a implantação, você deve usar os seguintes formatos de dados de entrada e saída para os modelos OPL Decision Optimization.

Formatos de dados do OPL

Em um modelo OPL, você deve declarar um tupleset para cada tabela que usar. O exemplo a seguir mostra um extrato de um modelo OPL:
tuple parameters {
	int maxTrucks;
	int maxVolume;
}
parameters Parameters = ...;

tuple location {
  key string name;
}
{location} Hubs = ...;

tuple spoke {
  key string name;
  int     minDepTime;
  int     maxArrTime;
};
{spoke} Spokes = ...;

dvar int+ TruckOnRoute[Routes][TruckTypeIds] in 0..Parameters.maxTrucks;

[...]

minimize TotalCost;

subject to {
	[...]
}

Dados de entrada

Os dados de entrada podem ser preenchidos por meio de uma origem de dados externa. Os dados de entrada para modelos OPL podem ser fornecidos em um destes formatos:

  • Arquivo .csv
  • Arquivo .dat
  • Documento JSON
  • Os arquivos de pasta de trabalho do Microsoft Excel (.xlsx e ' .xls) estão obsoletos.

    Para se conectar a arquivos do Microsoft Excel, use um conector de dados. O conector de dados transforma seu arquivo do Excel em um arquivo " .csv. Para obter mais informações, consulte Dados referenciados.

Arquivo .dat
Todas as estruturas de dados do OPL são suportadas. Por exemplo,
{Parameters = <100, 5000>;

Hubs = { <"G">, <"H"> };

Spokes = { <"A", 360, 1080>, <"B", 400, 1150> };
Documento JSON ou pasta de trabalho do Microsoft Excel
Você pode usar somente tuples e tuple sets como entradas no modelo OPL.

Os tipos suportados para os campos de tupla são int, float ou string.

Para mapear os valores de entrada para o modelo OPL, deve-se seguir estas regras:
  • O elemento OPL deve ter o mesmo nome da propriedade JSON ou da planilha Excel.
  • Um conjunto de tupla pode ser preenchido por uma matriz de propriedade JSON ou uma planilha.
  • Um elemento de tupla pode ser preenchido por um objeto de propriedade JSON ou com uma planilha do Excel de uma única linha.
O formato JSON pode ser usado para a integração do modelo OPL para que seja mais fácil gerar dados de entrada e analisar os resultados.
{
  "Parameters": {
    "maxTrucks": 100,
    "maxVolume": 5000
  },
  "Hubs": [
    {  "name": "G"  },
    {  "name": "H"  }
  ],
  "Spokes": [
    { "name": "A",
      "minDepTime": 360,
      "maxArrTime": 1080 },
    { "name": "B",
      "minDepTime": 400,
      "maxArrTime": 1150  },
   . . .
}

É possível usar um arquivo Excel em vez de usar um arquivo .dat. Essa opção é diferente da IBM ILOG CPLEX Optimization Studio, em que o arquivo do Excel deve ser especificado como uma fonte externa no arquivo .dat. Em Decision Optimization, o arquivo do Excel deve ser incluído no modelo e não pode ser chamado de um arquivo .dat.

A limitação de usar apenas tuplas e conjuntos de tuplas como entrada OPL é para facilitar a integração com fontes de dados. Por exemplo, as fontes de dados SQL podem ser acessadas e o fluxo de dados pode ser feito com um mínimo de esforço; as fontes de dados NoSQL podem ser acessadas e os dados podem ser transformados automaticamente em tabelas. Se necessário, o desenvolvedor do modelo de otimização pode reformular os dados para preenchimento de outras estruturas de dados durante a otimização, mas essa manipulação não deve afetar os dados de entrada ou saída.

Dados de Saída

Se a sua saída for um arquivo de texto, a função objetiva e os valores das variáveis de decisão serão fornecidos em um formato não estruturado.

Se o seu formato de saída for JSON, ' .csv ou Excel, você deverá definir o que deseja exportar de volta para o cliente no bloco de pós-processamento. O pós-processamento é todo o código que segue a seção subject to no arquivo .mod. Assim, para definir JSON, ' .csv ou saída do Excel, você deve declarar conjuntos de tuplas ou tuplas no pós-processamento.

Se você não declarar elementos de saída no bloco de pós-processamento do arquivo .mod, nenhum dado de saída será gerado.

No exemplo a seguir, o arquivo de saída conterá o valor de Result e NbTrucksOnRouteRes e a função objetiva porque esses elementos são definidos no pós-processamento.

subject to {
   [...]
}

tuple result {
  float totalCost;
}
result Result;

execute {
     Result.objValue = cplex.getObjValue();
}

tuple nbTrucksOnRouteRes {
  key string	spoke;
  key string	hub;
  key string	truckType;
  int			nbTruck;
}
{nbTrucksOnRouteRes} NbTrucksOnRouteRes =
  {<r.spoke, r.hub, t, TruckOnRoute[r][t]> | r in Routes, t in TruckTypeIds :
                                                              TruckOnRoute[r][t] > 0};