Solved developer example · Part 3 of 6

Small BESS project tutorial: site and test a 30 MW four-hour battery

Step-by-step BESS modeling for India: prepare a base, run a 30 MW / 4 h siting study, compare price spread and peak net load, and separate operating value from investment returns.

For
BESS developers, lenders, utilities and technical advisers
Time
75 minutes plus paired solves
Updated
20 Jul 2026
Before and after comparison for a 30 MW four-hour BESS study
A BESS result must compare physical outcomes and commercial evidence without silently turning operational value into ROI. · Hosted on Cloudinary.

Direct answer

For a small BESS screen, solve an untouched base, rank buses by local price stress and evening ramp, place 30 MW / 4 h at the top-ranked bus, re-solve the cloned scenario, and compare physical and market metrics over the same horizon.

Solved result first

What the completed analysis must expose

Open the technical text / video script →

A BESS screen is a paired dispatch experiment, not an ROI claim. This guide sizes a 30 MW / 4 h asset (120 MWh), applies 92% charge and discharge efficiency (84.64% round trip), re-solves an untouched base with identical settings and reads cost, reliability, curtailment, emissions, state of charge, nodal price and corridor loading together. The recorded 168-hour Dholera benchmark is deliberately mixed: reliability and cost improved while marginal emissions and local loading worsened.

Recorded 168-hour BESS benchmark—method evidence only; rerun current inputs for a decision
MetricNo BESS30 MW / 4 h BESSBenchmark reading
Nameplate / usable cycle30 MW · 120 MWh · 84.64% round tripLosses require price and carbon spread, not merely time shifting
Unserved energy3.58 GWh2.94 GWh17.9% lower in the recorded modeled week
Incremental operating costRecorded baseline3.6% lower; ≈₹19 lakh reductionOperational saving only; capex and degradation excluded
Marginal emissions563 gCO₂/kWh607 gCO₂/kWh7.8% higher because charging/discharging changed marginal dispatch
Local corridor peak22.5%24.4%+1.9 percentage points; still non-binding in that recorded case
Loss-only arbitrage hurdleCharge at ₹3,000/MWhDischarge above ≈₹3,544/MWh₹544/MWh minimum spread before fees and degradation

Analytical method

  1. 01Define the service stack and decision metric: energy arbitrage, reliability, curtailment, congestion, capacity or a stated combination.
  2. 02Freeze the base result, time horizon, snapshot weights, network and solver formulation before adding storage.
  3. 03Specify power, duration, charge/discharge efficiency, cyclic state of charge, initial condition and operational limits.
  4. 04Inspect hourly charge, discharge and state of charge; reconcile stored energy and losses before reading financial value.
  5. 05Compare absolute and delta cost, unserved energy, curtailment, emissions, nodal prices and affected corridors.
  6. 06Run power, duration, efficiency, degradation-cost and weather/price sensitivities; only then connect operational value to capex and financing.

Who should interrogate what

Electrical engineer

Does storage relieve the right constraint?

Inspect injection location, SOC availability at the binding hour, loading and reliability—not just system cost.

Environmental engineer

What energy charged the battery?

Compare marginal emissions during charge and discharge; storage can raise emissions even when it reduces cost.

Energy economist

Which value streams are actually modeled?

Separate dispatch savings from capex, degradation, ancillary services, capacity value, taxes and financing.

Policy maker

Does the asset reduce system need or shift it?

Test reliability, curtailment and congestion under multiple stress cases before designing support.

Energy trader

Is the spread executable after losses and charges?

Compare price distribution, efficiency hurdle, market access, bid granularity and imbalance risk.

Before you start

  • A network with compatible buses, demand, generation and hourly snapshots.
  • An untouched base scenario that can complete a solve.
  • A decision rule for the site screen, such as price-spread reduction, peak shave, reliability or congestion relief.

What you will have

You will produce a cloned 30 MW / 4 h BESS scenario, paired base/BESS result IDs, a ranked site, operational deltas and an explicit list of investment inputs still missing.

Step-by-step

Complete the workflow

01

Frame the BESS decision and revenue boundary

Decide whether this is a siting, operations, reliability or investment study before selecting metrics.

Modeler BESS siting workflow with configurable capacity, duration and ranked-site inputs
Frame BESS as a controlled base-versus-change study with explicit size, duration and site count. · Captured in Modeler and hosted on Cloudinary.

Do this

  1. 1.Set power to 30 MW and duration to 4 h, equivalent to 120 MWh nameplate energy.
  2. 2.Choose topK = 1 for a single-site developer screen.
  3. 3.List physical metrics and commercial metrics separately.

Expected evidence

  • A one-site, 30 MW / 120 MWh operational question with defined acceptance metrics.

