Testing an SCND Cost Function Before Optimization

Before I wrote the full supply-chain network optimizer, I implemented the objective as a standalone scenario evaluator. That let me test units, timing, capacity bands, allocation logic, and cost dominance without involving solver behavior.

A solver can minimize a function exactly as written and still produce the wrong business decision. The evaluator made the economic assumptions visible first.

Model the objective as an independent component

I built scnd.oploy.eu as an interactive evaluator for a Netherlands network over 2026 to 2030. A scenario chooses fulfillment-center opening periods and capacity levels. The evaluation layer allocates demand to the nearest open facility, checks capacity and shortfall, and aggregates the cost by half-year period.

The implemented objective has four parts:

total_cost = opening_capex
           + fixed_facility_opex
           + hub_to_facility_transport
           + facility_to_demand_transport

Opening CAPEX is charged once in the selected period. Fixed OPEX repeats while a facility is active and depends on its capacity band. Transport OPEX depends on both network geometry and allocated flow. The user interface exposes these terms separately so one large component cannot hide a modeling error in another.

Scenario A: 107.9 M€

Scenario B: 105.2 M€

Both networks satisfy the same feasibility checks, but Scenario B evaluates 2.7 million euros lower. The opening schedule and selected capacity bands change when CAPEX begins, how many periods incur fixed OPEX, and how far demand travels.

This comparison is a unit test for the decision logic. I expect an earlier opening to increase facility cost and possibly reduce transport cost. If the component table does not move in that direction, I inspect period indexing, distance units, cost multipliers, and facility activation before trusting an optimizer.

Checks I run before solver integration

• A facility pays opening CAPEX exactly once.
• Fixed OPEX starts in the opening period and continues only while active.
• Capacity is compared with flow in the same unit and time period.
• Transport costs use the intended distance and load units.
• Infeasible shortfall is reported separately from economic cost.
• Identical scenarios return identical component totals.
• Small changes in timing produce explainable changes in the breakdown.

Once these checks pass, the same evaluator can become the objective for a MILP, genetic algorithm, particle-swarm method, or another search procedure. The optimization method can change without changing the business accounting.

How to repeat this

1. Open the SCND demo. It runs in the browser; nothing to install.
2. Build one scenario and write down the four component totals, not only the final number.
3. Open one facility a period earlier. Fixed OPEX should go up. Transport cost should stay the same or go down.
4. If a component moves the other way, check period indexing, distance units, cost multipliers and facility activation before you trust any optimizer built on top.

The same habit later caught a cost function that rewards stockouts in my inventory simulation, and the optimizer it misled is in optimizing reorder points with a noisy simulator.