Capacity Expansion (Network Optimization)

Capacity Expansion enables Cosmic Frog’s network optimization engine (Neo) to determine when, where, and how much additional capacity should be added across your supply chain while optimizing the entire network. It helps answer questions such as:

• Should we expand the storage at the existing distribution centers (DCs) or lease more space?
• We need to ramp up labor at some DCs, at which DCs and to which level is this overall most cost-effective?
• Should we expand our current production lines, or do we need to add new lines?

Instead of manually deciding where capacity should be increased, you can define the available expansion options and their associated costs. During optimization, Neo evaluates whether expanding capacity is economically beneficial compared to other alternatives, such as using existing facilities, opening new facilities, adding new production lines, changing transportation flows, or accepting unmet demand.

Capacity Expansion can be modeled for:

• Facility throughput capacity
• Facility storage capacity
• Work center throughput capacity
• User-defined variables – for example in the case where a one-time cost needs to be applied if a transport lane goes over a certain flow quantity.

This video briefly explains the Capacity Expansion feature and walks through a life-size example model:

This model is also covered in the Capacity Expansion Example Model section further below, which includes a deeper dive into outputs and additional sensitivity analysis scenarios around demand.

Quick Start

If you just want to get going with Capacity Expansion as quick as possible, follow these steps:

1. Define expansion costs: create the available capacity levels and associated costs in the Step Costs table. Use a separate Step Cost Name for each expansion cost structure.
2. Define what can expand: add records to the Capacity Expansions table. Specify the entity, Expansion Type, Expansion Cost, Max Expansion Units, and—if needed—Earliest Expansion Period.
3. Run Neo: run the optimization. If the applicable Capacity Expansions records have Status = Include, Capacity Expansion is automatically considered; no additional model option is required.
4. Review the decisions: review the Optimization Capacity Expansion Summary output to see where and when Neo selected an expansion, the resulting expansion activity and utilization, the expansion cost, and the next available capacity level.

Why Capacity Expansion Matters

Supply chain networks do not remain static. Demand changes, product mixes shift, and manufacturing or distribution requirements can move between regions. As a result, capacity that is sufficient today may not be sufficient in future periods.

Without Capacity Expansion, future capacity is typically modeled by manually creating scenarios with different fixed capacity levels. This can require significant effort and may overlook lower-cost alternatives.

Capacity Expansion lets Neo consider additional capacity as an optimization decision. You define the expansion options and their associated costs, and Neo determines whether an expansion is justified as part of the overall network solution.

This allows capacity decisions to be evaluated together with sourcing, production, inventory, transportation, and facility decisions rather than in isolation.

When to Use Capacity Expansion

Use Capacity Expansion when additional capacity is a possible investment and you want Neo to determine whether, when, and how much capacity should be added.

The following are common situations where Capacity Expansion may be appropriate:

Capacity Expansion can be modeled for facility throughput capacity, facility storage capacity, work center throughput capacity, and user-defined variables.

Rule of thumb question:Is additional capacity an option that Neo should decide on, rather than a change that I have already decided will happen?

• Yes: Capacity Expansion is likely the right tool.
• No: If the capacity change is already predetermined, consider modeling the change directly using the appropriate capacity or multi-time period inputs.

How Capacity Expansion Works

Capacity Expansion uses two input tables:

The optimization process is:

1. Define one or more Step Costs table entries describing expansion cost tiers.
2. Reference those step costs in the Capacity Expansions table.
3. Run the optimization.
4. Neo determines if and when capacity should be expanded to minimize total network cost.

‍

Configuring Capacity Expansion

Defining Expansion Costs

Capacity Expansion uses the Step Costs table to define available expansion levels and their associated costs.

Each Step Costs definition contains one or more capacity thresholds and the cost associated with reaching that threshold.

During optimization, Neo evaluates these cost tiers and selects the option that minimizes overall network cost.

For example:

This set of capacity threshold and associated expansion cost steps specifies that:

• For throughput/storage between 0 and 1,000, no expansion cost will be applied – this is implied and a specific record to specify this is not required.
• For throughput/storage between 1,000 and 1,500, an expansion cost of $20,000 will be applied.
• For a throughput/storage between 1,500 and 2,000 an expansion cost of $40,000 will be applied.
• For a throughput/storage over 2,000 an expansion cost of $60,000 will be applied. A hard upper limit to the capacity is set on the Capacity Expansions input table, see below.

Rather than requiring the modeler to choose which tier to use, Neo automatically determines whether purchasing additional capacity at what level most reduces the total network cost.