Worked calculation

Energy capacity = 30 MW × 4 h = 120 MWh

Trust check

The workflow’s operational result excludes capex, fixed O&M, degradation, augmentation, financing, taxes and contracted revenue.

02

Prepare the base data and time window

A BESS screen needs chronological demand, generation and network constraints; a price band alone is not a network model.

Atlas Data Shop catalogue open over Modeler with demand, market, generation and weather datasets
Prepare demand and market evidence with declared lineage before using them in a BESS screen. · Captured in Modeler and hosted on Cloudinary.

Do this

  1. 1.Load an appropriate State Model Library network or a Data Shop-built model.
  2. 2.Attach compatible hourly demand, generation and price-calibration signals when required.
  3. 3.Confirm the full study horizon has contiguous snapshots and common units.

Expected evidence

  • An active base scenario with a valid hourly solve and no unintended storage assets.

Trust check

Record whether each input is observed, derived or assumed; storage can only optimize against the signals the model actually contains.

03

Solve and preserve the base

Run the base before adding storage and save the result ID used by the BESS ranking step.

Modeler Run options showing the base scenario, pre-run lint information and solver compute profile
Solve and persist the untouched base with the same horizon and settings planned for the BESS case. · Captured in Modeler and hosted on Cloudinary.

Do this

  1. 1.Lint the base scenario and resolve all errors.
  2. 2.Run at the intended snapshot stride.
  3. 3.Record base result ID, horizon, price spread, p95 net load, average price, unserved energy and curtailment.

Expected evidence

  • A completed, persisted base result with time-series frames available to the workflow.

Trust check

Do not compare a native-hourly BESS case to a three-hour-stride base.

04

Configure the BESS siting workflow

In Workflows → BESS siting study, set Storage MW 30, Duration 4 and Sites 1.

Modeler BESS siting workflow configured for 30 MW, four hours and one ranked site
The workflow records the exact BESS capacity, duration and number of candidate sites before execution. · Captured in Modeler and hosted on Cloudinary.

Do this

  1. 1.Open Workflows and select BESS siting study.
  2. 2.Enter 30 MW, 4 hours and top 1 site.
  3. 3.Confirm the workflow will solve the base, rank buses, clone the scenario, place BESS, re-solve and compare.

Expected evidence

  • The visible workflow summary reflects 30 MW / 4 h across one site before launch.

Copy into Modeler Agent

Run a BESS siting study on the active untouched base with 30 MW total storage, 4 hour duration and one site. Keep the base unchanged and report both result IDs, the selected bus, price-spread change, peak-net-load change and modeled revenue evidence. Do not claim project ROI.

Trust check

The storage assets use 92% charge efficiency and 92% discharge efficiency in the current workflow; cite that implementation assumption.

05

Check storage physics and the loss hurdle

Translate nameplate power and duration into energy, round-trip efficiency, feasible SOC movement and the minimum price spread needed to cover losses.

Modeler BESS workflow configuration with GridAI closed showing 30 MW power, four-hour duration, one ranked site and the repeatable storage operations
Translate 30 MW and four hours into 120 MWh, verify 84.64 percent round-trip efficiency and calculate the loss-only price hurdle. · Captured in Modeler and hosted on Cloudinary.

Do this

  1. 1.Confirm 30 MW × 4 h = 120 MWh nameplate energy.
  2. 2.Confirm 92% charge and 92% discharge efficiency produce 84.64% round-trip efficiency.
  3. 3.Inspect cyclic state-of-charge and any initial/final SOC constraint.
  4. 4.At an example ₹3,000/MWh charge price, calculate the loss-only discharge hurdle before degradation and fees.

Expected evidence

  • SOC remains within energy bounds and closes the cycle when cyclic SOC is enabled.
  • Loss-only discharge hurdle ≈₹3,544/MWh, or ≈₹544/MWh spread above ₹3,000/MWh charging energy.

Worked calculation

Nameplate energy = 30 MW × 4 h = 120 MWh
Round-trip efficiency = 0.92 × 0.92 = 0.8464 = 84.64%
Loss-only discharge hurdle = ₹3,000 / 0.8464 ≈ ₹3,544/MWh

How to read the result

  • The economic hurdle rises further with degradation, auxiliary load, market fees and charging/network charges.
  • Cyclic SOC prevents the model from creating value by ending the horizon emptier than it began.
  • Duration does not guarantee discharge at the system peak; inspect SOC availability in that hour.

Trust check

Reject any arbitrage claim that ignores round-trip loss or obtains value from an unconstrained terminal SOC.

06

Review ranking and placement before reading value

