From GridLAB-D Wiki
Jump to: navigation, search

 Proposed for review 

Interaction of DR and Two Settlement Markets

The purpose of this module is to examine the behavior (e.g., information flow, power flow, money flow) between the day-ahead and the real time markets of a two-settlement market system. The time horizon of this analysis can range from a few days up to several years.

The user will need to establish a model for an ISO and LSE operation, run that model with a set of loads and generators in the context of a transmission and distribution power delivery system, and extract data regarding the financial, electrical, and consumer behavior of the total system.

The user needs to provide data regarding the ISO operations, such as the DA LMP, RT LMP, dispatch amount, real load, self-supply disposition rules, market rules and timing, security constrained unit commitment procedure, security constrained economic dispatch process, security constrained optimal power flow procedure, energy and reserve co-optimization procedure, and the real-time load forecast.

The user needs to provide data regarding the LSE operations, such as type of company (e.g., private, public), wholesale purchasing bidding/bilateral longterm purchasing strategy, self-supply strategy, demand programs (e.g., direct load control), consumer rates and tariffs (industrial, agricultural, commercial, residential, renewable resources, demand response).

The user needs to provide the transmission and distribution power delivery structure, such as major line constraints, location of generation resources, location of loads, network structure, power, voltage and current information, and location of major control and distribution equipment.

The user needs to provide the generation participants at the wholesale and retail level, including capacity, energy cost, ramping rates, supply curve, emissions/energy constraints.

The user needs to provide the consumer participants at the wholesale and retail level, including elasticity, available devices, population diversity, consumption patterns, capacity, and ramping.

The user seeks results of voltage, current, power, energy profiles, revenue, fuel consumption, emissions, profit, price profiles, cost profiles, at generation, transmission, distribution and meter levels.


Load Serving Entity (e.g., a utility).
Independent System Operator (e.g., MISO, PJM, ERCOT).
Day Ahead market.
Real Time market.
Locational Marginal Price

Demand Response (and Generation)

The questions to be answered by this section are:

  1. Can demand response offset the variability of wind or other non-controllable generation sources?
  2. Can demand response reduce the capacity of transmission systems, distribution systems, generation, or the system as a whole?
  3. What are the effects of demand response on customer bills and energy consumption?
  4. What are the local, regional, and national effects of demand response?
  5. How do various control strategies affect consumer use patterns and their end-use appliances?

The user will need to compare the demand and energy consumption at various levels of their model - overall, feeder, neighborhood, house, etc.

The user will need to have a complete breakdown of the demand and energy consumption.

The user will need to include generation cost curves, and other generation bidding abilities, as part of the powerflow solution.

The user will need to create a bidding strategy which includes all components (transmission lines, feeders, generators, etc.).

The user will need to incorporate demand response into energy storage and generator control strategies. This will minimally include optimal placement, optimal operation, optimal cycling, cost and ownership contingencies.

The user will need an interface for adding optimization strategies which will minimally include the ability to create multiple area networks (home area networks, communities, feeders, etc.).

The user will need customizable, centralized plant models (e.g. wind farms, base plants, etc.).

The user will need an automated Monte Carlo simulator to test varieties of cases.

The user will need to create multiple "climates" on a single system - the system needs to contain multiple regions with each region having its own weather.