The above tier structure for throughput/storage level and associated expansion cost is entered into the Step Costs table as follows:

The columns from left to right:

1. Step Cost Name – all records that specify the capacity expansion - cost structure for 1 entity, need to have the same Step Cost Name. Here we are specifying the capacity level – expansion cost relationship for a work center named WC1 and have therefore named the step cost WCExpansion.
2. Step Cost Behavior – always set to Stepwise for capacity expansion.
3. Throughput Level – the Throughput/Storage Level from the above example. Note that there is a UOM field (not shown) associated with this Throughput Level field; it is set to EA (i.e., per unit) for all records in this example.
4. Cost – the Expansion Cost from the above example.

Capacity Expansions Input Table

The Capacity Expansions input table associates the throughput/storage level - expansion cost tiers specified in the Step Costs table with the correct entities. Additionally, the type of expansion, the maximum capacity limit, and from when expansion is allowed are configured here too.

Each row in the table represents one entity whose capacity may be expanded.

Expansion Types

The Expansion Type column supports the following values.

‍

Using the WCExpansion capacity – expansion cost tiers set up in the Step Costs table above, a record that allows a Work Center to expand can look as follows in the Capacity Expansions table:

The columns from left to right:

1. Entity Name – set to WC1, the name of the work center that is allowed to expand
2. Expansion Type – set to WorkCenterThroughputCapacity as we want to consider expanding the capacity of a work center.
3. Expansion Cost – set to WCExpansion; this ensures the 3 records that are shown in the Step Costs table screenshot above, which all have Step Cost Name = WCExpansion, are used as the capacity level – expansion cost tiers Neo can optimize on.
4. Max Expansion Units – the maximum throughput capacity of the Work Center in the highest tier (after incurring $60k in expansion costs) is 2,500 units.
5. Earliest Expansion Period – work center WC1 is allowed to expand from the period named P2 onwards.

‍

Viewing Results

After optimization, the selected capacity expansion decisions are written to the Optimization Capacity Expansion Summary output table.

Each row represents the expansion details of one entity for one scenario-period combination.

Key output fields include:

Example output for scenario using above capacity-cost structure to allow WC1 to expand:

The Scenario Name, Work Center Name (WC1), and Expansion Type (Work Center Throughput Capacity) columns are omitted in this screenshot as they have the same value for all 4 records. The other columns from left to right are:

1. Expansion Period – the period to which the record applies, one record for each of the 4 periods (P1-P4) in the scenario.
2. Expansion Cost – this work center was expanded in period P2 for a cost of $20,000 and then again in P4 for another $20,000 (cumulative expansion cost of $40,000). No expansions occurred in P1 and P3.
3. Expansion Activity Quantity – the throughput level of WC1 for each period in quantity units (also listed in volume and weight units; these columns are not shown in screenshot). We see that after expansion in P2, the throughput goes up to 1,300 in P2 and 1,500 in P3, the latter is the maximum in this tier. Then to go up to 1,800 in P4, the second expansion is necessary. Going beyond 2,000 would require another expansion to the last tier but is not required in this example.
4. Next Expansion Level – this indicates the maximum capacity that will be available after incurring the next tier’s one-time expansion cost.
5. Current Step Capacity – the maximum capacity of the current tier. In period P1 (before the expansion in period P2), the throughput capacity was 1,000. After expansion in period P2, the throughput capacity has become 1,500 and stays at that level until the final capacity expansion in P4 which brings it up to 2,000.

Tips and Best Practices

Capacity Expansion is Automatically Enabled

No additional model option is required.

If the Capacity Expansions table contains one or more rows with Status = Include, Capacity Expansion is automatically considered during optimization.

Define Step Costs before Capacity Expansions

The Expansion Cost column references a Step Costs entry by name. If the referenced Step Costs entry does not exist, preprocessing will fail.

Set Realistic Maximum Expansion Limits

Max Expansion Units represents a hard upper limit.

If the model requires more capacity than this limit allows, demand may need to be satisfied using other network alternatives or the model may become infeasible.

Comparing to a Baseline without Expansion Options

1. If a Baseline scenario specifies Throughput/Storage Capacities on the Facilities/Work Centers table(s), set these values to blank ('') in scenarios that use capacity expansion options. A fixed capacity otherwise caps the entity, regardless of the options defined in the Capacity Expansions table. Blanking the value removes this ceiling and lets the expansion logic determine capacity.
2. Set Capacity Expansions records to Status = Exclude in the Baseline scenario and switch them to Status = Include through a scenario item in scenarios that use the expansion options.
   1. Note: Step Costs defining the throughput-level/cost structure for an expansion can have Status = Include. They are only used when the Capacity Expansions record referencing them has Status = Include.