The workflow ranks buses from modeled local price spread and evening ramp, then places storage only in the clone.

Modeler BESS workflow step details for ranking stressed buses from the persisted base result
Inspect each workflow operation, input frame and output artifact before accepting the automated sequence. · Captured in Modeler and hosted on Cloudinary.

Do this

  1. 1.Inspect the selected bus name, score, local spread and ramp.
  2. 2.Open Tables → Storage in the clone and confirm one 30 MW asset with max_hours = 4.
  3. 3.Verify the base still contains no new storage asset.

Expected evidence

  • One 30 MW / 4 h storage unit in the cloned scenario and zero unintended changes in base.

Trust check

A top-ranked modeled bus is a screening candidate, not proof of land, bay, evacuation, protection or commercial availability.

07

Inspect charge, discharge and state of charge hour by hour

The battery mechanism must be visible in chronology, not inferred from an annual revenue total.

Modeler BESS workflow step detail with GridAI closed showing the re-solve and decision-dashboard path used to inspect charge, discharge and state of charge
Audit the hourly battery mechanism and reconcile charged energy, discharged energy, losses and cyclic state of charge before valuing dispatch. · Captured in Modeler and hosted on Cloudinary.

Do this

  1. 1.Plot charge power, discharge power and SOC on the same 168-hour clock as load and price.
  2. 2.Check that charge and discharge do not occur simultaneously unless the formulation explicitly permits and justifies it.
  3. 3.Locate the top discharge hours and identify the displaced marginal generator or avoided shortfall.
  4. 4.Reconcile charged MWh, discharged MWh and round-trip losses using snapshot weights.

Expected evidence

  • A SOC trace within 0–120 MWh and power within ±30 MW.
  • A physical explanation for each high-value dispatch interval.

Worked calculation

SOCₜ = SOCₜ₋₁ + ηcharge × chargeₜ × Δt − dischargeₜ × Δt / ηdischarge
Energy loss = charged MWh − discharged MWh

How to read the result

  • If the battery discharges during scarcity but cannot recharge without fossil generation, reliability can improve while carbon worsens.
  • Snapshot weighting must be applied to both energy and value; summing MW without duration is dimensionally wrong.

Trust check

A plausible total revenue is insufficient if the hourly SOC and power trajectory violates physics or horizon closure.

08

Compare the paired results

Read price flattening, p95 net-load reduction, dispatch, state of charge, unserved energy, curtailment and affected constraints together.

Modeler Run evidence workbench with comparison selector, immutable-run link, units and source-input fields
Compare BESS and base results through persisted evidence, not a detached headline or screenshot alone. · Captured in Modeler and hosted on Cloudinary.

Do this

  1. 1.Pin base and BESS result IDs.
  2. 2.Compare like-for-like metrics over the identical horizon.
  3. 3.Inspect the before/after net-load chart and BESS discharge band.
  4. 4.Open Map for the selected bus and nearby corridors.

Expected evidence

  • A before/after table and a physical explanation of when and where the battery charged and discharged.
Minimum BESS comparison table
MetricBase30 MW / 4 h BESSDecision use
Price spread (₹/MWh)recordrecordArbitrage / price flattening
p95 net load (MW)recordrecordPeak contribution
Unserved energy (MWh)recordrecordReliability
Curtailment (MWh)recordrecordRenewable capture
Marginal emissions (gCO₂/kWh)recordrecordCarbon effect
Incident corridor loading (%)recordrecordNetwork effect

Trust check

A lower modeled price spread can coexist with higher emissions or different corridor loading; do not optimize one KPI invisibly.

09

Read the reliability–carbon trade-off

Storage can reduce unserved energy and cost while increasing marginal emissions; quantify both directions and explain the dispatch cause.

Modeler BESS decision output with GridAI closed for comparing unserved energy, operating cost, marginal emissions and local corridor loading together
Preserve the recorded mixed result: reliability and cost improved while marginal carbon and local loading worsened. · Captured in Modeler and hosted on Cloudinary.

Do this

  1. 1.Calculate absolute and percentage changes in unserved energy and incremental operating cost.
  2. 2.Calculate the marginal-emissions intensity change and identify charging-hour marginal generation.
  3. 3.Compare curtailment and renewable charging share if available.
  4. 4.Report whether improved reliability depends on stored energy available before the scarcity window.

Expected evidence

  • Recorded benchmark reproduced: unserved energy 3.58 → 2.94 GWh (about 17.9% lower).
  • Recorded benchmark reproduced: marginal emissions 563 → 607 gCO₂/kWh (about 7.8% higher).

How to read the result

  • The recorded result is a methodological benchmark; current decisions require a fresh run with current data and result IDs.
  • An environmental conclusion needs both total emissions and marginal-intensity mechanism; neither can be inferred from cost alone.
