Build and Solve

Warning

This task is available on specific request only. Contact us for specific pricing.

The Build/Solve task constructs and solves an optimization problem. This task requires two input files:

  • a dataset showing the problem’s features, which doesn’t need to have a specific structure, it only needs to contain a row for each possible solution.

  • a configuration file, defining the constraints of the problem. A full description of the configuration file, along with its features and syntax is provided in the corresponding section.

After having prepared the configuration file following the provided guidelines, the task itself has a simple configuration layout, made of the Options tab only.

The Options tab

The Build/Solve task requires two input tasks: one containing the problem’s features, and another containing the optimization constraints. When opening the Build/Solve task, the Options tab is the only tab available.

It is divided into two areas:

  • in the left one, users must define the tasks containing the problem’s description and the configuration file. This is possible through the following options:

    • Rule imported from task: specify the task containing the file with the constraints’ definition.

    • Data imported from task: specify the task containing the file with the details which make up the problem.

  • in the area located on the right, users can customize the optimization features through the following options:
    • Optimization mode: specify the solution’s outcome. The possible values are:

      • Minimize (default)

      • Maximize

    • Solver used for optimization: select the solver which will be used for the optimization operation. Possible solvers are:

      • Coin-Or: it is a collection of interoperable open source solvers from the repository of open source software maintained by the COIN-OR Foundation. More information can be found in the website.

      • Symphony: it is an open-source generic MILP solver, callable library, and extensible framework for implementing customized solvers for mixed-integer linear programs (MILPs). More information can be found in the website.

      • Naive: (Rulex proprietary solver) it is faster than the Coin-or and Symphony optimizers, but it provides a less accurate result.

      • SCIP: it is a framework for Constraint Integer Programming. More information can be found in the website.

      • Highs: it is an open-source optimization suite, for sparse linear programming, mixed-integer linear programming and quadratic programming models. More information can be found in the website.

    • Maximum execution time (seconds): specify the solver execution’s time limit in seconds. If not specified, no limits are set.

    • Maximum number of iterations (where 0 means no stopping value): the maximum number of iterations during computation.

    • Stop at first feasible solution: if selected, the optimization operation stops when a solution satisfying all the constraints is found. It might be possible that the solution found is not the best one.

    • Value of priority for stopping iteration (where 0 means no stopping value): the priority value where the loop on the priority will be stopped. If not specified, the loop doesn’t stop.

    • Do not evaluate formula post optimization: if selected, the formulas with the after Application value in the configuration file will not be evaluated when stopping the priority evaluation.

    • Save constraints in cluster: if selected, the sparse input matrix will be saved in a cluster structure. This structure can be visualized by importing it through an Import from Task task.

    • Add auxiliary rows: if selected, auxiliary rows will be added to the output dataset. The auxiliary rows provide information on the auxiliary variables, which have been defined in the configuration file and added during the optimization process.

    • Add feasible column in dataset: if selected, a binary column, called ‘Feasible’ is added to the dataset. The value True indicates that the solution is feasible, while the value False indicates that the solution is unfeasible.

    • Call Naive function in case of unfeasibility: if selected, the task runs a Naive optimization when the algorithm specified in the Solver used for optimization option fails to find a solution within the timeframe defined by the Maximum execution time option.

    • linprogmaxnode: specify the number of feasible solutions which will be considered.

    • firstfeasible: if selected, the algorithm stops evaluating when the first feasible solution is found.

    • linprogabsgap: specify the limit of the absolute cost gap between the feasible solution and the optimal solution.

    • linprogrelgap: specify the limit of the relative cost gap between the feasible solution and the optimal solution.

    • Usewarmstart: if selected, the already existing solution will be used as the starting point to calculate the solution.

Warning

Always remember to save and compute the task.

The Constraints Configuration File

The configuration file must follow a strict setup: it can have any format, (the most commonly used is MS Excel) and it must have two sheets, each of them containing specific information:

Warning

The sheets must follow the order listed above, otherwise the optimization operation won’t make sense.

Tip

The two sheets don’t need to have a specific name, so users can choose the one which fits better according to their needs.

Sheet 1 - Variables definition

