Application overview

In simple terms

Hyprisma helps someone plan a green-hydrogen project and see, in seconds, whether it makes economic sense and how big each piece should be.

“Power-to-X” means using renewable electricity (wind, solar) to make hydrogen, and then turning that hydrogen into something useful and shippable — ammonia, e-methanol, sustainable aviation fuel, green steel, and so on. Building such a plant costs hundreds of millions, so before anyone commits, they need to answer: is this worth it, and how should I size the wind farm, the electrolyser, and the factory that turns hydrogen into the final product?

This app is the tool that answers those questions. You describe a project (a location, what you want to produce, roughly how big), and it computes the cost per tonne of product, where the bottleneck is, how much energy gets wasted, and what sizes would make it cheapest — then lets you refine and compare designs.

Why this exists

Existing tools are either grid-market simulators (built for utilities, not project developers) or black-box consultant software (you can’t see how the number was made). Hyprisma is different on purpose:

• Built for project developers, not consultants or utilities.
• Transparent — every number traces back to an editable assumption, and you can see the physics and the maths behind it.
• A first-class financial model — not a bolt-on.
• Staged sophistication — a fast free “prefeasibility” screen first, a rigorous “feasibility” optimisation second, so you only pay the compute cost when you need the precision.

Where it lives

• Backend engines + API: backend/
• Web interface: frontend/
• The structural blueprint: docs/01-architecture/

How it works step by step (the big picture)

1. You open the app in a browser (it runs on your own machine — see Deployment & runtime model).
2. You create a project: a location with its wind/solar quality, and one or more products to make.
3. In the cockpit you set sizes (how many MW of wind, how big an electrolyser, how much storage). Every edit re-runs the engine automatically.
4. The engine computes production, energy use, curtailment (wasted electricity), and the levelized cost of each product.
5. A flow diagram lights up the binding bottleneck; charts break down the cost.
6. Right-size finds the cheapest set of sizes; the optimization landscape shows you the cost surface so you can trust it.
7. When you want the bankable answer, the feasibility stage re-solves the whole year hour-by-hour as an optimisation problem.
8. You snapshot designs to compare them, and export Excel/PDF reports.

The two engines (the core idea)

The whole product is organised around a staged-sophistication model — each stage adds exactly one layer of physics over the one below:

• Prefeasibility — Mode A (annual): closed-form averages on an assumed curtailment floor. No weather data. Screens an idea in seconds.
• Prefeasibility — Mode B (timeseries): an hour-by-hour simulation on real weather, with simple priority rules and no foresight.
• Feasibility (hourly LP): the same year solved as a linear program with perfect foresight and real operating limits. With the rule-based engine (the same limits, no foresight) it brackets how the plant really runs.

That bracket — no look-ahead on one side, perfect foresight on the other, and the annual screen resting on the curtailment floor you assume, so it can land on either side — is the mental model that ties the app together; How prefeasibility works says which comes out higher, and why. See System architecture for how the pieces fit, and the Glossary for any unfamiliar term.

Audience note

This documentation is written for two readers at once: a newcomer who wants an intuitive picture, and a developer who needs enough depth to change the code safely. Each page starts plain and gets progressively more technical — read as far as you need. See the Reading guide.

A living first-overview (not a final spec)

This guide describes the app as it is today and will change as the app does — read no page as a fixed contract; each carries an honest status:. Two areas are explicitly preliminary: the Assumptions surface (it will be deepened into robust, sourced assumptions with per-assumption user comments + edits and multiple source choices you can aggregate/consolidate), and Operations & security (it reflects today’s local, single-user posture and the audit backlog — not a hardened final design).

Related topics

• System architecture
• Reading guide
• Glossary