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,
the clock ticks at the beginning of timeslot n.
customer and market activities happen for a while, probably much less than the interal between ticks.
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.
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.