Encourage Capacity Expansions to Occur as Late as Possible

Because expansion costs are one-time investments, the Neo engine may apply an expansion earlier than expected if there is no incentive to delay it. To ensure expansions occur as late as possible, introduce costs that discourage early investment. For example:

• Storage capacity: Ensure holding pre-build inventory incurs a cost by using non-zero product values and inventory carrying costs and/or a non-zero unit storage cost.
• Throughput capacity: Increase other non-variable costs when capacity is expanded, such as facility/work center fixed operating costs. For example, define the same throughput-level breaks in the Step Costs table and reference the Step Cost Name in the Fixed Operating Cost field on the Facilities/Work Centers table(s).

Filter Optimization Capacity Expansion Summary for non-0 Expansion Cost

To quickly see which entities are expanded when, use a Greater Than filter with value of 0 in the Expansion Cost field on the Optimization Capacity Expansion Summary table. This resulting grid only shows records where an expansion occurred.

Capacity Expansion vs. Incremental Change

Capacity Expansion and Incremental Change can both be used to model how a network evolves over time, but they solve different problems.

Capacity Expansion gives Neo the option to add capacity and lets the optimization determine whether, when, where, and how much capacity to add, based on the available expansion options and their costs.

Incremental Change controls the pace and sequence of network changes over time. It is designed to make a transition between network states more practical by limiting how much certain types of change can occur from one period to the next. The Incremental Change Constraints table defines the change type and the change budget for each period.

For example, suppose demand is expected to increase, and a work center may eventually need more capacity. Capacity Expansion can allow Neo to decide whether the work center should be expanded, and which expansion level is most economical.

If the resulting network also needs to be implemented gradually—for example, production cannot increase too quickly from one period to the next—Incremental Change can be used to constrain the rate of that transition. Incremental Change currently supports changes such as facilities opened or closed, suppliers added or removed, production increases or decreases, and lanes added.

In short:

Capacity Expansion determines the capacity investment decision; Incremental Change controls how quickly the network can transition.

The two capabilities therefore address different aspects of network evolution and are useful together when both the capacity decision and the pace of implementation need to be modeled.

Capacity Expansion Example Model

This example model shows how Capacity Expansion can be used to determine whether the current supply chain network has sufficient capacity to support projected demand from 2027 through 2031 and, if not, to identify the most appropriate and cost-effective capacity expansion strategy. Using several scenarios, the model determines:

• When and where to add DC storage capacity.
• Whether existing production lines should be expanded, or if an additional factory should come online, or a combination of both.
• The scenarios also determine optimal timing for these events.

Sensitivity analysis around demand growth is performed on the best-looking scenario.

This example model, “Capacity Expansion”, can be copied from the Resource Library if you want to follow along: Capacity Expansion resource.

Capacity Expansion Model – Inputs

The Capacity Expansion model is derived from the Global Supply Chain Strategy model from the Resource Library (here) and has been modified to demonstrate Capacity Expansion functionality.

Network Structure

Materials flow through the network as follows:

1. Local Suppliers (6 European, 3 Chinese) → 2 Overseas Ports (Raw Materials)
   • Rotterdam (Europe)
   • Shanghai (China)
2. 2 Overseas Ports → 2 North America Ports (Raw Materials)
   • Charleston Port (USA)
   • Altamira Port (Mexico)
3. 2 US / Mexico Ports → 2 Factories (Raw Materials)
   • Princeton Factory (USA)
   • El Bajio Factory (Mexico)
4. 2 Factories → 7 Distribution Centers (Finished Goods)
   • 7 U.S. DCs serving 1,333 customers

The model also includes potential West Coast expansion locations:

• Los Angeles Port
• Reno Factory

These facilities are evaluated in selected scenarios.

The following map screenshot shows the port, factory, DC, and customer locations in North America, with the current (2026) port to factory and factory to DC flows drawn:

Production

The 9 raw materials are brought into the factories and turned into 3 finished goods on product-specific production lines (Work Centers). Bills of materials are used to specify how much of each raw material is used to produce a unit of a finished good. The following table summarizes current and future production options:

Basic Model Adjustments

Several changes were made to the base model to support the capacity expansion options and the consideration of the West Coast locations:

In addition, the Step Costs and Capacity Expansions tables are populated in order to model the possible DC Storage Capacity and Work Center Throughput Capacity expansions in several scenarios. These are discussed in more detail in the next 2 sections.