The first sheet of the configuration file is the one defining variables. The system will check if the specified attributes satisfy the specified features. The more variables are specified and described, the more precise and reliable will be the optimization output. The sheet name can be customized by the user. The first sheet must contain the following columns:

  • For (optional): definition of a group of variables. It creates n variables, where n is the number of values of the list. The syntax which must be used is @variable_name in [list_of_values]. A formula can also be inserted in the list_of_values field. If the variable is mentioned in the Formula field, it allows creating multiple formulas (according to what has been specified in this field) by simply adding the variables in the formula itself. If the variable is mentioned in the Attribute field, it creates as many attributes as the number of values in the list.

  • Attribute: the name of the attribute which is being defined as a variable. Specify also the attributes which need to be added to the dataset and defined in the Formula column.

  • Role: the role the corresponding attribute is going to play in the optimization process. The possible values are:

    • Key: the task verifies that the attribute is a key. The task verifies that the attribute exists in the input dataset and that each row of the key attribute has a different value. More than one attribute can be specified.

    • Input: attributes containing important information to solve the optimization problem. If no input exists, an error is returned.

    • Solution (mandatory): the attribute representing the solution. This role must be specified. If the attribute does not exist in the dataset containing the problem’s features, it will be created upon the task’s computation. The behavior of the task changes based on whether the column is empty or contains values. See the panel below to know more.

    • Cost: the cost associated to each solution. It indicates the cost value of only one unit of the Solution.

    • Priority: the priority value associated to each row. The priority attribute’s type must be integer, with positive values only, where the value 1 indicates the highest priority, 2 a priority lower than 1, and so on. When a priority is present, the optimization problem is split into multiple optimization problems, which are executed sequentially according to the priority value.

    • Type: the type of the solution generated by the task. If this role is not specified, the type will be taken from the Solution attribute. As the Solution attribute is usually empty, its type can be customized using a Data Manager, before the Build/solve task and linked one to each other. The values in the corresponding Attribute can be:

      • 0: continuous solution

      • 1: integer solution

      • 2: binary solution

    • Minimum: the solution’s minimum value. If not specified, its value is 0.

    • Maximum: the solution’s maximum value. If not specified, its value is infinite.

  • Distinct (optional): the system checks that the attributes specified in the Attribute column values is constant for each attribute value in the Distinct column. More than one attribute can be specified, so the system checks that the attribute is constant for the associated group values. If they are not constant, the system raises an error.

  • Formula (optional): here, any Data Manager formula can be inserted, as well as the IF, THEN, ELSE rule. The results of these formulas will then be used to fill the attribute specified in the Attribute column. This field can be used to define new attributes that must be added to the problems’ dataset when they are not already present. These variables depend on the inputs defined in the Roles column.

  • Application (optional): if a sequence of formulas must be applied, the priority can be specified in this column. The possible values are:

    • (missing value)/ start: if the value is left empty, the evaluation is performed only once, before starting the optimization.

    • before: the variable-formula is calculated at each iteration, before the optimization process.

    • after: the variable-formula is calculated after the end of the optimization process.

    • end: the variable-formula is calculated only once, after the end of the optimization process.

  • Description (optional): a description of the defined variable in natural language. Users can add any description to better understand the variable’s features.

  • Priority (optional): since the priority can be dynamic, this column contains integer numbers defining when functions and constraints in the corresponding row must be calculated while the specified priority is being evaluated by the Build/Solve task.

See also

When the attribute whose role is Solution is provided empty, the task optimizes every row in the problem dataset. Rows with values in the Solution attribute are not recalculated; the task updates only the empty Solution cells. If the Solution attribute is already filled, the task verifies whether its values are feasible or infeasible. If the task generates an auxiliary variable with the define keyword (explained in the paragraph below), it recalculates all Solution attribute values, whether the attribute is already filled or empty.

See also

As said while defining the Formula column, the if, then, else rule can be added. Its syntax is: if condition(s) then true (i.e. the value to display if the condition is satisfied) else false (i.e. the value to display if the condition is not satisfied).

If it is necessary to insert functions in the if then else constraints, it is required to use the ifelse() function. More information on the ifelse function can be found in the corresponding page.

