Market User Guide

Market Objects
Current market objects (non-deprecated) include:


 * Auction objects (bid collection and market clearing):
 * Auction
 * Stubauction


 * Controller objects (modify behavior of controlled object and may bid into market):
 * Controller
 * Passive Controller
 * Generator Controller


 * Bidding objects (bids into a market, but does not control the response of any other object):
 * Stub Bidder


 * Functional objects (contain functions for use by auction and controller objects - not described here)
 * Bid
 * Curve

Auction Object
The auction provides a means for different objects within the GridLAB-D program to base their supply or demand on a dynamic or real time price. The market implemented in the auction object is implemented as a double-auction market. A double-auction market is one where suppliers and demanders (sellers and bidders) submit their bids of desired price for a set quantity simultaneously. Once the bidding submission period ends, the market "clears" by selecting the intersection point of the supply and demand curves. After the market clears and the relevant latency interval expires, the market price becomes active. At this point, devices that bid into the market will respond appropriately based on internal logic comparing their bid price to the market clearing price. The auction object does not provide any book-keeping or enforcement of the market, it simply provides a central market for buyers and sellers to bid their respective prices and quantities.

Further information describing clearing mechanisms and basic operation can be found at Market_module.

Auction Parameters
  Additionally, the auction objects has published functions that can be used in runtime classes or other objects to get bid information into the auction object (submit_bid and submit_bid_state). The two are similar, except the latter has an additional input to define whether the state or if the load is currently ON or OFF (1 or 0) when the bid occurs. This is used for accounting in the capacity_reference_bid_quantity. The format is:


 * submit_bid( market object, bidding object, quantity, price, market id )
 * submit_bid_state( market object, bidding object, quantity, price, current state, market id )

Examples of Auction Use
This is an auction setup for a single-sided market that allows controllers to respond to changes in price relative to the standard deviation and mean of the previous 24 hours:

class auction { double current_price_mean_24h; double current_price_stdev_24h; }

object auction { name Market_1; period 900; special_mode BUYERS_ONLY; unit kW; object player { file price.player; loop 10; property current_market.clearing_price; }; }

You could also set up your own static values and not use the built-in statistics:

class auction { double my_avg; double my_std; }

object auction { name Market_1; period 900; special_mode BUYERS_ONLY; unit kW; statistic_mode OFF; my_avg 0.110000; my_std 0.037953; object player { file price.player; loop 10; property current_market.clearing_price; }; }

To set up a congestion object with a full double-auction market, where the capacity object could bid in the LMP of the feeder, with a power limit of 1200 kW, and starts collecting bids immediately:

class auction { double current_price_mean_24h; double current_price_stdev_24h; }