Step Costs Input Table

The Step Costs table contains several sets of records with following step cost names:

• StorageCapacityDet, StorageCapacityPhil, StorageCapacitySanB: these sets specify storage thresholds and accompanying expansion costs for the Detroit DC, Philadelphia DC, and San Bernardino DC, respectively.
  • These will be used as the Expansion Cost value on the Capacity Expansions input table.
• ThroughputCapacityElBajioRocketsWC, ThroughputCapacityPrincetonSpaceSuitsSC: these sets specify throughput thresholds and corresponding expansion costs for the Rockets line at the El Bajio factory and the Space Suits line at the Princeton factory, respectively.
  • These will be used as the Expansion Cost value on the Capacity Expansions input table.
• ElBajio_Rockets_FixedOperatingCosts, Princeton_SpaceSuits_FixedOperatingCosts: these sets specify the operating costs for the Rockets line at El Bajio and Space Suits line at Princeton. Their throughput thresholds match those of the expansions: an expansion incurs a one-time investment (expansion cost) to go to the next level, and to operate at that higher tier, the on-going operating costs are higher too. This encourages the model to expand a production line as late as possible.
  • These are used as the FixedOperatingCost on the Work Centers table.

This screenshot shows the configuration of the Fixed Operating Costs and Expansion Costs of the Rockets line at the El Bajio factory:

1. These 4 records together specify the fixed operating costs for the Rockets line at the El Bajio factory:
   1. To tie the records together, they all have the same Step Cost Name of ELBajio_Rockets_FixedOperatingCosts.
   2. The Throughput Level and Cost pairs specify that between a throughput of 0 (row 1) and 700k units (row 2) per quarter, the fixed operating cost is $225k/quarter (row 1), for a throughput between 700k-760k/quarter units, the fixed operating cost is $270k/quarter, etc. To go over 820k units per quarter, the cost goes up to $820k/quarter.
   3. The Status of these records is set to Include, so they are used when a record on the Work Centers table uses them.
2. These 3 records together specify the expansion options at the El Bajio Rockets line:
   1. They all have the same Step Cost Name of ThroughputCapacityElBajioRocketsWC.
   2. The Throughput Level and Cost values specify that up to a throughput of 700k units/quarter, no expansion cost needs to be incurred. To go over 700k units and up to 760k units maximum, an expansion cost of $300k will be incurred once. To bring the throughput up to between 760k and 820k units/quarter, another one-time expansion cost of $300k needs to be incurred. The expansion cost at this tier is specified as $600k since that is the total accumulated expansion cost for this level. When jumping from below 700k units to in between 760-820k units from one quarter to the next, this $600k cost is incurred.
   3. The Status is set to Include, meaning that if this cost is used on an included record in the Capacity Expansions table, this cost structure is used. The Notes field is set to “WC Throughput” to allow for easy filtering of this table and for use in a condition for a scenario item.

Capacity Expansions Input Table

1. The first 2 rows in this table specify the work center throughput capacity expansions that will be allowed for the El Bajio Rockets and Princeton Space Suits lines. They use the Step Cost Name we saw in the previous screenshot as the Expansion Cost. In addition, Max Expansion Units indicates they cannot expand beyond 880k, and 820k units, respectively, Earliest Expansion Period sets the expansion is allowed from the first quarter of 2027 onwards, and the Status is set to Exclude to be change to Include in scenarios where these lines are allowed to expand.
2. Similarly, these 3 records set up the storage capacity expansions allowed at Detroit, Philadelphia, and San Bernardino DCs. These are also allowed from period 2027_Q1 onwards and are set to Status = Exclude by default.

Summary of Modeled Costs

The table below summarizes the different costs that are included in the model:

Summary of Modeled Constraints

Following table provides an overview of the constraints used in the model:

Capacity Expansion Model – Scenario Storyline

Objective

The objective of the scenario analysis is to determine whether the current supply chain network has sufficient capacity to support projected demand from 2027 through 2031 and, if not, to identify the most appropriate and cost-effective capacity expansion strategy.

Story at a Glance

The analysis follows a progressive scenario-building approach. Each scenario builds on the findings of the previous scenario(s), allowing the capacity requirements and potential expansion strategies to be evaluated step by step.

The overall storyline is:

1. Test the current network against future demand
The current network (0 Baseline 2026 scenario) is tested against projected 2027–2031 demand. The resulting 0 Baseline 2026-2031 scenario is infeasible, confirming that additional capacity is required.

