Message-ID: <27824145.1075848307029.JavaMail.evans@thyme> Date: Wed, 29 Nov 2000 01:42:00 -0800 (PST) From: cgreer@tnpe.com To: isonp@ercot.com, piwg@ercot.com, operations@ercot.com, manuel-munoz@reliantenergy.com Subject: RE: Suggested Solution to the PUC's Concerns Regarding Local Cong estion Cc: kevin-gresham@reliantenergy.com, brenda_b_harris@reliantenergy.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bcc: kevin-gresham@reliantenergy.com, brenda_b_harris@reliantenergy.com X-From: "Greer, Clayton" X-To: isonp@ercot.com, piwg@ercot.com, operations@ercot.com, manuel-munoz@reliantenergy.com X-cc: kevin-gresham@reliantenergy.com, Brenda_B_Harris@reliantenergy.com X-bcc: X-Folder: \Doug_Gilbert_Smith_Nov2001\Notes Folders\All documents X-Origin: GILBERTSMITH-D X-FileName: dsmith.nsf If I am reading this correctly, it appears that rather than provide an adjustment for decremental units relieving local congestion, they will be required to either pay the market clearing price of energy for the zone or redispatch another unit in the same zone to counter act the decremental instruction. I believe we can support this change as long as few questions are properly handled: If there are multiple units that can clear the local congestion problem, who gets selected? (best shift factor, submitted dec bids, ERCOT flips a coin?) If a generator fails to follow this instruction will it properly show up as an uninstructed deviation, or will ERCOT follow performance to these direct instructions some other way? Can this similar methodology be used on the incremental side to curb abuse by those who manipulate their resource plans to create congestion they will be the only resource to correct? Have a great day! > ---------- > From: > manuel-munoz@reliantenergy.com[SMTP:manuel-munoz@reliantenergy.com] > Sent: Sunday, November 26, 2000 7:45 PM > To: isonp@ercot.com; piwg@ercot.com; operations@ercot.com > Cc: kevin-gresham@reliantenergy.com; Brenda_B_Harris@reliantenergy.com > Subject: Suggested Solution to the PUC's Concerns Regarding Local > Congestion > > <><>< stoft-intra-zonal.pdf>> > In a memo from Parvis Adib dated Oct. 31 (copy attached), the PUC > describes > a serious concern on the part of the Commission regarding market abuse > through relieving Local Congestion under the current Protocols. John Meyer > has asked me to draft a suggested solution to this concern. I am > recommending the following solution and believe it should be very easy to > implement. > > THE PROBLEM: Gaming whereby an entity deliberately and chronically places > itself in a situation to create local congestion in order to profit from > instructions to decrement its energy deliveries. > > The current language states that when a resource is instructed to > decrement its energy deliveries and a Market Solution does not exist the > resource's QSE will pay the minimum of the MCPE for that zone or 0. The > trouble with this approach is that if the MCPE is negative the QSE is > rewarded for having a resource causing local congestion. If the situation > persisted over time this could encourage inefficient generation to be > built > on the same area so that it can profit by having its output reduced or > even > turned off. > > Note that this would only happen in a situation where the local congestion > is located within a zone that is also susceptible to CSC congestion as > well > and the QSEs in such a zone are decremented most of the time which leads > to > high incidence of negative MCPE for the zone. This does not appear likely > but could occur if a zone is relatively small; i.e., dominated by QSEs > that > are few in number and that consistently overschedule across a CSC zone > with > the anticipation that they will always be instructed to decrement energy > in > real time. > > RECOMMENDED SOLUTION : > > Do not compensate or charge a resource that is instructed to decrement its > energy deliveries by ERCOT when a Market Solution does not exist in > relieving local congestion. However, the resource must obey the > instruction in order to maintain system reliability. > > Please give me your comments on this solution concept before Dec. 1. I > am > recommending that we add this as an item to vote on at the RUG meeting > scheduled for Dec. 6. I will also draft the recommended language changes > (very minor) to sections 6 and 7 and distribute it prior to the meeting. > > Manny > > > (See attached file: Adib103100) > > (See attached file: stoft-game.pdf) > > (See attached file: stoft-intra-zonal.pdf) > >