> ## Documentation Index
> Fetch the complete documentation index at: https://docs.models.dunsky.com/llms.txt
> Use this file to discover all available pages before exploring further.

# DR standalone demand response analysis

> Run demand response analysis independently, estimate enrollment and dispatch impacts, and optionally connect the results to a DERP potential study.

DR estimates how flexible resources can enroll, dispatch and change electricity load. You can run DR independently of DERP, using its own market, measure, program and load-profile inputs. You can also connect it to DERP when a study needs adoption-driven market changes and feedback into resource potential results.

## What DR answers

* How many units are eligible, enrolled and called under the program assumptions?
* How does curtailment, pre-charging and rebound change a typical day or an annual hourly load curve?
* How much peak reduction remains after resources interact?
* Which eligible grid-service streams can dispatch serve, subject to caps and operating constraints?
* How do incentives, participation, cost-effectiveness screening and program competition change the result?

## Two execution contexts

| Context | Market and measure preparation | Result |
| - | - | - |
| Standalone DR study | DR reads its study workbooks directly and constructs dispatch records | DR impact, load-curve, enrollment and financial reporting |
| DR connected to DERP | DERP supplies a handoff containing year/scenario market and impact records | DR reporting plus selected results written back to DERP |

Both runners are distributed in the Python package named `derp`. A standalone DR study can read DER measure characterization for economics without executing the DERP technical, economic or achievable potential engine.

The term **standalone per-unit impact** in DR output has a second, narrower meaning: a resource's independently evaluated impact before portfolio interactions. That output metric is available within an analysis and must not be confused with whether the overall study was launched independently from DERP.

## Run DR locally

After installing and configuring the package using the [README](https://github.com/dunsky-consulting/packages/blob/trunk/derp/README.md), inspect the DR module's CLI:

```bash theme={null}
python -m derp.run_demand_response --help
```

Run a workbook-based standalone study with the actual input paths:

```bash theme={null}
python -m derp.run_demand_response \
  --source write-to-file \
  --dr-measures "data/inputs/DR Measures.xlsx" \
  --der-measures "data/inputs/Measures.xlsx" \
  --markets "data/inputs/Markets.xlsx" \
  --programs "data/inputs/Programs.xlsx" \
  --settings "data/inputs/Settings.xlsx" \
  --valuations-and-rates "data/inputs/Valuations and Global Inputs.xlsx" \
  --adoption "data/inputs/Adoption.xlsx" \
  --output_file "data/outputs/DR_Outputs.zip"
```

The package currently registers a `derp` console command; the DR invocation above uses its separate Python module. Do not assume a separately installed `drp` console executable exists.

## Choose the temporal and grid scope

Typical-day analysis uses 24-hour weekday, weekend and peak representations by period, including configured call-number evaluations. Annual analysis uses the 8,760-hour sequence with event-count, cooldown and availability constraints. Typical-day results are not a substitute for annual chronology.

Local, regional-bulk and bulk modes change the grid aggregation used for load layering and dispatch. A node-level peak reduction and the reduction in an aggregated system peak answer different questions; report the active mode with the result.

## Read the model specification

* [Enrollment, load curves and dispatch equations](https://docs.models.dunsky.com/en/models/derp/dr/specification.md)
* [Optional DERP integration](https://docs.models.dunsky.com/en/models/derp/specification.md#optional-dr-integration)
* [Shared financial calculations](https://docs.models.dunsky.com/en/models/derp/specification.md#financial-calculations)

DR dispatch is a planning analysis using supplied profiles and program assumptions. The registered peak-chasing and system-needs strategies place resources sequentially; their results should not be interpreted as a guarantee of a globally optimal portfolio or as live device control.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.