2. Identify where capacity is insufficient
An Infeasibility Check and analysis of outputs of the 0 Baseline 2026 scenario identifies the main constraints. Three DCs — Detroit, Philadelphia, and San Bernardino — are consistently at maximum storage capacity, while two production lines show high utilization: Rockets at El Bajio and Space Suits at Princeton.

3. Address the distribution capacity constraints
Based on these findings, storage capacity at Detroit, Philadelphia, and San Bernardino is allowed to expand and this option is carried forward into all subsequent scenarios.

4. Evaluate alternative production capacity strategies
Two main approaches are compared:

• Expand the existing high-utilization production lines (scenario 1 Existing Line Expansion).
• Add a new Reno factory capable of producing Space Suits, Rockets, and Consumables.

Different Reno start dates (from 2027, scenario 2a, and from 2028, scenario 2b) are also tested to understand the impact of factory startup lead-time.

5. Select the preferred production strategy
The initial comparison shows that **Reno available from 2027 (**scenario 2a) has the lowest cost of the individual alternatives tested. The combined strategy of **Reno from 2027 plus existing-line expansion (**scenario 3) then produces a further, albeit small, cost improvement.

6. Take the combined strategy forward
Scenario 3 Consider Reno from 2027 PLUS Existing Line Expansion is therefore selected as the preferred configuration for further analysis.

7. Test the robustness of the preferred solution
Finally, sensitivity scenarios 4a–4d test how the preferred network configuration performs when demand differs from the forecast by −10%, −5%, +5%, and +10%.

Overall conclusion

The analysis therefore moves from:

“Is the current network sufficient?”

to:

“Where are the capacity constraints?”

to:

“What capacity expansion strategy provides the best solution?”

and finally, to:

“Is the preferred solution robust if demand differs from the forecast?”

The detailed sections that follow below provide the scenario results, screenshots, capacity constraints, cost comparisons, and sensitivity results supporting each step of this decision process.

Capacity Expansion Model – Scenario & Output Details

This table summarizes the scenarios:

The Scenarios module in the Capacity Expansion model in Cosmic Frog looks as follows. Scenario 3 is expanded, and its 7 scenario items are shown:

When running scenarios, on the Run Settings modal we need to pay attention to 3 parameters:

1. The “0 Baseline 2026-2031 Infeasibility Check” scenario is run with the Check Infeasibility option enabled; for all other scenarios this option is left disabled.
2. All scenarios have the MIP Relative Gap Percentage reduced to 0.000001 from the default of 0.0001 in order to have the scenarios run to a low enough gap where solutions that are close to each other in cost are not considered equivalent solutions.
3. All scenarios have the Logical Constraints troubleshooting option toggled on as this reduces scenario runtimes for the scenarios in this model.

1. Starting Point: Current Network

Scenario: 0 Baseline 2026

This scenario represents the current supply chain network and capacity configuration and provides the baseline for the analysis.

The key question is:

“Can the current network support the projected demand for 2027–2031 without additional capacity?”

To answer this, projected demand for 2027–2031 was applied to the existing network.

Result

The resulting scenario, 0 Baseline 2026-2031, is infeasible.

This indicates that the existing network does not have sufficient capacity to meet the projected demand throughout the 2027–2031 planning horizon.

See the “Capacity Story 1 – 2026 Capacity” dashboard in the Analytics module which looks at scenarios 0 Baseline 2026 and 0 Baseline 2026-2031. At the top the overall demand, existing line capacity and the 2026 Baseline total cost are summarized. Beneath these statistics is a table summarizing the 2 scenarios in terms of solve status, total cost, and total demand units served.

Four charts then follow:

We can for example already calculate that the total Rockets capacity will not be sufficient to meet the demand:

• The total 6-year demand for Rockets comes to just under 18M units (aggregated quantities for Rockets on the Customer Demand table).
• The total 6-year capacity with the 1 Rockets line at the El Bajio factory is 6 * 4 * 700k = 16.8M units.
• There is no initial inventory modeled.

2. Identify the Sources of Infeasibility

Scenario: 0 Baseline 2026-2031 Infeasibility Check

An Infeasibility Check was performed on a copy of the 2027–2031 baseline scenario to identify which capacity constraints are driving the infeasibility. And just above we have seen where capacity is at a high utilization already during 2026.

See the “Capacity Story 2 – Capacity Shortages 2027-2031” dashboard in the Analytics module. At the top are 2 maps showing DC storage capacity utilization and work center throughput capacity utilization by location in the 0 Baseline 2026 scenario. This shows the same data as the last 2 charts of the first dashboard discussed above, but now on a map.

