The power brief A steady demand during a grid outage
Illustrative catalogue. Availability: 32 battery racks, 12 converters and 20 coolers of a chosen family. No measured site data.
These results could not be read.
The embedded calculation record is missing or invalid. Reload the complete app to try again.
THE SELECTED DESIGN
Reading the complete calculation…
The choices that remain
Lower cost and a smaller compound are both desirable. Keep the designs that cannot improve one without giving up the other.
A first pass can miss its own obligations
Railway load is only the start.
Check the three connected interfaces
These are checks of the declared sizing equations. They do not establish electrical protection, operating reliability or a safe installation.
See the selected component costs and footprint
Replay the actual calculation
The obligations settle together.
Each pass propagates requirements through batteries, converters and cooling. These are calculation iterations, not construction stages or elapsed hours.
Inspect every recorded calculation pass
All eight family combinations
A completed calculation can still exceed available equipment. Cost and footprint ceilings are applied after sizing. A family record is retained even when another family has the same resources.
Keep the brief, every family result, the selected witness and its calculation trace together.
From a power requirement to a compatible system
Include what keeps
the power running.
An extra battery rack brings a cooling allowance. Cooling draws power. Conversion loses energy. That can call for another rack. The least compatible design has to close the whole loop.
Supply energy.
Bring a heat allowance.
Usable battery energy must cover the railway, cooler draw and converter loss throughout the outage.
Supply output.
Add conversion loss.
Converters must support railway demand plus cooling draw. Their fixed operating loss becomes heat and an energy requirement.
Remove heat.
Use some power.
Coolers cover the allowance from operating racks and converter losses. Their own electrical draw returns to the power requirement.
Three interfaces, checked in their own units
Converter output ≥ railway power + cooling draw
Heat removal ≥ rack heat allowance + converter loss
Counts are whole numbers. Within each of eight fixed-family architectures, the actual Python codesign-mcdp package composes these modules using System and starts its feedback calculation at zero. Each pass increases obligations until the count vector stabilises. The app preserves the package’s trace and the implementing equipment counts.
A converged count vector is checked directly against all three interfaces. It is then compared with explicit equipment availability: 32 battery racks, 12 converters and 20 coolers. Calculation completion and catalogue availability are separate findings.
Why the least counts are enough here
The declared count map is monotone: raising connected obligations cannot reduce the required number of a component. The zero-start fixed point is componentwise no larger than any compatible count vector in the same architecture. Every extra component has positive cost and footprint. Thus the least compatible vector dominates larger vectors of that family. If it exceeds an equipment cap, a larger one cannot repair availability.
After this sizing, the app compares capital and footprint across all eight families. Equal resource points retain all family IDs. Upper ceilings on these resources can filter the complete results without hiding a newly preferable oversized design. This conclusion relies on this particular monotone model and its resource coefficients.
A finite atlas of real package calculations
The 98 selectable briefs cover seven power values, seven durations and two declared conditions. Each has eight cold-start package calculations. The browser reads those precomputed records and filters or displays them; it does not run Python or substitute a JavaScript sizing algorithm. Arbitrary power values, durations, component coefficients and climate conditions are outside the atlas. Capital and footprint ceilings may be entered freely. They are retained as decimal strings in the record; comparison with the whole-pound and whole-square-metre resource totals uses the exact integer part, so a ceiling just below a boundary cannot round up to include it.
Model, equations and verification · Python calculation recipe · Complete calculation atlas
Read the component catalogue and hot-condition factors
Hot multiplies usable battery energy by 4/5, rack heat allowance by 3/2, and cooler removal capacity by 4/5. Converter parameters and cooler draw are unchanged. “Hot” is one declared scenario, not a probability distribution or a universal worst case.
Usable kWh is net DC energy after internal cell losses. Cooling draw and converter loss are accounted for separately. The fixed heat per operating rack is a synthetic design allowance; it is not a physical assertion that adding parallel batteries always increases actual heat at a fixed railway load.
What the first pass leaves out
The comparison initially sizes batteries for railway energy and converters for railway power, then adds cooling for those initial components. It stops before enlarging batteries and converters for cooling draw and conversion losses. The resulting interface checks expose what remains unsupported. It is a deliberately incomplete comparison, not an alternative acceptable design.
A sizing result, with a clear boundary
All equipment capacities, heat allowances, losses, costs and footprint figures are synthetic. Steady demand replaces a real duty cycle. The model omits transient thermal behaviour, charging, protection, reliability, distribution losses, construction sequence and site constraints beyond its explicit inventory and resource ceilings. A converged calculation is not an engineering or safety approval.
For a different question—whether a railway upgrade can reach its target while meeting intermediate service requirements—visit Staged rail paths. This app sizes a temporary power compound; it does not place it into that construction model.
What comes from where
A published method.
A declared numerical experiment.
The solver is real package code. The equipment catalogue is fictional. The source ideas motivate the connection without validating the invented numbers.
The actual package
Corentin Briat’s codesign-mcdp package supplies the design-problem primitives, named-interface composition and feedback calculation used to generate every result in this app. The pinned source and recipe make the atlas reproducible.
Pinned package source ↗Minimal resources and feedback
Andrea Censi’s A Mathematical Theory of Co-Design supplies the order-based treatment of functionality, resources and coupled design problems. Here, integer equipment obligations form the feedback loop, and capital and land are compared componentwise.
Censi’s paper ↗Retain the implementation
Gioele Zardini’s Co-Design of Complex Systems, §§3.1–3.5, separates functionality, implementation and resources. This app keeps the battery, converter and cooling families and their counts alongside each resource point.
Thesis at ETH Zürich ↗Thermal design and energy are connected
The National Laboratory of the Rockies describes thermal experimentation and system-level energy-storage design. This motivates asking about heat, cooling and energy together. It does not provide or validate this app’s equipment coefficients or its rail application.
Energy storage performance research ↗Inspect and reproduce
Model and source-use note · Record format · Pinned Python dependency · Independent arithmetic check
The independent arithmetic check and browser interaction checks are different kinds of evidence. Neither represents field validation or human acceptance of a railway design.