Prefeasibility cockpit

In simple terms

The cockpit is the app’s main instrument. On the left you set the plant’s sizes (how much wind, solar, battery, electrolyser, and how much of each product). On the right you immediately see the answer: the levelized cost of the product, which stage is the bottleneck, a live flow diagram of the value chain, and a set of breakdown charts. Every edit re-solves and the numbers animate to their new values — recalculation is the point.

Why it exists

Prefeasibility is fast screening: before committing to a bankable hourly study, a developer wants to sweep sizings and see the cost and the binding constraint move in real time. The cockpit turns that loop — edit → solve → read → tweak — into a single live screen.

Where it lives

• Room: frontend/src/rooms/prefeasibility/PrefeasibilityRoom.tsx.
• Sub-parts: RightSizeControl.tsx (the optimiser FAB), LcoaLandscape.tsx (the optimisation surface); the design panel, shared with feasibility: frontend/src/design/ (PrefeasibilityDesign.tsx, DesignPanel.tsx, VersionLine.tsx). Export ▾ and Snapshot are the stage frame’s (shell/StageActions.tsx).
• Backend: PtxApi.solve → run_prefeasibility_auto (Mode A) / run_greedy… (Mode B) in backend/core/.

How it works, step by step

1. The design panel (left). One section open at a time: Site & resource · Plant (renewables, electrolyser, technology) · Products (the value-chain editor: add/remove derivatives, choose the eSAF pathway, set each capacity — the capacities decide each product’s share of the hydrogen, shown read-only) · Storage · How it runs, where Resolution switches Annual (Mode A) ↔ Timeseries (Mode B). Editing debounces, then auto-solves — you rarely press a button. A value that differs from the saved sizing version is marked “was …” and counted on Save · N changes; Discard goes back to the version.
2. The solve. The room calls solveProject; the backend resolves the book into params and runs the engine. See the request lifecycle for the full click-to-chart path.
3. The answer side (right). The result bundle drives:
   • Flow diagram — the value chain (renewables → BESS → electrolyser → desalination → derivative units → product), with the binding stage lit and per-node realized utilization %. Re-lights on every recalc.
   • LCO hero — the headline levelized cost (LCOA $/t, LCOH $/kg where H₂ is an intermediate), tweened.
   • KPI strip — production, curtailment, electrolyser load factor, annualized cost.
   • Breakdown charts — CostBuildup (annualized cost composition), EnergyBalance (electricity by consumer + curtailment), BottleneckChart (the three limits), CapexBreakdown, LcoBreakdown (per molecule).
4. Tools. A persistent Right-size FAB (bottom-right), a Snapshot button (capture the scenario into the Snapshots room), and Excel/report exports.

The two modes

• Mode A (annual) — pure closed-form screening. Each component reports a yearly ceiling; the binding (smallest) one is production. No weather data needed.
• Mode B (timeseries) — an 8,760-hour greedy simulation on the site’s hourly CF curve. Adds real weather coincidence + storage dynamics; shows day-envelope SoC / supply traces and an interactive optimisation landscape.

How each mode computes, how both compare with the feasibility engines, and what to trust: How prefeasibility works; see also System architecture.

Right-size & the optimisation landscape

• Right-size (the FAB) runs an optimiser that sizes the free components to the locked ones, minimising the product levelized cost. You choose which components to lock via the split-pill’s chooser; guard rails keep at least one locked and one free. In Mode B it refines the closed-form answer against the greedy engine (coordinate descent + a Nelder–Mead polish).
• The landscape (LcoaLandscape, Mode B) draws the LCOA surface the optimiser minimises — a heatmap over electrolyser MW × total product t/yr — with the current (◦) and optimum (★) points, a per-derivative capacity/LCO read-out, and an ”✓ Optimized / ↓ X% cheaper” badge. The axes adapt to what’s locked (e.g. the x-axis flips to “Renewables” when the electrolyser is locked).

For the maths, see How prefeasibility works — the page the cockpit’s How it works tab shows (/projects/:id/prefeasibility/method; the old /projects/:id/methods redirects there).

Multi-derivative

A project holds a list of derivatives; a single molecule is a list of length 1 (single-vs-multi is a view). Each product’s share of the hydrogen is a result of the capacities — its need at full output over all the units’ needs (How prefeasibility works); the Production panel shows each share, the one load every unit runs at, and the hydrogen not made when the units are full (that electricity is curtailed unless you add an H2_export product). Shared upstream cost is allocated by that share; the multi landscape decomposes the result per derivative. A product without a capacity stops the solve with one sentence naming it.

Failure & edge cases

• No site linked in Mode B: the greedy frame falls back to a flat CF profile (degraded but honest) — it never fails the solve.
• Bad parameter/range or unknown derivative: the backend returns a 422 with a specific message, surfaced in the room’s error panel.
• Lock-all on right-size: rejected (≥1 must stay free) — the guard rails prevent reaching that state.

How to modify this safely

• New output on the answer side is a three-place change: the core/ producer → the api.ts type → the room. Run tsc.
• Keep the recalculation-as-hero motion (tween numbers, re-light the bottleneck).
• Sizing lives in the project config, not the book — edits go through patchConfig, assumptions through the book editor.

Related topics

• How prefeasibility works — the stage’s How it works tab
• What the model leaves out
• Request lifecycle
• System architecture
• Feature index
• Feasibility solve flow