The next chart in the dashboard shows the extra capacity that would be needed by quarter. For DCs this means additional storage capacity and for factories additional production line capacity:

To get a sense for how much additional capacity is needed as compared to what is available today, the following chart showing the peak shortfall as compared to the capacity limit is part of the dashboard too:

The details of what capacity had to berelaxed when and by how much are also included on a table at the bottom of thedashboard:

In summary, the analysis identified two main areas of concern:

1. Distribution capacity

Three Distribution Centers (DCs) consistently operate at their maximum storage capacity across all quarters:

• Detroit DC
• Philadelphia DC
• San Bernardino DC

Decision:
Storage capacity at these three DCs is allowed to expand in all subsequent scenarios.

2. Production capacity

Two production lines also show high utilization:

• Rockets line — El Bajio Factory
• Space Suits line — Princeton Factory

These constraints indicate that additional production capacity may be required, and at this point two strategic alternatives will be considered:

1. Expand the existing 2 most constrained production lines.
2. Add a new factory in Reno with optional production for all three finished goods.

3. Evaluate Production Capacity Options

Option 1: Expand Existing Production Lines

Scenario: 1 Existing Line Expansion

This scenario addresses the production constraint by allowing the two existing lines with high utilization to expand:

• Rockets at El Bajio
• Space Suits at Princeton

No new factory is introduced.

Option 2: Add a New Factory in Reno

A second strategy is to introduce a new factory in Reno, capable of producing all three products.

Because a new factory requires a start-up lead time, two scenarios are evaluated:

Scenario: 2a Consider Reno From 2027

Reno is available from Q1 2027.

This represents an optimistic assumption in which the new factory can be operational from the beginning of the planning horizon.

Scenario: 2b Consider Reno From 2028

Reno becomes available from Q1 2028.

This represents the more realistic timing assumption based on the expected lead time required to establish the new factory.

4. Cost Comparison of the Production Strategy Scenarios

In the outputs (the Optimization Facility Summary output table), we see that the Reno Factory opens as soon as it is allowed to in both the 2a and 2b scenario (2027 Q1 and 2028 Q1, respectively).

The total cost of the three scenarios is ranked as follows, see the Optimization Network Summary output table:

The results show that bringing Reno online from 2027 produces the lowest cost among the initial production capacity alternatives.

Although opening Reno in 2028 is operationally more realistic, its later availability results in a higher overall cost.

Decision:

The analysis proceeds with the assumption that Reno should be considered as available from Q1 2027 in the subsequent scenarios.

5. Evaluate Costs of a Combined Capacity Strategy

Scenario: 3 Consider Reno from 2027 PLUS Existing Line Expansion

The next question is whether the optimal strategy is to combine both approaches:

• Allow the Reno factory to open from Q1 2027.
• Allow expansion of the existing high-utilization production lines at El Bajio and Princeton.
• Continue with the previously identified DC storage expansions at Philadelphia, and San Bernardino (Detroit is never expanded, see next section).

Result

The combined strategy produces a slightly lower overall cost of $2,147.42M than 2a Consider Reno From 2027, which was previously the lowest-cost scenario:

This indicates that combining new capacity in Reno with targeted expansion of the existing production lines provides a better overall network solution than relying on Reno alone.

Decision

Scenario 3 is therefore selected as the preferred scenario for further sensitivity analysis.

See the “Capacity Story 3 – Expand and Add Capacity 2027-2031” dashboard in the Analytics module for more high-level details of scenarios 1, 2a, 2b, and 3. At the top, a table and 2 charts summarize the scenarios by total costs and by cost type.

The next chart and table focus on capacity expansion costs and timing:

Three more charts on this dashboard show production by quarter: by factory comparing scenarios 1 and 3, and for scenario 3 also a chart that shows throughput for the new Reno production lines.

6. Deep Dive into Expansion Outputs

First, we will look at different charts and output tables to see when and where expansions occur, next summarize these in a table, and finally explain the expansion decisions.

The example model contains a dashboard named “Capacity Expansion – Expansion Costs by Scenario and Period” in the Analytics module. It contains 2 charts:

• Total Expansion Cost by Scenario: for the 4 feasible 2026-2031 scenarios, all allowing certain expansions, the total expansion costs color-coded by entity are compared.
• Expansion Costs by Period: the user can pick the scenario to look at, and for each period where an expansion occurred, a bar chart indicating the cost and entity is shown.

‍

