Modeler fundamentals · Part 1 of 6
Modeler user guide: your first defensible power-system study
A novice-friendly Modeler walkthrough: create a project, load an India network, branch a scenario, inspect data, run a study and verify the result.
- For
- First-time users, analysts and reviewing agents
- Time
- 45 minutes plus solve time
- Updated
- 20 Jul 2026
Direct answer
The safest first Modeler study is a result-first evidence chain: define one decision, load and inspect a sourced network, preserve the base case, change one scenario, lint and solve it, reconcile the physical result, compare economics and carbon, then stress-test the conclusion.
Solved result first
What the completed analysis must expose
Start by reading a complete solved output, then work backward to its network, scenario and run manifest. The production demo below is a 168-hour India zonal case captured on 20 July 2026; it is a method benchmark, not a forecast or market quote. A credible analysis explains the physical balance, economic objective, carbon result, constraint response and sensitivity—not merely that the solver completed.
| Result | Displayed value | Technical benchmark | Decision reading |
|---|---|---|---|
| Energy served | 26,573.4 GWh | Reconcile against demand and balance residuals | Volume actually served over the modeled horizon |
| System cost | ₹106.2 billion | Compare only with matched horizon, network and formulation | Objective value; not a retail bill or project NPV |
| Emissions | 10.7 MtCO₂ | ≈403 gCO₂/kWh derived from displayed totals | System-average modeled intensity for this run |
| Curtailment / unserved | 0 / 0 GWh | Stress-test before concluding the system is unconstrained | Zero in one run is not proof across weather or outages |
| Average price | ₹3,996.1/MWh | ≈₹4.00/kWh energy-only | Modeled marginal-price summary; not a delivered tariff |
Analytical method
- 01Freeze the decision question, counterfactual and pass/fail metrics before editing the model.
- 02Audit topology, component units, time series, snapshot weighting and source coverage before the first solve.
- 03Preserve an untouched base; change one controlled input in a named scenario and use identical solve settings.
- 04Read results in this order: balance and solver status, reliability, cost and prices, emissions and curtailment, then asset-level constraints.
- 05Benchmark every delta against a physical identity, historical range, alternative scenario or sensitivity; export result IDs and limitations.
Who should interrogate what
Electrical engineer
Where is the physical constraint?
Trace unserved energy, overloads, voltage-class assumptions and affected buses or corridors before accepting a KPI.
Environmental engineer
What changes at the margin?
Compare total and marginal emissions, curtailment and the hourly dispatch mechanism rather than relying on annual renewable share.
Energy economist
Is the comparison economically matched?
Hold horizon, objective, network and constraints constant; separate operating cost from capex, tariff and welfare effects.
Policy maker
Which result supports which claim?
Use scenarios to test policy mechanisms and distributional effects without treating a planning run as compliance evidence.
Energy trader
Is this a tradable exposure or a model proxy?
Distinguish modeled nodal prices from IEX observations, tariff components, imbalance settlement and executable market bids.
Before you start
- • An EnergyMap account with an active organisation.
- • A current Chrome, Edge, Firefox or Safari browser on a laptop or desktop.
- • A concrete question stated in one sentence—for example, ‘What changes if I add a 30 MW four-hour battery?’
What you will have
You will finish with an untouched base, one named scenario, a completed result ID and a short evidence note another person or agent can reproduce.
Step-by-step
Complete the workflow
Write the decision before opening a model
A useful study changes one decision variable and names the outputs that would change the decision.
Do this
- 1.Write the project decision, asset size, location, time horizon and comparison case.
- 2.Choose three to five decision metrics such as unserved energy, system cost, local price, curtailment and corridor loading.
- 3.Write one explicit non-goal—for example, ‘This is not an interconnection approval.’
Expected evidence
- ✓ One sentence a reviewer can agree or disagree with.
- ✓ A fixed list of metrics that prevents cherry-picking after the solve.
Trust check
If the question cannot be stated before the run, the result cannot be audited after it.
Create a project and name it for the decision
Projects are study folders; use a name that will still make sense in an exported result six months later.
Do this
- 1.Open Modeler and create a project.
- 2.Use a specific name such as ‘Gujarat 30 MW BESS screen — July 2026’.
- 3.Confirm the project appears in the left Networks panel before loading data.
Expected evidence
- ✓ The project is active and its name is visible in the workspace context.
Trust check
Do not mix unrelated client, site or policy decisions inside one project.
Load the smallest defensible network
Use File → State Model Library for a prepared India model, File → Import for your own network, or the Data Shop for a scoped data-built model.
Do this
- 1.Open File → State Model Library.
- 2.Read the model card’s resolution, source notes and plan gate before loading it.
- 3.Load a fresh copy into the active project and wait for its map and Tables view to render.
Expected evidence
- ✓ An active network name in the project tree.
- ✓ Visible buses, lines, generators or loads appropriate to that model’s declared resolution.
Trust check
A transmission-planning backbone is not automatically an as-built GIS, SCADA twin or complete distribution network.
Inspect the base before changing it
Check geography in Map, parameters in Tables and time coverage before you branch a scenario.
Do this
- 1.Open Map and confirm the intended state, node or corridor exists.
- 2.Open Tables and check the units for loads, generators, lines and storage.
- 3.Open Analytics or the result header to confirm the available snapshot window and stride.
Expected evidence
- ✓ The intended asset or location is present by a specific name.
- ✓ Units and time coverage are written into your study note.
Trust check
Stop if the model lacks the spatial or temporal detail needed for the decision; more solver fidelity cannot repair missing geography.
Read the baseline Analytics surface before editing
Record absolute system values and derive two cross-check ratios before creating the counterfactual.
Do this
- 1.Open Analytics and select the untouched base scenario.
- 2.Record energy served, system cost, emissions, curtailment, unserved energy, average price and modeled hours.
- 3.Derive average carbon intensity as emissions tonnes divided by energy GWh; derive ₹/kWh as ₹/MWh divided by 1,000.
- 4.Inspect the generation-mix trace for ramps, scarcity hours and implausible flat segments.
Expected evidence
- ✓ A dated baseline row with units, horizon and result ID.
- ✓ For the worked demo, ≈403 gCO₂/kWh and ≈₹4.00/kWh derived from the displayed totals.
Worked calculation
Carbon intensity (gCO₂/kWh) = emissions (MtCO₂) × 10⁶ / energy (GWh) 10.7 × 10⁶ t / 26,573.4 GWh ≈ 402.7 t/GWh = 402.7 gCO₂/kWh Energy-only ₹/kWh = 3,996.1 ₹/MWh ÷ 1,000 ≈ ₹4.00/kWh
How to read the result
- • The carbon ratio is system-average modeled intensity, not the marginal emissions of a new load.
- • Average price is a model summary; a customer bill also needs losses, transmission, distribution, cross-subsidy, taxes and contract terms.
- • Zero unserved energy or curtailment in the base is a starting condition, not a robustness claim.
Trust check
Write the displayed values and your derived ratios separately so a reviewer can distinguish product output from post-processing.
Clone the base and change one scenario
Keep the base untouched and make scenario changes through validated controls, workflows or Agent action chips.
Do this
- 1.Clone or create a scenario from the active base.
- 2.Name the scenario with the changed input, such as ‘BESS 30 MW · 4 h’.
- 3.Change the parameter and confirm the intended component, value and unit in Tables or the Agent action summary.
Expected evidence
- ✓ Two clearly distinguishable cases: untouched base and named change case.
- ✓ A visible input delta that can be reviewed before solving.
Trust check
Never overwrite the only base case; comparison is the core of a defensible model result.
Lint first, then launch the run
The Run menu exposes scenario selection, pre-run issues, study settings and managed compute in one place.
Do this
- 1.Open Run options and select the base and change case you intend to solve.
- 2.Resolve all errors; document any warning you deliberately accept.
- 3.Confirm horizon, snapshot stride, formulation and compute profile, then launch.
Expected evidence
- ✓ A job per selected scenario in the Jobs panel.
- ✓ A completed status or a specific, actionable failure message.
Trust check
A solver status of ‘completed’ proves execution, not that the study’s formulation or source data are adequate.
Validate the energy balance and solver result
Before interpreting cost or carbon, prove that demand, generation, storage, interchange, losses and unserved energy reconcile over the same weighted snapshots.
Do this
- 1.Open the completed result and confirm solver termination, formulation, horizon, stride and snapshot weights.
- 2.Reconcile served demand with generation, net imports, storage discharge minus charge and losses.
- 3.Inspect any residual against the recorded numerical tolerance.
- 4.If unserved energy is non-zero, locate the time step and constrained asset before reading the cost delta.
Expected evidence
- ✓ Balance residual within the run’s declared tolerance.
- ✓ A named explanation for every shortfall, relaxed constraint or non-converged state.
Worked calculation
Balance residualₜ = generationₜ + importsₜ + storage dischargeₜ − storage chargeₜ − demandₜ − exportsₜ − lossesₜ Pass when |residualₜ| ≤ recorded balance tolerance for every modeled snapshot.
How to read the result
- • A low-cost result with an unexplained balance residual is not economically meaningful.
- • Weighted snapshots require multiplying power by snapshot duration before aggregating to GWh.
- • Unserved energy is a modeled slack outcome; trace its penalty and location rather than treating it as a generic reliability index.
Trust check
Do not continue to commercial interpretation until the physical identity and termination condition pass.
Compare persisted results, not screenshots alone
Pin or open both result IDs and compare the same metrics over the same horizon.
Do this
- 1.Record base result ID, change result ID, timestamps and solver settings.
- 2.Compare system cost, unserved energy, curtailment, prices, emissions and affected corridors as applicable.
- 3.Open the cloned scenario on Map and inspect the assets behind the headline deltas.
Expected evidence
- ✓ A before/after table with common units and a shared time horizon.
- ✓ At least one map or table check connecting a KPI to a physical asset.
Trust check
Do not annualise a modeled week or call a local marginal-price proxy a customer tariff without a documented conversion and procurement model.
Explain the cost, price and carbon mechanisms
A defensible comparison connects each KPI delta to hourly dispatch and the assets that changed output.
Do this
- 1.Calculate absolute and percentage changes using the untouched base as denominator.
- 2.Identify the hours and carriers responsible for the largest production-cost change.
- 3.Compare average and marginal emissions; explain whether additional fossil dispatch, renewable curtailment or storage losses drove the result.
- 4.Separate system objective, nodal marginal-price proxy and delivered customer cost.
Expected evidence
- ✓ A mechanism sentence for every headline delta.
- ✓ A table containing absolute value, delta, percentage, unit, horizon and result ID.
How to read the result
- • A percentage change is unstable when the base is near zero; show the absolute delta first.
- • System cost can fall while a local price rises if congestion redistributes marginal value.
- • Lower curtailment can increase or decrease emissions depending on which generator is displaced and when.
| Metric | Absolute values | Delta | Mechanism to inspect |
|---|---|---|---|
| System cost | Base and scenario ₹ | ₹ and % | Dispatch, starts, fuel and scarcity |
| Unserved energy | Base and scenario GWh | GWh and % | Constrained hour, bus and penalty |
| Curtailment | Base and scenario GWh | GWh and % | Renewable availability, load and transfer limit |
| Emissions | MtCO₂ and gCO₂/kWh | Total and intensity | Marginal carrier and storage losses |
| Price / loading | ₹/MWh and % | Level and percentage points | Binding constraint and affected asset |
Trust check
Never publish a favorable KPI without the countervailing metrics and mechanism checks that could reverse the decision.
Run a small sensitivity matrix
One deterministic result becomes decision evidence only after the conclusion survives plausible input and model choices.
Do this
- 1.Choose at least three sensitivities: demand/load factor, fuel or market price, renewable/weather profile, asset rating or storage efficiency.
- 2.Change one family of assumptions at a time and retain the same comparison metrics.
- 3.Report the range, sign stability and threshold at which the decision changes.
- 4.Prioritize new evidence for the parameter with the highest decision elasticity.
Expected evidence
- ✓ A sensitivity table with low/base/high assumptions and result IDs.
- ✓ A clear statement of whether the recommendation is robust, conditional or reversed.
Worked calculation
Decision elasticity ≈ (% change in decision metric) / (% change in input) Use this as a screening diagnostic, not a substitute for a full probabilistic model.
How to read the result
- • Sampling stride is itself a sensitivity because it can hide short scarcity, ramp and congestion events.
- • If the recommendation flips under a small plausible change, the next action is better evidence—not a stronger headline.
Trust check
A single base/scenario pair supports a conditional finding; a tested range supports a more durable decision statement.
Write the evidence note
A useful handoff says what changed, what the model found, what it did not prove and which next input matters most.
Do this
- 1.List sources and retrieval windows.
- 2.List assumptions, model resolution, horizon, solver and result IDs.
- 3.State the decision implication and the highest-value missing evidence.
Expected evidence
- ✓ A reviewer can reproduce the run without asking which model, scenario or setting you used.
Trust check
Use the exact truth label shown by Modeler. Do not silently upgrade a planning screen into a forecast, SCED study or approval.
Before you share
Completion checklist
- Question, changed variable and decision metrics were fixed before the run.
- Base remained untouched and the scenario has a descriptive name.
- Source, coverage, units and time horizon are recorded.
- Base and scenario use comparable solver settings.
- Result IDs and solver status are saved.
- Limitations and the next missing input are stated beside the result.
Answer desk
Frequently asked questions
Do I need to know PyPSA to use Modeler?
No. Prepared models, validated forms, workflows and Agent tools cover the normal path. PyPSA knowledge helps when importing or auditing custom networks, but it is not required for a first study.
What should a first-time user model first?
Choose a single controlled comparison: one load, one battery or one constraint change against an untouched base. Avoid a multi-year investment programme as the first study.
Can a Modeler result be used as an interconnection approval?
No. Modeler can produce planning evidence, but utility ratings, outage sets, protection, reactive power, AC validation and the applicable approval process must be supplied for an interconnection study.