See also

The variables which have their role set as Solution must be used alone or inside a sum or a sumIf function.

The sumIf function follows the syntax: sumIf(var_name, condition). This function performs the sum only when the specified condition is verified.

For example, sumIf($"att_1", $"att_2" > 0) means that the att_1 values will be summed only in the rows where $"att_2" > 0.

Sheet 2 - Constraints definition

The second sheet defines the constraints which must be taken into consideration when the task performs the analysis.

As previously said, the sheet’s name can be customized by the user, but it must contain the following columns:

  • For (optional): definition of a group of constraints. It creates n constraints, where n is the number of values of the list. The syntax which must be used is @variable_name in [list_of_values]. A formula can also be inserted in the list_of_values field. If the variable is inserted in the Constraint field, it allows creating multiple constraints (according to what has been specified in this field) by simply adding the variables in the constraint itself. This way, it is possible to include the group in a unique constraint, without creating multiple ones.

  • Constraint: definition of the constraint using Rulex syntax. Two types of constraints can be added, depending on their aim:

    • variable’s definition: as there are some variables which depend on the solution, and are calculated during the analysis, these constraints define the new attribute starting from the solution. These constraints must be created using the define keyword in the rule. Once created, the defined variable can be used in other constraints.

    • constraints: they are constraints which are applied to the existing variable-solutions or to solution dependent variables. These constraints must be created using the let keyword in the rule.

  • Description (optional): a description of the constraint in natural language. Users can add any description to better understand the constraint’s features.

More information on keywords and on the constraints’ syntax is provided in the paragraph below.

See also

When the for keyword is used in combination with a define keyword, a new attribute is added to the output dataset, whose name will be the @variable_name defined in the for column, and the values will be those defined in the [list_of_values] associated with the corresponding iteration variable defined in the for column.

Constraints syntax

The following keywords must be taken into consideration while writing a constraint, as each one of them gives specific directions to the system to calculate the best solution:

Keyword

Description

Example

when

It works as a filter, specifying the object’s features and excluding data which may not satisfy the condition from the constraint. It is possible to use all the Data Manager conditions.

when $"Att_1" < "5"

foreach

It is used to check a group of constraints. Attributes specified after the foreach keyword are used to divide the dataset values in groups, and a constraint for each group of values.

  • foreach $"Attr_1"

  • foreach ($"Att_1",$"Att_2")

forevery

When used to check ordered attributes, it emulates the behavior of a moving window made of the number of values specified in the overlap parameter of the chosen attribute. The number specified after the forevery keyword indicates the number of values of the moving window. When it is used to check nominal attributes, it evaluates all the possible combinations, without repeating them: for example, if the combination A, B has already been evaluated, the combination B A won’t be taken into consideration.

  • forevery 3 $"quantity" overlap 2 (ordered values in the $"quantity" attribute)

  • forevery 2 $"material" (when nominal values are present in the $"material" attribute)

overlap

It specifies the shift values of the ordered attributes checked with the forevery parameter. Its values must be ordered.

forevery 3 $"quantity" overlap 2

define

It introduces an auxiliary variable, which can be defined through a formula. The variables created through this keyword are strictly tied to the solution: their values remain unspecified until the optimizer has solved the problem. The variable syntax must be define $"New_variable" =.
It is always possible to define variables by using mathematical expressions or conditions, by leaving them empty (e.g. define $"Newvar"), by giving it a fixed value (e.g. define $"Newvar" = 1). When defining solutions, solution vectors can be built. Refer to the panel below to know more about it.
In the old formulation, all the solution must have been located at the left of the ``=``, now only the variable which is being defined must be located at the left of the ``=`` operator. Make sure you convert the syntax if you have used the Build/Solve before the XXX.

define $"NewSol" >= sum($"Solution")

let

It introduces a constraint which must contain a comparison operator. All variables (those which have their role set as Solution and those which aren’t a Solution) can be located both on the left and on the right of the comparison operator. All the elements of the constraint must be linear in their variables, so they can only contain a sum or a difference between them.

let sum($"Moved") <= max($"New(Supply)")

See also