The “Total Expansion Cost by Scenario” chart for scenarios 1, 2a, 2b, and 3 looks as follows:

To drill into period-specific details, we use the “Expansion Costs by Period” chart, here filtered for scenario 1:

We can also see these details for all scenarios in table form in the Optimization Capacity Expansion Summary output table, which is filtered for Expansion Cost > 0 here:

To get the full picture, we also check if any existing lines close, and if so when. In addition, we can check if all 3 potential production lines at Reno are being used and, if so, from the first possible option (2027_Q1) or later. This screenshot filters the Optimization Work Center Summary output table for scenarios 2a and 3 and Startup Cost > 0:

And here is the Optimization Work Center Summary output table again, still filtered for scenarios 2a and 3, but now also for Closing Cost > 0:

For storage capacity expansion at the DCs, in all 4 scenarios (1, 2a, 2b, and 3):

• Storage capacity at both Philadelphia and San Bernardino is expanded – this is expected as both were at 100% utilization during 2026 and demand increases in 2027-2031.
• Storage capacity at Detroit is not expanded, even though it was also at 100% capacity during 2026. This was however a result of Philadelphia being maxed out: Detroit was one of the main DCs to store what Philadelphia could not fit anymore. See also the following 2 map screenshots which illustrate this point: the first map shows customer flows from the Detroit, Philadelphia and Atlanta DCs in scenario 1 for the last quarter of 2026 when Philadelphia is not yet expanded, and the second map shows the same but for the first quarter of 2027 in which the Philadelphia DC is at its expanded 320k level:

Next, we will focus on scenarios 1, 2a, and 3 as we have seen 2a is preferred over 2b and explain the drivers behind the differences in expansions. We will start with a summary of the scenarios and their results:

Why San Bernardino expands to 250k in scenarios 2a and 3

The Reno Factory opens in scenarios 2a and 3 and due to its proximity, San Bernardino services a lot more customer demand since the overall cost is reduced due to the much lower inbound costs. Note that in scenario 3, Rockets do still come from the El Bajio Factory.

Why Philadelphia expands to 320k in scenarios 1 and 3 and to 260k in scenario 2a

Philadelphia’s upgrade costs an extra $330k to go from 260k to 320k. How much it saves differs by scenario:

• Scenario 1: the Philadelphia expansion is purely a transport decision. Philadelphia ships about 1.1M more units over 2027-2031 if it is at the 320k level as compared to 260k. This is mostly to Maryland, Virginia, Pennsylvania and New York customers. Outbound savings of ~$3.5M outweigh ~$3.2M more in replenishment, a net of about $353k against the $330k cost to go from 260k to 320k. Pre-build is not part of the reason: the stock behind Philadelphia’s extra shipments (about 264–316k) already fits within 320k, and the El Bajio Rocket expansions and total pre-build cost are the same with or without this additional Philadelphia expansion.
• Scenario 2a: opening Reno makes San Bernardino cheap to serve from, so it serves about 1.2M more units than in scenario 1 and expands to 250k. This slightly reduces stretched assignments elsewhere, including a few East DCs, leaving less for a Philadelphia expansion to fix: it would save about $318.5k against the $330k extra expansion cost, so 3.5% short. This accounts for about $18k of the $35k gap to scenario 1; the rest is not due to 1 single cause.
• Scenario 3: the additional Philadelphia expansion is worth about $431k (against its $330k cost): roughly $320–335k from similar shipping savings (see scenario 1) plus about $100k from relieving a Rockets bottleneck. All Rockets come from El Bajio, whose line runs at its limit (having expanded twice), so Rockets are built ahead in the quarters before the 2031 peak. That stock competes for DC space; without the Philadelphia expansion to 320k, Atlanta would be full from 2030 and customers would shift to farther DCs. Philadelphia’s expanded storage relieves this. A third El Bajio expansion would relieve this same bottleneck and is a substitute, but it is the overall more expensive option here, so not chosen. Scenario 3 does not buy that third El Bajio Rocket line expansion, unlike scenario 1, partly because San Bernardino’s extra storage frees room for the pre-build.

Why El Bajio Rockets expands three times in scenario 1 and twice in scenario 3

Rockets all come from El Bajio in both. Scenario 3 builds about 60k extra Rockets ahead in each of periods 2030_Q3 through 2031_Q1 (about 220k unit-quarters of pre-build, vs about 41k in scenario 1), while scenario 1 buys the 880k step for 2031_Q2.

Scenario 3 can do this because it has 50k more storage, all at San Bernardino, which pulls customers from Dallas and Salt Lake City and frees room there.

