Understanding The Validation Error Report

The validation error report table will be populated for all model solves and contains a lot of helpful information for both reviewing and troubleshooting models. A set of results will be saved for each scenario and every record will report the table and column where the issue has been identified, a description of the error, the value that was identified as the problem along with the action taken by the solver. In the instance where multiple records are generated for the same type of error, you will see an example record populated as the identified value and a count of the errors will be displayed – detailed records can be printed using debug mode. Each record will also be rated on the severity of its impact on a scale from 0 – 3 with 3 being the highest.

The validation error report can serve as a great tool to help troubleshoot an infeasible model. The best approach for utilizing this table is to first sort on the Severity column so that the highest level issues are displayed. If severity 3 issues are present, they must be addressed. If no severity 3 issues exist, the next steps would be to review any severity 2 issues to consider policy impact. It is also helpful to search for any instances where rows are being dropped as these dropped rows will likely influence other errors. To do this, filter the Action field for ‘Row Dropped’.

While the report can be helpful in trying to proactively diagnose infeasible models, it won’t always have all of the answers. To learn more about the dedicated engine for infeasibility diagnosis please check out this article: Troubleshooting With The Infeasibility Diagnostic Engine

Severity 3

Severity 3 records capture instances of syntax issues that are preventing the model from being built properly. This can be presented as 2 types:

• Invalid Scenario Item Action or Condition
  • The identified issue will be reported, please confirm that proper syntax has been followed. You can read more on proper scenario syntax here – Writing Scenario Syntax | Optilogic
• Gurobi Failure Due to Long Variable Names
  • Model Elements such as Customers, Facilities, Products, WorkCenters etc. have long names and when variables are being built by the solver the combination of names is exceeding 255 characters. Reduce long names with shorter versions to resolve this issue

Severity 3 records can also be instances where model infeasibility can be detected before the model solve begins, in the instance where a severity 3 error is detected the model solve will be cancelled immediately. There are 3 common instances of these Severity 3 errors:

• No Lanes to Serve Demand
  • If a valid customer demand record exists and there are no possible transportation lanes that allow for the product to flow into the customer, the model identifies this during the formulation of the demand constraints. Depending on the Lane Creation Rule that you are using for the scenario, you will need to evaluate your Transportation Policies, Customer Fulfillment Polices, or both to address this issue.
• Production / Inventory Ability
  • If a valid customer demand record exists and there is no possible way to introduce the product into the network, either by way of a Production Policies, Supplier Capabilities, or Initial Inventory, the model identifies this during the formulation of demand constraints. Depending on where the product should be originating in your supply chain, you will need to evaluate the appropriate policy table.
• Conflicting Constraints
  • If there are constraints in direct conflict with one another the model will identify this during the constraint formulation. An example of directly conflicting constraints would be MFG_A is required to produce a fixed amount of 20 LB of Product_1, and MFG_A is required to produce a fixed amount of 50 LB of Product_1. These constraints which are in direct conflict can be identified during the problem formulation, constraints which are overly restricting the problem and causing an infeasible solution can still exist outside of these directly conflicting cases and these constraints will be identified in a full Infeasibility Diagnosis run.

Severity 2

Severity 2 records capture sources of potential infeasibility and while not always a definitive reason for a problem being infeasible, they will highlight potential issues with the policy structure of a model. There are 2 common instances of Severity 2 errors:

• No outgoing arc for incoming arc
  • This means that valid flow lanes have been established into a facility for a product but there is no way for the product to exit the facility either through an outbound policy or the ability to hold the product in inventory. This is informing you of a dead-end in the product flow at this facility.
• No incoming arc for outgoing arc
  • This means that valid flow lanes have been established out of a facility for a product but there is no way for the product to enter the facility through an inbound policy, production policy, initial inventory, or supplier capability.

These severity 2 errors don’t necessarily indicate a problem, they can often times be caused by grouped-based policies and members overlapping from one group to another. It is still a good idea to review these gaps in policies and make sure that all of the lanes which should be considered in your solve are in fact being read into the solver.

Severity 1

Severity 1 records will capture issues in model data that can cause rows from input tables to be dropped when writing the solver files for a model. These can be issues on allowed numerical ranges, a negative quantity for customer demand as an example. Detailed policy linkages that do not align can also cause errors, for example a process which uses a specific workcenter that doesn’t exist at the assigned facility. There are other causes of severity 1 errors, and it is important to review these errors for any changes that are made to your input data. Be sure to check the Action column to see if a default value was applied and note the new value that was used, or if a row was being dropped.

Severity 1 records will also note other issues that have been identified in the model input data. These can be unused model elements such as a customer which is included but has no demand, or transportation modes that exist in the model but aren’t assigned to any lanes. There can also be records generated for policies that have no cost charged against them to let you know that a cost is missing. Duplicate data records will also be flagged as severity 1 errors – the last row read in by the solver will be persisted. If you have duplicated data with different detailed information these duplicates should be addressed in your input tables so that you can make sure the correct information is read in by the solver.

A point to look out for is any severity 1 issue that is related to an invalid UOM entry – these will cause records to be dropped and while the dropped records don’t always directly cause model infeasibilities themselves, they can often times be at the root of other issues identified as higher severity or through infeasibility diagnosis runs.

Severity 0

Severity 0 records are for informational purposes only and are generated when records have been excluded upstream, either in the input tables directly or by other corrective actions that the solver has taken. These records are letting you know that the solver read in the input records but they did not correspond to anything that was in the current solve. An example of this would be if you only included a subset of your facilities for a scenario, but still had included records for an out-of-scope MFG location. If the MFG is excluded in the facilities table but its production policies are still included, a record will be written to the table to let you know that these production policy rows were skipped.