LLamasoft Supply Chain Blog

← Back to Blog

Debugging Tools for Network Optimization

By Stella Lee  March 18, 2019


Supply Chain Guru is a tool that is easy to use. Tables and Fields are all pre-populated, and users just need to convert and translate the company data into the information a model need.

When the model gets more complex and contains more data elements, the chances to have an infeasible model increase. The reasons a model is infeasible can be categorized into two:

  1. Model Structure issue. For example, a customer requests a product but there is no defined source for the customer.
  2. Conflicts on the constraints. For example, a customer requests 10 units of a product but the plant can make 8 units max.

Supply Chain Guru equips Verify Model and Infeasibility Diagnosis to help debug the model. The built-in tools are very useful and are able to guide the directions on how to fix the model. However, those tools cannot help as much under certain circumstances.

  1. The model failed before solving stage – After kicking off the model run, there are couple steps at the backend to complete the model run. If the error happens before the solving stage, the infeasibility diagnosis tool cannot do much.
  2. The structure of the model is too complicated – When the model structure is complex such as containing BOMs, multi-periods with inventory or multiple constraints, the suggestions from the infeasibility tool might not indicate the actual causes or might be hard to link to the exact problem sets.
  3. Numerical Issue – The inputs in the model are translating into a series of mathematic formulations. When the problem formulates poor at the backend, numerical issue comes into play, and the debugging tool may not provide the root cause of the error.
  4. It takes too long for infeasibility diagnosis to complete – Infeasibility diagnosis tool is fixing the problem then solving the model with some assumptions. If the model has a lot of decisions to make and takes a long time to run, it will take a similar time to run the infeasibility diagnosis.

Approaches to debug the model manually

There are a few approaches to debug the model manually.

  1. Expand Model
  2. Valid path checking for both Sourcing Policy and Transportation Policy
  3. Run model with a subset of products/customers/sites
  4. Layer in/include one type of constraint at one time
  5. Add a Dummy Site to the network

Detailed explanations and processes are below.

Expand Model

When model building, sometimes it is easier to build the policies and constraints with Groups. However, it makes it difficult for the user to check the tables for missing data. Also, when changing the model inputs in scenarios by scenario items, it can create the wrong content and wrong inputs due to an incorrect filter. Expanding the model will show exactly how Guru sees the scenario design at the back end as it builds the mathematical formula to solve the problem.

Expand model is a built-in Guru functionality. Under the Recent Model panel, there is a button called Expand. Clicking on it will pop up a panel to ask which specific scenario to expand. After selecting the scenario, a new model will be created with the scenario content that is designed to be included, and the group will be expanded.

The user can easily check the inputs this way.

Figure 1 shows where to find the Expand model functionality

Figure 1: Expand model icon. Click here for a larger image.

Valid path checking for both Sourcing Policy and Transportation Policy

How can users make sure the Origin-Destination (OD) combinations in the policies can connect an end customer to the Make site for every product it needs, assuming Verify Model tool doesn’t provide useful information? It can happen with a complicated model.

Users can do a few manual steps to check.

  1. Copy all of the Origin and Product combinations in the policy table as Table a.
  2. Copy all of the Destination and Product combinations in the policy table as Table b.
  3. Do a look up from Table b to Table a. Keep in mind that an Origin in a record needs to be a Destination of another record in order to connect the path.
  4. For any records that in Table a but not in Table b, there are two possible reasons
    1. The site is a Make site of that product
    2. Missing link

Users can look up the Production Policy table to confirm if the site is a make site of that specific product. If it is confirmed to be a missing link, that’s the reason causing the model not working.

Figure 2 shows the steps above in the graphical way.

Figure 2: Policy cross checking process. Click here for larger image.   

If there are BOMs involved, user needs to include the BOM relationship look up. All of the components that make a finished good need to be able to be brought into the site, either from a different location or the site can make the component by itself.

Each sourcing policy and transportation policy represents an OD relationship. One sourcing policy should have at least one corresponding transportation policy with the same OD. After checking the path within the sourcing policy/transportation policy table, it is worth to do a look up to check if the path in sourcing policy exists in the transportation policy.

Run model with subset of products/customers/sites

When the model has a lot of data elements and complexity such as multiple echelons, BOMs, multiple periods with inventory and capacity involved and multiple constraints, it is hard to debug and determine what part of the model is incorrect and what details make the model not working.

It is always easier to understand the model behavior when the model size is small, and the model will solve much faster. Include subset of the products or customers or facilities to make sure it follows the rules, and if the small set of the model is infeasible, it should be easier to check the details of the model.

Layer in/add one type of constraint at each run

A Guru model is mostly optimizing based on costs, but to align to reality, a user layers in a variety of constraints. There are some constraints the user may not aware of as constraints in the model – such as a required demand. When conflicts occur across the constraints, the model will fall into infeasibility. To simplify the model and to identify which type of constraints are causing the issue, layer in one type of constraint at each run. Starting with no constraints and just the basic required tables is suggested.

Remember that it is always easier to start by making a simple feasible model and then make it more complex by adding constraints and other complexities.

Add a Dummy Site to the network

Sometimes users are aware there are potential issues with a model but do not know which exact product/customer/facility is causing the problem. A user can add a dummy site, allowing the site to make all products with a very high cost, and allowing it to connect to all nodes in the network. Since the high cost of sourcing the product from the dummy site, the model will try not to use it unless there is something broken within the original network. Therefore, by using this approach, it should point the user to the issue.  This is another form of Infeasibility Diagnosis, but this approach always allows the model to be infeasible.  Just be sure to always see if the Dummy site is being used when reviewing outputs.

The approaches above combining with the built-in tools should guide users on a good path to solve the problematic model and make the modeling easier.

Like this article? There is more to explore! If you are a current customer, please visit our support site for more practitioner insights. Future customers can request a demo here.