----- Original Message -----
From: Phil Davis [mailto:
pddcoo@gmail.com]
Sent: Wednesday, September 15, 2010 07:26 AM
To: Crimmins, Sean;
Toby.Considine@gmail.com <
Toby.Considine@gmail.com>; 'Edward G. Cazalet' <
ed@cazalet.com>;
emix@lists.oasis-open.org <
emix@lists.oasis-open.org>
Subject: RE: [emix] Ramp intervals
Would we be concerned in this group for transactions associated with
non-economic bids, i.e., emergency calls?
Phil
-----Original Message-----
From: Crimmins, Sean [mailto:
SCrimmins@caiso.com]
Sent: Wednesday, September 15, 2010 7:39 AM
To:
Toby.Considine@gmail.com; 'Edward G. Cazalet';
emix@lists.oasis-open.org
Subject: RE: [emix] Ramp intervals
The ramp rate curve is a characteristic of the unit that determines whether
it will be selected and what the five minute dispatches will look like once
the unit is online (e.g when ramping from 100 MW to 200 MW). It is not
strictly part of the three part bid which is purely economic; $/MW, Startup
cost and Minimum load cost. While the nominal ramp rate curve is determined
by physical unit characteristics it is possible to submit reduced ramp rate
curves that are lower than the units capablity to reduce wear and tear or
other "economic" reasons.
________________________________________
From: Toby Considine [
tobyconsidine@gmail.com] on behalf of Toby Considine
[
Toby.Considine@gmail.com]
Sent: Wednesday, September 15, 2010 2:25 AM
To: 'Edward G. Cazalet';
emix@lists.oasis-open.org
Subject: RE: [emix] Ramp intervals
So, if I understand this, ISO markets just set delta T small enough in the
ramp periods that they do not care.
The other proposal would be that in EMIX, we defined a generic enumeration
object which has two variations: Simple (a number) or ramp (begin rate, end
rate)
Another indication might be a "variance allowed", such that if your [ramp]
variation is greater than this, you must divide the intervals.
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:
Toby.Considine@gmail.com<mailto:
Toby.Considine@fac.unc.edu>
Phone: (919)619-2104
http://www.tcnine.com/
blog:
www.NewDaedalus.com
From: Edward G. Cazalet [mailto:
ed@cazalet.com]
Sent: Tuesday, September 14, 2010 6:01 PM
To:
Toby.Considine@gmail.com;
emix@lists.oasis-open.org
Subject: RE: [emix] Ramp intervals
I know there is another thread from this email related to DR "ramps", but
this note is focused on generation although much of it applies to DR and
loads as well.
I disagree that each EMIX product needs a ramp component. Some EMIX product
may have a ramp component.
A good example is bidding into ISO markets. The ISO accepts multi-part bids
from generators and dispatches them, Part of the bid is a ramp rate curve
vs. MW output (not a WS-calendar construct ). The output of the ISO process
is hourly and five minute schedules for the generator, without any explicit
WS-Calendar-like ramp. Yes the generator does not move instantly from the
level in one interval to the next in a step, but the balancing processes of
the ISO accommodate this.
Most forward wholesale contracts may be scheduled hourly. Ramping up and
down from levels in one hour to next often has an assumed ramp ( from 10
minutes before the hour to 10 minutes after the hour). As Phil has said, a
registration process can deal with any standard ramp assumptions. For
financial contracts the ramp can be ignored.
In automated markets it is easier to deal with schedules where the ramp is a
characterized by series of shorter interval schedules. It is also how we
meter delivery as energy over an interval. This provides standard products
and contracts in each interval. If every offer has a different ramp rate on
each end markets it is harder to get liquid markets.
Also, think of the complexity in adding up a large portfolio of schedules
each with a different embedded WS_Calendar ramp rate. The final schedule
with include all of the ramps, all with different durations and start times.
It is much easier to do what we do today which is a sequence of yearly,
monthly, daily, hourly, 5 min schedules each of which are simple block
schedules, transactions, or offers.
Edward G. Cazalet, Ph.D.
101 First Street, Suite 552
Los Altos, CA 94022
650-949-5274
cell: 408-621-2772
ed@cazalet.com<mailto:
ed@cazalet.com>
www.cazalet.com<
http://www.cazalet.com>
From: Toby Considine [mailto:
tobyconsidine@gmail.com] On Behalf Of Toby
Considine
Sent: Tuesday, September 14, 2010 12:20 PM
To:
emix@lists.oasis-open.org
Subject: [emix] Ramp intervals
Do we need a construction within EMIX for ramping intervals? I am tieing
this to such things as the 3-part generation bids Consider the case of a
long generation cycle followed by a discrete ramp cycle. The whole shape is
the electricity produced. Things don't just shut down, there is some
electricity that needs to go somewhere, and if it goes onto the grid, it
must be planned for and balanced.
The large rectangle on the left is the scheduled generation period. The it
may be scheduled for three hours, it may be scheduled for 1, it may be
scheduled for 16. The slopey bit on the right just comes along for the
ride.
[cid:
image001.png@01CB548D.BA8FA890]
The shape above is an ugly interval.We could solve it by making an infinite
number of intervals, or at least enough so that we can assume that each one
was flat. I think it would be an error to recreate intro calculus within
EMIX. [cid:
image002.png@01CB548D.BA8FA890]
WS-Calendar supports separating a scenario like that above, in which the
things are split into two linked intervals. It is easy to schedule the
interval on the left, to any length, It is the supply of a constant amount
of energy for a variable period of time, as per contract. The funny looking
shape on the right, comes along for the ride; buying the left is buying the
right. This occurs in many scnarios in homes / buildings / energy / . So in
Emix, we have a product, and then we have a ramp. The ramp is a predictable
varying, but constant duration (probably) delivery of product. There may be
ramp ups and ramp downs.
We need to include handling of ramped energy in each EMX product.
________________________________
"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:
Toby.Considine@gmail.com<mailto:
Toby.Considine@fac.unc.edu>
Phone: (919)619-2104
http://www.tcnine.com/
blog:
www.NewDaedalus.com<
http://www.NewDaedalus.com>
****************************************************************************
*****************
The foregoing electronic message, together with any attachments thereto, is
confidential and may be legally privileged against disclosure other than to
the intended recipient. It is intended solely for the addressee(s) and
access to the message by anyone else is unauthorized. If you are not the
intended recipient of this electronic message, you are hereby notified that
any dissemination, distribution, or any action taken or omitted to be taken
in reliance on it is strictly prohibited and may be unlawful. If you have
received this electronic message in error, please delete and immediately
notify the sender of this error.
****************************************************************************
*****************
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
________________________________________________________________________
This email has been scanned for SPAM content and Viruses by the MessageLabs
Email Security System.
________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php