Recorded reliability and carbon benchmark
MetricNo BESSBESSDelta
Unserved energy3.58 GWh2.94 GWh−0.64 GWh / −17.9%
Operating costbaseline≈₹19 lakh lower≈−3.6%
Marginal emissions563 gCO₂/kWh607 gCO₂/kWh+44 / +7.8%
Local corridor peak22.5%24.4%+1.9 percentage points

Trust check

Do not choose a single green/red verdict. Preserve the multi-metric trade-off and state which objective the project prioritizes.

10

Benchmark power, duration and efficiency sensitivities

Test whether the decision depends on MW, MWh, efficiency or one exceptional modeled week.

Modeler BESS workflow controls with GridAI closed, prepared to vary storage power, duration, site count and baseline reuse across matched sensitivity runs
Benchmark power, duration, efficiency and stress scenarios separately to expose diminishing value and the first binding constraint. · Captured in Modeler and hosted on Cloudinary.

Do this

  1. 1.Run at least 15/30/45 MW and 2/4/6 h cases from the same base.
  2. 2.Test lower efficiency or an explicit degradation throughput cost.
  3. 3.Repeat under a higher-demand, lower-renewable or tighter-corridor scenario.
  4. 4.Plot diminishing value per added MW and MWh and identify the first binding interconnection constraint.

Expected evidence

  • A sensitivity surface for cost, unserved energy, emissions, curtailment and corridor loading.
  • A conditional sizing range rather than one unsupported optimum.

How to read the result

  • Power governs instantaneous response; duration governs energy coverage. They should not be varied as one combined scalar.
  • Value usually diminishes as storage flattens the very spread or scarcity that created the first unit of value.

Trust check

Call the result a screening range until interconnection, degradation, availability, capex and contracted revenues are included.

11

Build the investment bridge outside the operational solve

Use modeled dispatch and spread as evidence inputs, then add contract, capex and finance assumptions in a separate investment case.

Modeler result workbench beside an Agent prompt separating modeled arbitrage from excluded BESS revenues
Keep operating-value evidence separate from capex, degradation, financing and market-access assumptions. · Captured in Modeler and hosted on Cloudinary.

Do this

  1. 1.Export annualized arbitrage evidence only with the workflow’s stated method and coverage.
  2. 2.Add capex, EPC, land, bay/evacuation, degradation, augmentation, O&M, taxes, debt and contracted revenue as explicit inputs.
  3. 3.Run downside cases for availability, spread compression and delayed commissioning.

Expected evidence

  • An investment model whose non-Modeler assumptions are visible instead of hidden in a headline ROI.

Trust check

Do not quote payback, IRR or DSCR from a zero-capex operational dispatch result.

12

Prepare the developer evidence pack

The pack should let a utility, lender or investor trace every headline back to a model, scenario and source.

Modeler result workbench beside an Agent prompt for an investment-committee BESS evidence handoff
The handoff requests assumptions, source hashes, run ID, units, exclusions and next diligence actions. · Captured in Modeler and hosted on Cloudinary.

Do this

  1. 1.Include network scope, data windows, base/BESS result IDs and solver settings.
  2. 2.Include selected bus and nearby constraint checks.
  3. 3.Include the full assumption register and missing interconnection evidence.

Expected evidence

  • A repeatable screen with a clear next diligence request, not a marketing-only savings claim.

Trust check

For a bankable project, replace public or modeled network assumptions with utility-supplied ratings, outages and interconnection data.

Before you share

Completion checklist

  • Base and BESS cases use the same horizon and stride.
  • 30 MW, 4 h, 120 MWh and one-site inputs are visible.
  • 92% charge and 92% discharge efficiencies are cited.
  • The base is unchanged; storage exists only in the clone.
  • Both result IDs and the selected bus are saved.
  • Physical, market, carbon and network effects are compared together.
  • Capex, degradation, financing and contracted revenue remain separate explicit inputs.

Answer desk

Frequently asked questions

Can Modeler tell me the best BESS site in India?

It can rank candidate buses inside the active model for the chosen signals and horizon. The result is a screening rank, not proof of land, interconnection capacity, permits or commercial availability.

Does the BESS workflow calculate project IRR?

No. It reports operational and modeled revenue evidence. A project IRR requires capex, degradation, augmentation, availability, contracts, financing, tax and commissioning assumptions.

Why use topK = 1 for this example?

A small developer usually needs a single-site screen. topK = 1 keeps all 30 MW at the highest-ranked modeled bus; portfolio studies can spread capacity across more sites.

← PreviousData Shop guideNext →National BESS siting