object auction { name Market_1; period 900; unit kW; capacity_reference_object Substation_Transformer; capacity_reference_property power_out_real; max_capacity_reference_bid_quantity 1200; //Defaults to 1200 kW    init_price 0.10; init_stdev 0.03; warmup 0; object player { file price.player; loop 10; property capacity_reference_bid_price; };    } 

Auction State of Development
This model has been well tested and validated, however, as it is used for current and future applications, additional features are added continuously.

<BR>

Controller Object
The controller is loosely based upon the design used in the Olympic Peninsula Project. This controller provides price-responsive controls (or other control inputs) to individual objects, typically appliances, within GridLAB-D. The controller compares the current price signal to the average market price, each delivered by the auction object, and bids the appliance’s current demand as a function of price back into the auction. After the market clears all bids within the system and determines the next market price, the controller modifies the appliance’s set points to reflect operation at the new current price, often related to the standard deviation from the average set point. The set point that is modified depends upon the object to which the controller is modifying. At this time, only devices with continuous temperature set points may be used with the controller object. As this object is expanded, additional controls may added that align with the general design principles.

Further information describing bidding mechanisms and basic operation can be found at Transactive Control Specifications.

Controller Parameters
Table 1: Controller inputs.

Examples of Controller Use
Assume an auction setup of:

class auction { double current_price_mean_24h; double current_price_stdev_24h; double my_avg; double my_std; }

object auction { name Market_1; period 300; unit kW; capacity_reference_object Substation_Transformer; capacity_reference_property power_out_real; max_capacity_reference_bid_quantity 1200; //Defaults to 1200 kW    init_price 0.10; init_stdev 0.03; my_avg 0.15; my_std 0.05; warmup 0; object player { file price.player; loop 10; property capacity_reference_bid_price; };    }

Then, a bidding controller for an HVAC system in DOUBLE_RAMP and SLIDING modes, which bids 60 seconds prior to the market closing and uses the previous 24 hours of cleared prices to determine that statistics for responsiveness, could be setup as:

object controller { name testController_1; parent house_1; market Market_1; control_mode DOUBLE_RAMP; resolve_mode SLIDING; bid_mode ON; heating_base_setpoint 65; cooling_base_setpoint 75; target air_temperature; deadband thermostat_deadband; average_target current_price_mean_24h; standard_deviation_target current_price_stdev_24h; period 300; cooling_setpoint cooling_setpoint; heating_setpoint heating_setpoint; heating_demand last_heating_load; cooling_demand last_cooling_load; bid_delay 30; heating_range_high 0.265; cooling_range_high 0.442; heating_range_low -0.442; cooling_range_low -0.265; heating_ramp_high -2.823; cooling_ramp_high 2.823; heating_ramp_low -2.823; cooling_ramp_low 2.823; total total_load; load hvac_load; state power_state; };

A similar HVAC controller for RAMP mode, controlling only the cooling load and bidding immediately prior to market closing, but uses predefined values for average and standard deviation, would be:

object controller { name testController_3; market Market_1; parent house_3; bid_mode ON; control_mode RAMP; base_setpoint 75; setpoint cooling_setpoint; target air_temperature; deadband thermostat_deadband; average_target my_avg; standard_deviation_target my_std; period 300; demand last_cooling_load; range_high 0.431; range_low -0.258; ramp_high 2.828; ramp_low 2.828; //slider_setting 0.2; //This could replace range_high,range_low, ramp_high, and ramp_low. total total_load; load hvac_load; state power_state; };

Controller State of Development
This model has been well tested and validated, however, as it is used for current and future applications, additional features are added continuously.

Controller2 Object
Deprecated to Passive Controller.

Double Controller Object
Deprecated to Controller.

Generator Controller Object
In development.

Generator Controller Parameters
In development.

Examples of Generator Controller Use
TODO.

Generator Controller State of Development
In development.

Passive Controller Object
This controller is similar to the controller object, except without the capability to bid back into an auction. It is designed as a passive demand response controller, which only receives price (or other) signals, generally from an auction or stubauction object, and responds accordingly. Additionally, it is used as a test bed for future transactive controller strategies, as it is easier to implement a passive response than an active bidding market.

Further information describing bidding mechanisms and basic operation can be found at Transactive Control Specifications.

Passive Controller Parameters
The following table describes available properties of the passive controller

Examples of Passive Controller Use
Assume an auction setup of:

class auction { double current_price_mean_24h; double current_price_stdev_24h; double my_avg; double my_std; }

object auction { name Market_1; period 300; unit kW; capacity_reference_object Substation_Transformer; capacity_reference_property power_out_real; max_capacity_reference_bid_quantity 1200; //Defaults to 1200 kW   init_price 0.10; init_stdev 0.03; my_avg 0.15; my_std 0.05; warmup 0; object player { file price.player; loop 10; property capacity_reference_bid_price; };    }

To create an HVAC passive_controller, similar to a controller in RAMP mode that does not bid:

object passive_controller { period 300; parent house1; control_mode RAMP; observation_object Market_1; observation_property current_market.clearing_price; stdev_observation_property current_price_stdev_24h; expectation_object Market_1; expectation_property current_price_mean_24h; range_low -0.005; range_high 3; ramp_low 2.4; ramp_high 2.4; base_setpoint 75; setpoint_property cooling_setpoint; state_property power_state; };

A passive_controller, modifying the behavior of an analog ZIPload by using the ELASTICITY_MODEL with a 2-tier TOU and no CPP, would look like:

object passive_controller { period 300; parent ZIPload1; control_mode ELASTICITY_MODEL; two_tier_cpp false; observation_object Market_1; observation_property past_market.clearing_price; state_property multiplier; linearize_elasticity true; price_offset 0.01; critical_day 0; first_tier_hours 12; second_tier_hours 12; first_tier_price 0.076351; second_tier_price 0.152702; old_first_tier_price 0.124300; old_second_tier_price 0.124300; daily_elasticity -0.1305; sub_elasticity_first_second -0.0198; sub_elasticity_first_third -0.0290; };

The same passive_controller, again in ELASTICITY_MODEL modifying a ZIPload, in a situation with TOU and CPP (price pattern shown in the following figure) would be:



object passive_controller { period 300; parent ZIPload1; control_mode ELASTICITY_MODEL; two_tier_cpp true; observation_object Market_1; observation_property past_market.clearing_price; state_property multiplier; linearize_elasticity true; price_offset 0.01; critical_day critical_day_schedule.value; //schedule with a 1 on critical days, and 0 on normal days first_tier_hours 12; second_tier_hours 12; third_tier_hours 6; first_tier_price 0.076351; second_tier_price 0.152702; third_tier_price 0.76351; old_first_tier_price 0.124300; old_second_tier_price 0.124300; old_third_tier_price 0.124300; daily_elasticity -0.1305; sub_elasticity_first_second -0.0198; sub_elasticity_first_third -0.0290; };

A passive_controller modifying the behavior of a waterheater in a manner similar to the Olympic Peninsula Demonstration project, using PROBABILITY_OFF, would look like:

object passive_controller { period 900; // Note period is a multiple of auction period. parent waterheater1; control_mode PROBABILITY_OFF; distribution_type NORMAL; observation_object Market_1; observation_property past_market.clearing_price; stdev_observation_property my_std; expectation_object Market_1; expectation_property my_avg; comfort_level 0.82; state_property override; };

A passive_controller in DUTYCYCLE mode, modifying the behavior of a ZIPload (which has a duty_cycle defined), would look like:

object ZIPload { name pool_pump1; parent house1; // Representative of Pool Pump operation base_power 1400 W;     duty_cycle 0.22; phase 0.26; period 4.96; heatgain_fraction 0.0; power_pf 1.0; current_pf 1.0; impedance_pf 1.0; impedance_fraction 0.2; current_fraction 0.4; power_fraction 0.4; is_240 TRUE; recovery_duty_cycle 0.27; object passive_controller { period 900; control_mode DUTYCYCLE; pool_pump_model true; observation_object Market_1; observation_property past_market.clearing_price; state_property override; base_duty_cycle 0.22; setpoint duty_cycle; first_tier_hours 12; second_tier_hours 12; third_tier_hours 6; first_tier_price 0.070489; second_tier_price 0.140979; third_tier_price 0.704894; }; };

Passive Controller State of Development
This model has been well tested and validated, however, as it is a testbed for future applications, additional features are added continuously.

Stubauction Object
This object performs in a similar manner to an auction object in the BUYERS_ONLY mode. This object will most likely be deprecated in versions 3.0 and greater.

Examples of Stubauction Use
TODO.

Stubauction State of Development
This model has been fully tested and validated.

Stub Bidder Object
This object is a "fake" bidder into the market. It can perform price and quantity bids (both buy and sell), but will not be directly reflected on the power system solution. Additionally, it is not able to control another device as a response to the price. This object is generally used for testing purposes, or to "fill out" a market that doesn't have enough buyers or sellers to be stable. According to its design, it is only able to use the submit_bid function, and does not support submit_bid_state.

Examples of Stub Bidder Use
TODO.

Stub Bidder State of Development
This model has not been fully tested or validated.

= See also = Market_module

Market Specifications

Controller Specifications

Wholesale_Markets