Game Design

Broker

 * Responsible for building and operating a portfolio, and for balancing the supply and demand within that portfolio by trading in the Wholesale Market.

Distribution Utility and Accounting Service

 * The Distribution Utility (DU) models the regulated monopoly that owns and maintains the distribution infrastructure. In the context of Power TAC, it is a neutral third party, primarily responsible for balancing supply and demand in each timeslot. So if a Broker is unable to balance its portfolio, the DU does it. Because it controls the physical infrastructure, the DU is the party who is able to observe the actual energy use of the customers, and the actual power imports and exports through its coupling with the transmission infrastructure. Therefore, it also controls the accounting process by which customers and brokers are charged and paid.

Wholesale Market

 * Consists of a day-ahead market and a real-time market. There are a number of market models in use, from a simple Continuous Double Auction (CDA) or Periodic Double Auction (PDA) to the more complex FERC structure used in much of North America, in which bids consist of piecewise-linear supply and demand curves.


 * What period of time is covered by each?

Market Intelligence Service

 * Responsible for providing customer data to Brokers, and for running the tariff market by which Brokers build their portfolios of tariff customers.

Contract Customer

 * A relatively large (compared to an individual Tariff customer) customer who wishes to negotiate an individual contract with a Broker for electric power service. May be a net supplier or a net consumer. Examples include large commercial and industrial facilities, and government entities.

Tariff Customer

 * A small-scale customer, such as a household or small-to-medium business, may be net supplier or consumer. Most (or all) tariff customers are represented by population models in order to achieve reasonable scalability.

Bank

 * Keeps accounts on behalf of the Brokers, the DU, and probably the MIS.

Days and Dates
The game simulates interaction over several days spread across two years. The exact number of days simulated is deliberately undefined to discourage the use of end-game or known-horizon strategies. However, participants can expect that the game will simulate approximately 60 days. Each simulated day represents a specific calendar date. For example, assume that the game is initialized with a start date of Jun 1, 2011. Then the sequence of days progresses as: In other words, the date of the first simulation day is not known until the start of the game, but once that first date is known, the rest of the series can be computed deterministically. This is relevant because the underlying model in the game infrastructure attempts to simulate typical load and production levels for that date of a typical year and game partipants may want to use that knowledge in their strategies.
 * 1) Jun 1, 2011 (Simulation day 1)
 * 2) Jun 13, 2011 (Simulation day 2 = Calendar date of simulation day 1 + 12 calendar days)
 * 3) Jun 25, 2011 (Simulation day 3)
 * 4) Jul 07, 2011
 * 5) Jul 19, 2011
 * 6) ... and so on.

Execution and Contracting
The game timeline is partitioned by two sets of periods, Execution and Contracting. An Execution period represents 1 hour in simulated time and lasts 5 seconds in wall-clock time. Therefore, each simulated day is made up of 24 Execution periods. In parallel, we define a Contracting period as 6 hours in simulated time. Therefore, we have 4 Contracting periods per simulated day and, correspondingly, 6 Execution periods per Contracting period. Contracting periods start at 00:00, 06:00, 12:00 and 18:00 in the simulated day.

An Execution period defines the smallest timeslot for which prices can vary. During a given Execution period, the makeup of a Broker's portfolio of customers remains unchanged. In fact, the portfolio remains unchanged over the six Execution periods that correspond to a single Contracting period. In a given Contracting period, Brokers can submit tariffs to the Market Intelligence Service or cancel tariffs that they had previously submitted. During the last Execution period in a given Contracting period, the Market Intelligence Service computes a new allocation of Tariff Customers to Brokers based on the tariffs submitted by each Broker and the preferences of the Customers. Each Broker's share of the allocation is then communicated to that Broker by the game server before the start of the next Contracting and Execution periods. Note that Brokers can negotiate contracts with Contract Customers at any time.

Note: Given 5 seconds per Execution period and approximately 60 simulated days, the game can be expected to last approximately 2 hours in wall-clock time.

(JDcosta: Q: Is the Execution (shorter time interval) and the Contracting (relatively longer look-ahead time horizon) identifiable with the Real Time Dispatch (RTD) over 5-10 minute interval) and Real Time Commitment (RTC over a 1-3 hr ) in a Real Time (as well as a Day -Ahead scheduling optimized over hourly intervals over a 24 hr period ) Market operation of a market design referenced on (for example) page 1964 of the reading material assigned for today's meetup (Chow et al)? (except perhaps for convolution with a time contraction/dialation operator to adjust for the relative differences in the magnitudes of the time periods involved in the proposed Game Design and the Market Design presented in the paper) [http://class.ece.iastate.edu/ee458/Chow.pdf ]

(JEC) - moved this discussion to the talk page...

Server start
The server is started by the Web App (locally or remotely). It is provided with the identies of the participating brokers as part of its configuration.

Local startup is provided for research and debugging purposes, remote startup for multi-server competition situations.

Initialization

 * Start the Repast simulation
 * Set up Repast model instances

Broker login

 * Brokers first login to the Web App.
 * In case a competition is open for participants, the Web App returns the competition server's URL. The broker then connects to the competition server.
 * In case a competition is already running, the Web App either tells a broker to wait and check back at a later time, or the Web App sets up a new competition server. For research and debugging scenarios, brokers may be allowed to ask the Web App to create a competition based on certain parameters defined by the broker.
 * Once the broker has the server's URL, it logs into the simulation server.

Game start

 * Once all brokers defined as part of the server configuration are connected, the game starts.
 * Initial endowment is computed and communicated to all brokers.
 * If brokers start with non-empty endowment, then
 * There is a "warm-up" period to allow brokers to predict supply and demand, and secure necessary commitments in the wholesale market.

Execution
Primary activities during an execution timeslot include:
 * Price changes are communicated to Customers.
 * Customers retrieve Environment conditions.
 * Customers determine actual usage and production for the current timeslot.
 * Portfolio retrieves supply, demand, and balancing capacity data from Customers. The cost of using customer balancing capacity is determined by tariff terms.
 * Distribution Utility retrieves supply and demand from Broker Portfolios, Broker positions from Wholesale Market.
 * DU determines prices for external balancing capacity.
 * DU performs intra-Broker, inter-Broker, and external balancing. We assume this is done in a way that maximizes individual broker welfare; in other words, broker balancing capacity will be used as long as it's financially better for the broker than the cost of external balancing. Inter-broker balancing will initially be charged/credited at the price of external balancing capacity, until we allow brokers to make bilateral deals for mutual balancing. Note that the result of this step could change the prices for balancing capacity, so the two problems may have to be solved simultaneously.
 * DU clears the balancing market and runs resulting Bank transactions.
 * Portfolios compute actual charges and credits based on tariff terms and customer usage and production, run resulting Bank transactions.
 * Brokers may retrieve demand/supply forecasts for future timeslots from MIS.
 * Brokers adjust prices for customers with variable pricing. Updated prices may go into effect immediately, or be delayed, depending on tariff specification.