Load profiles - Pyosch/powertac-server GitHub Wiki

up
This page is an attempt to boil down a discussion on Nabble about consumption and production reporting.

##The Broker's prediction problem Brokers need to make predictions about energy production and consumption in order to evaluate their portfolios, and in order to drive trading decisions. The design of the simulation needs to make such information available to brokers in more or less the same form and granularity as what is available in the real world.

In most areas of the world, electricity demand exhibits daily, weekly, and seasonal demand variations, as well as variations due to local weather conditions. Brokers must deal with these sources of variability, and should be given enough data up front to bootstrap a prediction model to a reasonable level. This is important because the duration of the simulation is rather short, and research value will be limited if it takes the entire length of the game (or longer) to develop a usable model.

Here are some pieces of information that should be available in the real world and that have clear mappings to the simulation:

• Total aggregate (net) load for the market area over various periods in the past. If one aggregated a few years of such data, one could get something like a mean annual profile, broken down by timeslot. You could also get information on variability and trend. Such data would aggregate all types of customers, of course, and any energy production within the region would presumably not be visible, except that some load would be missing. Of course, any data that covers substantial periods of time will show long-term variation due to population changes, changes in industrial/commercial mix, and changes in technology (new traffic signals take considerably less power than the older ones, people are adopting CFL lighting very widely, etc.).

• Meter records are collected for individual customers, but historical meter records are probably not available outside the DU. Also, it's likely that such data in most cases would include only monthly meter readings.

• Once a customer is subscribed to a broker, the broker should get the full meter records for that customer during the term of the subscription.

##Bootstrap data When the game starts, brokers should be given access to aggregate data for the entire population, averaged over multiple years. For example, if we model a 12-month year, a 365x2x24 array could contain actual net consumption for the entire region for each timeslot over the previous two years. This is data the DU would normally have; it comes from the actual transport through the PCC, plus any local balancing provided by the DU. There's no need to do any statistics on this data; we should let the brokers do that. This sounds like a large array, but if we represent it as 8-byte doubles, this is just 140Kb, sent once at the beginning of the game. This is static data, so brokers could retrieve it from the web app when they log in with a simple http get. There is no need to handle it in the server at all.

Brokers will also need to learn how supply and demand correlate to weather conditions, and so the weather data that corresponds to the actual consumption data should also be provided, in the same way (static data).

##Customer population data Customers are modeled as either discrete large customers, or as "clustered" population models. Population models are characterized by size, consumption profile, and other attributes such as proportion with PV or wind generators, electric vehicles, or price-sensitive appliances. What data should a broker be able to discover about these populations without actually selling tariffs to them and observing their behaviors? Here are some possibilities (mostly from Carsten):

• statistical 24-hour load profile, or perhaps weekday/weekend load profiles, in the form of "boxplots" for each of 24 timeslots. A boxplot is at least the 25%, 50%, and 75% points on the observed distribution, along with (perhaps) mean and std. deviation.
• proportion of population with various "special capabilities" such as production capacity of various types, interruptible (shiftable) load capacity, or electric vehicles.
• Preference information could possibly be revealed. Do we want to do that? Is it reasonable?

###Generating customer data Our customer models may be more or less representative of real customer populations. If they were perfectly representative, we could bootstrap broker agents with real-world data. But making that assumption seems far too constraining (and perhaps misleading). If we assume customer model behavior is significantly variable, then one approach would be to run our suite of customer models independently over multiple simulated years (in order to collect seasonal variation) and collect the data summaries. This would, of course, also require that we run the physical environment model as well. If we assume that the customer and physical environment models can run faster than the simulation timeline, this "seeding" process for a model config could be finished in a few hours, and the resulting data would then be bundled with the model config.

###Questions:

• Is there any compelling reason to make this information available on demand, or just at the beginning of a simulation. A reason to make it available always is that brokers could then recover from a crash during a simulation.
• Is there any compelling reason why this information needs to be available in any form other than a bulk download, through an http get?
• What information is available about individual large customers, and when? Possibly very little unless a broker actually engages in negotiation. Perhaps a condition of making a counterproposal to a broker is that the customer reveal their capabilities and profile data, at least that portion that would apply to the proposed contract?

##Data from subscribed customers Brokers should get the same information the DU/Accounting service uses to bill/pay customers and compute balance. That's really just raw metering information, plus information on balancing actions taken.