Simulation timeline and market clearing

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Simulation timeline and market clearing

grampajohn
Administrator

Dear colleagues -

I am in the final stages of testing a new default broker, and I found myself confused about the relationship between "enabled timeslots," clock ticks that signal timeslot boundaries, and the sets of bids considered when clearing the wholesale market. I suspect the current implementation (including the grails version) is not quite correct.

Here's a brief overview of the current scheme:

  • In each timeslot, starting when the clock ticks, the server's internal processes go through three phases, as shown in Figure 8 of the current Power TAC specification. These phases are roughly customer activities (production, consumption, tariff evaluation), market activities (clearing and balancing), and accounting.
  • At the end of this activity, but presumably well before the next clock tick, the server sends out a TimeslotUpdate message, to inform brokers of the set of timeslots that will be traded in the next market clearing.
  • The server is then idle, essentially, until the next clock tick.

From the broker's standpoint,

  1. the clock ticks at the beginning of timeslot n.
  2. customer and market activities happen for a while, probably much less than the interal between ticks.
  3. a number of messages arrive - tariff transactions describe the customer activities, market transactions, market positions, cleared trades, and balancing transactions describe the market activities, and finally updated cash positions.
  4. A few additional messages complete the per-timeslot set: weather reports and forecasts, and a timeslot update.
Brokers can submit their messages at any time, including tariff offerings, price updates, bids and asks for the wholesale market, etc. The question is, how exactly do we interpret the relationship between enabled timeslots and the subsequent market clearing. Partly this is related to issue #383, and partly it's about the discrete-time nature of the simulation. During timeslot n, the market clears trades for power starting in timeslot n+1, but it does this near the beginning of timeslot n, not at the end. This means that for most of the interval during timeslot n, broker bids and asks for timeslot n+1 will arrive too late to be considered, and the boundary occurs some time before the TimeslotUpdate is sent out.

Perhaps the most awkward feature of this design is that no information about customer consumption/production during timeslot n can be used to inform bidding for timeslot n+1, because that information arrives after the market has already cleared for the last time for timeslot n+1.

This situation needs some careful thought. Perhaps it's OK the way it is, but I think it's going to be an ongoing source of confusion. Perhaps we should move the market clearing to the beginning of the timeslot, and treat it as the clearing that should have happened at the end of the previous timeslot, then send out the TimeslotUpdate message immediately after (or perhaps before) the market clears. I welcome your input on this.

John

Reply | Threaded
Open this post in threaded view
|

Re: Simulation timeline and market clearing

chris.flath
Hi John - I agree that the current scheme is somewhat puzzling.

I think the following ordering of actions (only looking at the relevant ones for this discussion) in any time slot n seems natural to the flow:

-----
1. Balancing actions n-1 take place
2. Bids / asks for n collected last time
3. Market clears for n the last time
4. consumption decisions in n occur
5. Balancing actions n take place
-----

A key aspect is definitely that you want to place bids for n after balancing occured in n-1.
Reply | Threaded
Open this post in threaded view
|

Re: Simulation timeline and market clearing

grampajohn
Administrator
In reply to this post by grampajohn
I have written up a proposal on addressing this problem in the server wiki. Please take a look and see if you agree.

Thanks -

John