Pyomo Examples That Simplify Modeling (Without Math Gymnastics)
In all examples below:
You describe business rules
Pyomo handles auxiliary variables, reformulations, and solver‑ready math
You never manually derive LP/MIP rows
Example 1: Step Function Cost Inside a Component
(Classic but messy in math)
Business rule (plain language)
Producing up to 100 units is cheap.
Producing more than 100 units triggers overtime and becomes expensive.
That is a step function in cost.
Logical description:
If production <= 100:
cost = 10 * production
Else:
cost = 10*100 + 25*(production - 100)
Writing this directly as math is unpleasant.
In Pyomo, it’s trivial.
from pyomo.environ import *
m = ConcreteModel()
m.production = Var(bounds=(0, 200))
m.cost = Var()
m.pw = Piecewise(
m.cost,
m.production,
pw_pts=[0, 100, 200],
pw_constr_type='EQ',
f_rule=[0, 1000, 1000 + 25*100],
)
Why this is powerful?
No binary variables written by hand
No “big‑M” reasoning required
Reads exactly like the business rule
If solvable as LP, Pyomo keeps it LP.
If MIP is required, Pyomo handles that.
Example 2: Warehouse Activation Threshold
(Logical switch, not algebra)
Business rule
A warehouse incurs a fixed operating cost if any inventory is used.
This is extremely common and awkward in pure math.
Logical thinking
Inventory > 0 → warehouse is “on”
Inventory = 0 → warehouse is “off”
Pyomo (clean and explicit):
m.inventory = Var(domain=NonNegativeReals)
m.active = Var(domain=Binary)
M = 1e6 # Pyomo-specific detail hidden at the component level
m.activation = Constraint(expr=m.inventory <= M * m.active)
m.fixed_cost = Expression(expr=5000 * m.active)
Why this helps?
You never reason about:
binary logic at the system level
how many rows this creates
solver syntax
You simply express:
“If anything flows, the warehouse is active.”
Example 3: Tiered Storage Capacity (Physical Reality)
Business rule
A warehouse has shelves.
First 50 units are easy.
Beyond that, storage becomes inefficient.
That’s not linear in spirit, but still manageable.
Logical description
Inventory is split into tiers
Each tier has different effects
class Warehouse(Block):
def build(self):
self.tier1 = Var(bounds=(0, 50))
self.tier2 = Var(domain=NonNegativeReals)
self.inventory = Expression(expr=self.tier1 + self.tier2)
self.handling_cost = Expression(
expr=2*self.tier1 + 5*self.tier2
)
Why this is elegant?
No piecewise constraints needed
Tiers map to physical interpretation
Algebra stays hidden
This would be unreadable in flat LP form.
Example 4: “Soft” Demand Requirement (Penalty Instead of Hard Constraint)
Business rule
Meeting demand is preferred,
but shortages are allowed with a penalty.
This flips a hard constraint into a soft rule.
Logical description
Demand shortfall is allowed
Penalty applies if shortfall > 0
m.supplied = Var(domain=NonNegativeReals)
m.shortfall = Var(domain=NonNegativeReals)
m.balance = Constraint(
expr=m.supplied + m.shortfall >= m.demand
)
m.penalty = Expression(expr=1000 * m.shortfall)
Now the objective decides whether it’s worth missing demand.
Example 5: Time-Based Step Rule (No calculus needed)
Business rule
Inventory held more than 3 months incurs spoilage cost.
You do not model time decay equations.
You model logic.
Pyomo (indexed logic):
m.T = RangeSet(6)
m.inventory = Var(m.T, domain=NonNegativeReals)
m.spoilage = Var(m.T, domain=NonNegativeReals)
def spoilage_rule(m, t):
if t <= 3:
return m.spoilage[t] == 0
return m.spoilage[t] >= 0.1 * m.inventory[t-3]
m.spoilage_constraint = Constraint(m.T, rule=spoilage_rule)
Why this matters?
This would be extremely opaque in:
pure LP matrix form
solver-native format
Here, it directly reflects policy.
What All These Examples Have in Common
You think in terms of:
thresholds
activation
penalties
tiers
policies
You do NOT think in terms of:
binaries first
matrix rows
constraint indices
reformulations
Pyomo translates logic → math → solver.
Mental Shift (Important)
Without Pyomo
“How do I encode this condition mathematically?”
With Pyomo
“What rule governs this behavior?”
That shift is the real power.
When This Becomes Critical
These constructs become essential when:
business rules evolve
thresholds change
new tiers are added
scale increases
You update logic — not math.
Key Takeaway
Pyomo excels when problems are driven by rules, thresholds, and structure,
not clean algebra.
Step functions, activation logic, penalties, and tiers are:
conceptually natural
extremely common
painful to derive by hand
Pyomo lets you model them as they are.