emix — archive

RE: Normalizing Price and Load Resources

From: Edward Cazalet
To: [email protected]
Date: Wed, 23 Feb 2011 01:05:00 -0000

What you suggest may be helpful. But, some types of resources can’t be well represented with ISO bid curves. Examples include cascaded hydro dams, pumped hydro, battery storage, combined cycle generation. Forwarded to the emix lists for discussion. Edward G. Cazalet, Ph.D. 101 First Street, Suite 552 Los Altos, CA 94022 650-949-5274 cell: 408-621-2772 [email protected] www.cazalet.com From: Toby Considine [mailto:[email protected]] On Behalf Of Toby Considine Sent: Monday, February 21, 2011 6:24 PM To: 'Ed Cazalet' Cc: 'Bill Cox' Subject: RE: Normalizinh Price and Load Resources Incremental is the only thing that makes sense, IMHO I am thinking that on the Ramp side we need an “integral” flag, i.e, you can request 50 MW or 75 MW, but not 60 (if the 50-75 ramp is integral = true) It can always be conformed away by a particular market. I think this would handle the dead bands. tc "If something is not worth doing, it`s not worth doing well" - Peter Drucker Toby Considine TC9, Inc TC Chair: oBIX & WS-Calendar TC Editor: EMIX, EnergyInterop U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee Email: [email protected] Phone: (919)619-2104 http://www.tcnine.com/ blog: www.NewDaedalus.com From: Ed Cazalet [mailto:[email protected]] Sent: Monday, February 21, 2011 6:57 PM To: [email protected] Cc: 'Bill Cox' Subject: RE: Normalizinh Price and Load Resources The price curves have some additional important attributes. There are two types: average price and incremental price. The ISOs use incremental price curves. Each curve segment is the price per MWH for the next segment. Usually there are two other elements to the offer (startup cost and minimum power) Most generating incremental price curves are increasing price – ISO’s require this. There are some very strange curves for combined cycle units with dead bands etc. that the ISO continue to struggle with. The average price curve is usually what most people think they want. It is the cost at each level of operation divided by the MWH at each level. These curves can be declining. They should never be used for transactions in my opinion, but they are. Edward G. Cazalet, Ph.D. 101 First Street, Suite 552 Los Altos, CA 94022 650-949-5274 cell: 408-621-2772 [email protected] www.cazalet.com From: Toby Considine [mailto:[email protected]] On Behalf Of Toby Considine Sent: Monday, February 21, 2011 1:23 PM To: [email protected] Subject: FW: Normalizinh Price and Load Resources From: Toby Considine [mailto:[email protected]] Sent: Monday, February 21, 2011 2:54 PM To: [email protected] Subject: Normalizinh Price and Load Resources The [uncompleted draft] work in the CIM has some inconsistencies in how it signs up loads. During the initial resource definitions, I pared those extensively, removing, for example, nameplate data, control system information, and other facts beyond those necessary to make economic decisions. There were also inconsistencies between the definitions for Load and for Power resources. I summarize the CSD01 interfaces below (and in the attached documenta, for those who have plain-text mail… RegisteredGenerationType OfferLoadReductionType OfferPowerType ResourceLoad Generic (Registered Generator from CIM) (LoadBid in CIM) raiseRampRate dropRampRate raiseRampRate dropRampRate stagingRamp maximumOperatingPower minLoad maximumPower minimumLoad maximumResponse minimumOperatingPower minLoadReduction minimumPower minimumResponse dropRampRate pickupRate dropRampRate raiseRampRate recoveryRamp spinReserveRamp minLoadReductionInterval minimumResponseInterval minTimeBetLoadRed minimumTimeBetweenCalls shutdownCost startupCost invocationPrice LoadReductionPriceCurve offerSegment priceRamp minLoadReductionCost minimumResourceCost minimumResponseCost Some notes )and thanks to Bruce for his work highlighting these issues: 1) We have a very similar starting ramps[s], min response, max response, finishing ramp[s] 2) We have a response time. Ramps. The CIM takes a Ramp (begin value, end value) and has a directionality attribute. We take a ramp, assign directionality (ramp up, ramp down), and then the begin and end values. There are a couple ways we could do this, but these are essentially identical constructs. Integral response: Each ramp could perhaps have some sort to integrity flag, i.e., all or nothing. Sit or Stand, but requesting crouching is illegal. This is particularly useful for DR (Turn off Chiller or turn off Chiller and Lights) but could be useful for Power as well—particularly for renewables which may not have control. Price requirements. Some of the CIM objects had price curves. Some did not. The last megawatt may be more expensive to buy than the first. Alternately, now that I have already sent everyone home, it may not cost much more to turn off all the lights. Price curves look like ramps in structure. Not all markets accept curves. Today’s market rules award different prices than those offered. (Often it is sum up all offers until you get enough, then award all that clearing price). I think we need a price curve, which is only incompletely described. Constraints. I mentioned them earlier today. I think I see a new top-level EMIX object, EmixOffers, which consists of Terms, Constraints, and a Price Ramp. The price curve would also include the requirements such as invocationPrice and minimumResponsePrice. This would reduce the four above to Power and Load. Power Ramps UP during Start and Ramps Down afterwards. Load Ramps Down during Start, and Ramps Up afterwards. Discussion? tc “It is difficult to get a man to understand something, when his salary depends upon his not understanding it” -- Upton Sinclair. Toby Considine TC9, Inc OASIS Technical Advisory Board TC Chair: oBIX & WS-Calendar TC Editor: EMIX, EnergyInterop U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee Email: [email protected] Phone: (919)619-2104 http://www.tcnine.com/ blog: www.NewDaedalus.com