From GridLAB-D Wiki
Jump to: navigation, search

NOTE: This object and page are deprecated. Its functionality has been folded into the Controller object.

The double-setpoint controller is used to specifically control demand-responsive thermostats that have price-responsive cooling and heating systems.

Behavior

The double_controller was originally created after it was observed that using two normal controllers could create implausible setpoint combinations given low prices and both pre-heating and pre-cooling, and could improperly bid the sum of both the heating and cooling power demands to the same cycle. The double controller is thus designed to specifically determine what the proper bid price and quantity is for a given temperature when both the heating and cooling systems are bidding to preheat and precool at the same time. It will also properly adjust setpoints to better facilitate whether the controller is currently heating or cooling a house, and prevent setpoint overlap.

Actors

The double_controller object is meant to attach itself to another object to control two setpoints to maintain a given observation between those two point. It is implicitly assumed with the initial version that it is meant to control an HVAC thermostat in order to keep the observed air temperature within a certain range.

Parent

The double_controller's parent is the source of temperature and setpoint observations, and is the affected by the setpoint determinations from the double_controller. The parent's setpoints are completely overwritten during the simulation process, and control of the base setpoint is done by writing values to heat_set_base and cool_set_base, rather than heating_setpoint and cooling_setpoint for the house, for example.

Market

The market object referenced is both used for input price signals and to post bids for power demand. The controller will sync up as frequently as the market does, updating the setpoints as the market clears and posts new prices. If the controller does not post bids, the market will only be used to calculate the setpoints for the next cycle in the same fashion that it would had it posted a bid that would have 'purchased' power.

Properties

thermostat_mode and last_mode

These two enumerations store the current and previous 'desire' of the thermostat. The current state, as determined by temperature and the bid price is in 'thermostat_mode'. This current state will be copied to 'last_state' between timesteps, and will be either HEAT or COOL during both the period of time that the thermostat is demanding heating or cooling, but will also persist for up to six hours afterwards if neither is demanded or activated for a period of time.

INVALID

This is the initial state for both modes, and is replaced by another state as soon as possible. It may be used in the future to indicate that the thermostat controller as a whole has an invalid configuration.

OFF

The thermostat is neither heating nor cooling.

HEAT

The thermostat is operating as if the device it is attached to needs more heat.

COOL

The thermostat is operating as if the device it is attached to needs to shed heat.

resolve_mode

This enumeration determines the strategy to resolve any conflicts or potential conflicts between the heating and cooling setpoints. If the setpoint changes sufficiently, it is possible for one or both sides of the controller to preempt the bid and remain inactive.

NONE

By default, the controller will resolve every conflict in favor of additional cooling, adjusting the heating setpoint downwards as far as the base heating setpoint. If the adjusted heating setpoint is below the base heating setpoint, the cooling setpoint will be adjusted upwards slightly.

DEADBAND

This strategy resolves conflicts by finding the average setpoint temperature and setting both setpoints equally distant from that average.

STICKY

The previous thermostat state is used to determine which setpoint is favored in conflicts. The thermostat will keep the heating setpoint if the thermostat is in a heating mode, and will keep the cooling setpoint if the thermostat is in a cooling mode.

setup_mode

This enumeration is used for convenience to reduce the complexity of connection to specific devices.

NONE

No assumptions will be made about the parent object that is being controlled.

HOUSE

The parent object is assumed to be a residential module house object.

bid_mode

The bid mode determines if the controller will bid its price and quantity to its associated market.

ON

The controller will post a bid price and power demand to the associated market (in dollars and kilowatts). Should the posted market clearing price be greater than the bid price, the thermostat's setpoints will be set to those at which it is no longer price-responsive.

OFF

The controller will operate solely on the input price signal, and determines its setpoints independently of the internal temperature.

ramps

The ramp values determine the number of standard deviations in the price signal are required before the thermostat will place a setpoint at the maximum of its allowed range. Cooling ramps must be positive, heating ramps must be negative.

cool_ramp_low

The number of standard deviations for the thermostat to maximize its precooling price exploitation.

cool_ramp_high

The number of standard deviations for the thermostat to maximize its cooling deferral.

heat_ramp_low

The number of standard deviations for the thermostat to maximize its heating deferral.

heat_ramp_high

The number of standard deviations for the thermostat to maximize its preheating price exploitation.

ranges

The range determines the 'width' of the thermostat's price-responsive band. The inner edge of the ranges represent the extent to which the thermostat will allow its precool or preheat. The outer edge of the ranges represents the point at which the thermostat will become unresponsive to price signals, and will run regardless of external data. Low ranges must be negative. High ranges must be positive. Ranges are measured in degrees Fahrenheit from the base setpoint.

cool_range_low

The number of degrees the thermostat will precool, given below-average prices.

cool_range_high

The number of degrees the thermostat will allow cooling to slip, given above-average prices.

heat_range_low

The number of degrees the thermostat will allow heating to slip, given above-average prices.

heat_range_high

The number of degrees the thermostat will preheat, given below-average prices.

names

The name properties reference the properties in the parent object that will be used for inputs and outputs with the controller.

temperature_name

The name of the temperature observation property.

cool_setpoint_name

The name of the cooling setpoint property, read at the initial timestep to determine the base cooling setpoint, and later used to post the controller's desired cooling setpoint.

cool_demand_name

The name of the property that posts the power demand of the cooling system, in kW.

heat_setpoint_name

The name of the heating setpoint property, read at the initial timestep to determine the base heating setpoint, and later used to post the controller's desired heating setpoint.

heat_demand_name

The name of the property that posts the power demand of the heating system, in kW.

load_name

The name of the property that contains the current controllable power load within the parent object.

total_load_name

The name of the property with the currently uncontrollable power load within the parent. Needed for bidding reasons.

last_mode_timer

The number of seconds until last_state will 'forget' whether it was heating or cooling in the recent past.

heat_set_base

The base heating setpoint that is used to determine the price response interval. Can be externally controlled.

heat_setpoint

The current heating setpoint, calculated based on the temperature observation, the price signal, and the controller's ramp and range values.

cool_set_base

The base cooling setpoint that is used to determine the price response interval. Can be externally controlled.

cool_setpoint

The current cooling setpoint, calculated based on the temperature observation, the price signal, and the controller's ramp and range values.

market

The market object reference to post bids to and retrieve price signals from.

market_period

The number of seconds between market clearing cycles. The controller defers price updates until the market has cleared.

bids and demand

Both the heating and cooling sides of the thermostat have independent price and quantity demands, which are separately calculated in parallel. If the thermostat has bid prices for both the heating and cooling systems, the controller will use the resolve_mode to determine whether the heating or cooling bid should be posted.

cool_bid

The price the thermostat is willing to pay per kilowatt-hour of energy to run the cooling system.

heat_bid

The price the thermostat is willing to pay per kilowatt-hour of energy to run the heating system.

cool_demand

The power draw, in kilowatts, that the cooling system will consume if it runs.

heat_demand

The power draw, in kilowatts, that the heating system will consume if it runs.

bid_price

The per-kilowatt price that the controller submitted in its bid to the market.

bid_quant

The number of kilowatts of power that the controller submitted in its bid to the market.

load

The controllable power consumption of the attached parent.

total

The total of the controllable and uncontrollable power consumption of the attached parent.

last_price

The price sent to the market for the previous auction session.

temperature

The current temperature observation inside the parent.

price

The most recently received current price signal.

avg_price

The most recently received average price signal.

stdev_price

The most recently received price standard deviation signal.

Functions

The double_controller has no published functions.

See also

Market_User_Guide

Market_module

Market Specifications

Controller Specifications

Wholesale_Markets