Projects, scenarios, and the data model

This page explains how TESSA organises the work of an energy planning study. If you are sitting down to model a district, you will be working inside a project, splitting your investigation into scenarios, and — if your study has a phasing component — combining those scenarios into a deployment plan. This page describes what each of those is for, what lives inside them, and how they relate.

Two companion pages drill down into the parts of the model where most of the engineering detail lives:

• Districts and buildings data model — the demand side.
• Networks and heat sources data model — the supply side.

Project, scenario, deployment plan

The three top-level concepts answer three different questions:

• A project answers "which study are we doing?" — it is tied to a place, an organisation, and a body of shared inputs (climate data, custom layers, the buildings you have curated). A project is long-lived; you keep coming back to it.
• A scenario answers "which option are we testing?" — a self-contained design with its own districts, network, heat sources, financial assumptions, and results. You will typically have several per project.
• A deployment plan answers "how does this get built over time?" — an ordered sequence of scenarios that represents a phased rollout, used when you need to consolidate CAPEX, OPEX, and revenues into a single multi-decade financial picture.

A deployment plan does not own its scenarios — it points at scenarios that live in the project. You can have a deployment plan or not, depending on whether phasing matters for your study.

What sits inside a scenario

A scenario is the unit of analysis. When you open the comparison view, when you export a report, when you simulate, you are working with one scenario at a time — and everything needed to do that work is contained inside it.

A few things worth keeping in mind as you set up a study:

• The district sets the demand. Buildings and the climate that drives their loads belong to the district. If two of your scenarios use different building stocks (e.g. before and after retrofit) or different climate series (present vs future), you will have separate districts inside each scenario, populated accordingly.
• The network is built on top of the district. Building substations connect to specific buildings; energy centers feed the network. A scenario without a network is perfectly valid — it just describes the demand and the existing situation.
• Borehole fields are scenario-level, not network-level, because the same field can appear at different points in the system (as the cold source for an energy-center heat pump, or as the source for booster heat pumps at substations) and because you may also model standalone geothermal assets.
• Financial assumptions are set once per scenario — discount rate, fuel price trajectories, electricity price, currency — and apply to every cost calculation that comes out of the scenario. Per-component costs (a specific boiler's investment cost, a specific pipe's cost) are stored on those components.

The two companion pages walk through the demand side and the supply side in detail.

Why you create multiple scenarios

The most useful thing about scenarios is that they are independent — changing one does not affect the others — but comparable, because they live in the same project and TESSA tracks how each was derived.

Patterns you will run into in practice:

When you duplicate a scenario, TESSA records the link. The comparison view uses that link to show what changed — energy demand, peak power, source mix, NPV, CO₂ — without you having to diff anything by hand. See Compare scenarios.

The duplication is a deep copy: the new scenario gets its own copy of the network, the buildings, the energy centers. Editing one scenario will never silently change the figures in another.

Deployment plans: scenarios over time

Most of your work will be inside a single scenario. The deployment plan is a separate object that comes into play when you need a multi-stage financial picture — typically when a network rolls out in phases over a decade or more.

Each stage records:

• Which scenario it points to — the design at that phase.
• The start year of that stage — when CAPEX is incurred and revenues begin.
• A capital carryover factor — what fraction of an earlier stage's assets is still on the books when the next stage starts.

The deployment plan adds its own discount rate and horizon end year so it can roll the per-stage cashflows into a single NPV/IRR for the whole programme. If your study is single-phase, you don't need a deployment plan at all — the financial figures on the scenario itself are sufficient.

Access and sharing

You are a member of one or more organisations. An organisation can be granted access to a project, and that access flows down to every scenario inside the project — there is no per-scenario permission layer.

If you need to send a single scenario to someone outside the project — for example, a colleague at a different consultancy — use the import/export workflow rather than trying to share project access. See Import and export scenarios.

Where to go next

• Districts and buildings data model — the demand side: districts, buildings, climate, and how they are populated.
• Networks and heat sources data model — the supply side: pipes, substations, energy centers, heat sources, borehole fields.
• Financial model — how scenario-level assumptions and per-component costs combine into a financial report.