When using the keyword define, solution vectors can be built. It is not possible anymore to create recursive definitions on the same variable. If this happens, an error is raised. This means that the same solution name can be used, along with an ID or a string, transforming the solution from scalar to vectorial. This means that the solution introduced by the keyword define must be written according to the following syntax: define $"NewSol" [0] = $"Solution" or define $"NewSol" [1] = $"NewSol" [0] + $"Solution" if the $"NewSol" name will be used. The same variable name can be used, but its tag must change, and it must be enclosed into square brackets. If a variable containing the same name and the same tag enclosed in square brackets is used after the define keyword, the system raises an error.

Hint

After having defined solution vectors, they can then be used together only with the sum and sumIf operators by simply enclosing the tags into the square brackets, using a comma to separate them. For example, by writing sum($"NewSol" [1,2,"test"]), the variables $"NewSol" [1], $"NewSol" [2], $"NewSol" ["test"] will be summed. Alternatively, users can specify all the vector’s elements by simply specifying the : into the square brackets. For example, knowing that the $"NewSol" [1], $"NewSol" [2], $"NewSol" ["test"] variables exist, users can simply write $"NewSol" [:] to specify all three.

Warning

When using the sum operator combined with the foreach keyword, different effects on the constraint definition are applied: two different operations are performed, according whether the sum operator has been used or not.

  • If the constraint does not include the sum operator, the system performs a contracted group operation, and the first row of each group is taken into consideration without performing the sum. (e.g. foreach $"Date" let $"Solution" >= 0)

  • If the constraint does include the sum operator, the system performs an expanded group operation, so the sum is performed within each group (e.g. foreach $"Date" let sum($"Solution") >= 0).

The two operations explained above can also be mixed when building the constraints.

Make sure you convert the constraints to this syntax if you have used the Build/Solve task before XXXX.

The keywords listed below are auxiliary ones, so they are not mandatory.

Keyword

Description

Example

cost (evaluated when the keyword let or define is present)

It is the cost related to the corresponding constraint. When a define statement is present, it is the unit cost of the auxiliary variable. In the other cases, it is the cost of the constraint that is added to the overall cost when the constraint is violated. A Data Manager formula can be inserted.

cost $"DestCost"

minimum or min (evaluated when the keyword define is present)

It is the auxiliary variable’s minimum value. A Data Manager formula can be inserted.

  • minimum 0

  • minimum mean($"cost")

  • min 3

  • min mean(S"income")

maximum or max (evaluated when the keyword define is present)

It is the auxiliary variable’s maximum value. A Data Manager formula can be inserted.

  • maximum 8

  • maximum max($"cost")

  • max 5

  • max mean($"income")

tolerance or tol (evaluated when the keyword let is present)

It indicates the allowed tolerance value, according to the set parameters. It indicates the allowed error, how much the constraint can be violated.

tol 4

type (evaluated when the keyword define is present)

It is the auxiliary variable’s type. It can be defined with a Data Manager formula or with the following values:

  • 0: continuous type.

  • 1: integer type.

  • 2: binary type.

type 2

center (evaluated when the keywords forevery and overlap are present)

It is the identifier of the window. The order is 1-based and its value must be integer and smaller than the window’s dimension. If the keyword center is specified without any value, the default value will be 1. This keyword can be used before or after the overlap keyword.

  • forevery 3 $"Day" overlap -1 center 2

Warning

If you are migrating from the old version of this task (released before XXXXX), make sure to check the configuration file, so that the constraints are written correctly.

If a file containing constraints written with the old syntax is used, the system raises an error upon task computation.

Important

While writing the constraint, the following keyword order must be followed in the string:

  1. when

  2. foreach

  3. forevery

  4. overlap (if the attribute in the forevery parameter is ordered)

  5. define or let

  6. all the other keywords left

See also

Two possible rules can be:

  • when $"Att_1" == "A" foreach ($"Items",$"Month") define $"Attr_1 in Month" = if sum($"Solution") >= 1 then 1 else 0 maximum 1 cost 1

  • when $"$January" ==1 foreach ($"Order_numer",$"Revenue") let sum($"Solution") >= $"Minimum_Revenue_January"