On Nov 16, 2007, at 1:09 PM, Daniel Gecer wrote:
I have problem solving an UOPF with a DC-network. I would like to
set up
an auction and use the smartmarket. When I do that it only works
from time
to time.
<snip>
What is it that I dont understand? Or is it just a
bug?
I'm not sure what is going on. If you send me the case file and two
script files that set up offers and options and call runmarket. Send
me one case that solves correctly with the low prices and another with
higher prices that does not solve, then I'll look into it. To be
honest, I have done very little testing of the smartmarket code with
the DC OPF, so there might very well be bugs.
<snip>
Can someone explain
to me how the calculation of nodal prices are made for DC aswell as
for AC
networks.
Yes, I know ... I really need to write a paper on this.
The nodal prices are determined from the shadow prices (lambdas) on
the power balance equations at each bus. At any given bus, lambda is
equal to the cost to the system of serving one more unit of load at
that location. When there are binding constraints and/or losses in the
system, the value of lambda may not be trivial to determine by
inspection. But it is calculated by the optimization routine used to
solve the problem. This all applies to AC and DC cases. It turns out
that for any generator that is partially dispatched, lambda is equal
to that generator's marginal cost at the dispatch point. But lambda
can be above the marginal cost if the generator is at an upper limit,
or below it's marginal cost if at a lower limit.
OK, now the tricky part ... the various auction types. Since lambda is
a measure of the value to the system of a unit of energy at that
location, we can use the ratios of lambdas as exchange rates between
locations. We can pick a reference node and compute exchange rates
with respect to that node and use those exchange rates to normalize
all bids & offers to a reference location. These normalized bids and
offers can be rank ordered by price, just like you would in a standard
2-sided auction. In a standard auction, there may be a gap between the
last accepted offer price and the last accepted bid price. Different
auctions use different conventions for setting a uniform clearing
price, since any price within that gap is acceptable to all parties.
It turns out that the lambda at the reference node will be equal to
the last accepted bid or offer price, depending which one is marginal.
But we can choose to always use last accepted offer, for example, if
we don't want bids to be able to set the price even when they are
marginal. So we can set the uniform price at the reference bus
anywhere within the bid/offer gap, then use the exchange rates to
convert this "uniform" price back to the location specific nodal prices.
So, for example, suppose you have a case where a bid is marginal and
all accepted offers are below the lambda's at their bus. If you are
using LAO, prices will be adjusted downward according to the
normalized bid/offer gap and the resulting price of (at least) one of
the generators will be equal to its offer.
Now, I should mention that I've never seen anyone else talk about LAO
vs. FRO vs. etc, etc. for markets solved by OPFs. Typically, they just
use the lambda's directly, which corresponds to what I call the 1st
price auction in MATPOWER.
Hopefully, that helps,
--
Ray Zimmerman
Senior Research Associate
428-B Phillips Hall, Cornell University, Ithaca, NY 14853
phone: (607) 255-9645
