The power brief A steady load while working off-grid
Illustrative catalogue. Availability: 32 battery packs, 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 less cabinet volume are both desirable. Keep the designs that cannot improve one without giving up the other.
A first pass can miss its own obligations
Monitoring 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 cabinet volume
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 cabinet volume 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.
Support consumes resources it must itself support. An extra battery pack brings a cooling allowance. Cooling draws power. Conversion loses energy. That can call for another pack. The least compatible design has to close the whole loop.
Supply energy.
Bring a heat allowance.
Usable battery energy must cover the monitoring equipment, cooler draw and converter loss throughout the monitoring period.
Supply output.
Add conversion loss.
Converters must support monitoring 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 packs and converter losses. Their own electrical draw returns to the power requirement.
Three interfaces, checked in their own units
Converter output ≥ monitoring power + cooling draw
Heat removal ≥ pack 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 packs, 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 cabinet volume. 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 cabinet volume 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 cabinet volume ceilings may be entered freely. They are retained as decimal strings in the record; comparison with the whole-pound and whole-litre 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, pack 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 Wh is net DC energy after internal cell losses. Cooling draw and converter loss are accounted for separately. The fixed heat per operating pack is a synthetic design allowance; it is not a physical assertion that adding parallel batteries always increases actual heat at a fixed monitoring load.
What the first pass leaves out
The comparison initially sizes batteries for monitoring energy and converters for monitoring 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 cabinet beside the crossing
The 750 W default represents an invented cluster of cameras, illumination, sensors, a logger and a data link, operating for eight hours without charging. It can stand for an overnight or temporary deployment; it is not the draw of a typical individual camera trap. The model sizes its power equipment, not the crossing itself.
Cabinet volume is an additive allocation in litres for equipment housing and internal spacing: 28/16 L per standard/compact battery pack, 12/8 L per standard/efficient converter and 12/6 L per air/liquid support unit. It does not predict ground footprint, exterior dimensions or physical packing. All these values are synthetic; liquid cooling is an illustrative family choice.
A sizing result, with a clear boundary
All equipment capacities, heat allowances, losses, costs and cabinet volume figures are synthetic. They are not supplier data or an ecological deployment recommendation. 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 the separate question of keeping a crossing usable while work proceeds, visit Staged crossing paths. This app sizes monitoring power; it does not place it into that construction model or predict animal behaviour.
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 volume 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 monitoring 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 monitoring design.