Why Princeton Space Suits expands in scenario 1 and not in 2a and 3

Scenario 1 does not have any other options to add Space Suits production capacity, so it needs to expand the existing line at the Princeton Factory to meet the increasing demand. The Space Suits line in Reno is opened as soon as Reno opens in 2027_Q1 in scenarios 2a and 3. This provides sufficient capacity for Space Suits over the model's horizon so that additional investment for expansion of the existing Space Suits line at the Princeton Factory is not needed.

7. Sensitivity Analysis

Scenarios: 4a–4d

The preferred configuration is tested against different demand assumptions to determine how sensitive the solution is to changes in the 2027–2031 demand forecast.

Four demand scenarios are evaluated:

The purpose of this analysis is to understand whether the preferred capacity strategy remains appropriate if actual demand is lower or higher than currently forecast.

On the Optimization Network Summary Output table, we see that, as expected, the total supply chain cost is lowest for the lowest demand scenario (4a), and it increases as demand increases:

Most other costs are omitted here, but from the Total Fixed Operating and Total Fixed Startup costs, we can tell that the Reno Factory and Los Angeles Port do not come online in the scenarios with reduced demand (4a and 4b), but they do in those with higher demand (4c and 4d).

Now we will compare how the expansion costs are split out over the DCs and existing lines in these 5 scenarios by using the Total Expansion Cost by Scenario chart in the Analytics module:

For the timing of each expansion, we can again use the Optimization Capacity Expansion Summary output table, now filtered for Expansion Cost > 0 and scenarios 3 and 4a-d:

For scenarios 4a-d, we can then conclude:

1. Reno only comes online from the demand level in scenario 3 and up. If demand is below the forecast, expanding the current lines is sufficient and cheaper overall.
2. Combining an El Bajio Rockets line expansion with opening the Reno Factory is optimal only in scenario 3:
   1. Decreased demand: Reno does not come online. At a 5% decrease, the El Bajio Rockets line is expanded twice, same as in scenario 3. At a 10% decrease, a single expansion suffices.
   2. Increased demand: the Reno Rockets line comes online in both 4c and 4d. The El Bajio Rockets line stays in use but is not expanded.
3. Decreased demand: both the San Bernardino and Philadelphia DCs still need to expand, but only to their first level in both the 5% and 10% scenarios.
4. Increased demand: Philadelphia expands to the third level (320k) level for both scenarios. San Bernardino goes to the second level (250k) in 4c and to the third level (300k) in 4d.
5. Detroit DC needs to expand only in the highest demand scenario (4d).

Other Helpful Resources

The following Help Center articles cover several modeling concepts touched upon in this article in more detail:

• Incremental Change (Network Optimization)
• Detailed Production Modeling in Cosmic Frog (Network Optimization)
• Multi-Time Period Network Optimization
• How to use User Defined Variables

And to get started with Optilogic tools, please see the following documentation landing pages for:

• Cosmic Frog
• DataStar
• Ada & Agentic AI

Appendix – SQL for Adding custom_entityname Column

The following SQL statements can be used to add and (re-)populate a custom column named custom_entityname to the Optimization Capacity Expansion Summary output table. This was done in the example model using the SQL Editor application to enable several visuals in the Capacity Expansion specific dashboards showing different types of expansions together in one chart.

The ALTER TABLE statement can be used once for a model to add the column and then does not need to be used again. The example model already has this column, so no need to run it on that model. The UPDATE statement needs to be run after running any new scenarios and after re-running already existing scenarios.

ALTER TABLE anura_2_8.optimizationcapacityexpansionsummary
  ADD COLUMN custom_entityname text;

UPDATE anura_2_8.optimizationcapacityexpansionsummary SET custom_entityname = COALESCE(
  NULLIF(BTRIM(facilityname), ''),
  NULLIF(BTRIM(workcentername), ''),
  NULLIF(BTRIM(userdefinedvariablename), '')
);

Note that you could also achieve this by using Ada with following prompts that has the Cosmic Frog model selected as the database and using the Modeler Agent:

• To add the column: "Add a column name custom_entityname to the Optimization Capacity Expansion Summary output table. Its value should be one of the values of the Facility Name, Work Center Name, or User-Defined Variable Name columns, whichever is not blank".
• To refresh the column's values: "Update the custom_entityname column on the Optimization Capacity Expansion Summary output table. Set its value to one of the values of the Facility Name, Work Center Name, or User-Defined Variable Name column, whichever is not blank".