Brokers need demand/supply forecasts

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

Brokers need demand/supply forecasts

grampajohn
Administrator

In the original server, customer load was derived not from a set of models, but from a data store. Brokers were provided, at every timeslot, with updated predictions of load for the next n hours. Clearly this approach will not work in exactly the same way with the new server, but brokers need some sort of forecast on which to base their trading strategies.

So three approaches occur to me to provide forecasts in a model-based simulation:

  1. We run our customer models, using the default tariffs, for a period of time in a variety of weather conditions, and provide brokers with both the resulting net consumption data along with the correlated weather data. This would require brokers to build their own prediction models.
  2. We run our customer models, using the default tariffs, for a period of time having approximately the same weather as we will be using in the simulation. This would most likely require either a substantial startup period during which we run the models and collect the data, or somehow running the actual models twice during each timeslot, once for the current timeslot with current tariffs and weather, and once for a future timeslot with a weather forecast, and use the future-timeslot data as the forecast. This could require substantial computing horsepower beyond the needs of the server.
  3. We implement a prediction model of our own and broadcast the resulting predictions as forecasts.
We need to decide on an approach and get started on an implementation. This is an essential element of the simulation that is not yet started, and for which the approach used in the prototype server will not be adequate.

I am open to suggestions. Better yet would be a volunteer to own this issue.

John

Reply | Threaded
Open this post in threaded view
|

Re: Brokers need demand/supply forecasts

Prashant Reddy
I am interested in this issue and can own or co-own it.  I think 1, 2a and 3 are all reasonable options, but as you indicate, I don't think 2b (running the models twice per timeslot) is desirable.  It not only imposes a computational overhead on the server, but it also makes state management in the customer models more complicated.

Regarding 2a, even if we're using the same weather data as in the simulation, why does that have to require a substantial startup period?  Why couldn't we run the forecasting model beforehand; don't we have both the weather data and customer models beforehand?  (Since you're saying that 2a is based on default tariffs, I assume you're not implying that we would want to run the forecasting model with the exact set of brokers that will be participating in that simulation.)

Thanks,
Prashant  


On Thu, Feb 24, 2011 at 6:14 PM, grampajohn [via Power TAC Developers] <[hidden email]> wrote:

In the original server, customer load was derived not from a set of models, but from a data store. Brokers were provided, at every timeslot, with updated predictions of load for the next n hours. Clearly this approach will not work in exactly the same way with the new server, but brokers need some sort of forecast on which to base their trading strategies.

So three approaches occur to me to provide forecasts in a model-based simulation:

  1. We run our customer models, using the default tariffs, for a period of time in a variety of weather conditions, and provide brokers with both the resulting net consumption data along with the correlated weather data. This would require brokers to build their own prediction models.
  2. We run our customer models, using the default tariffs, for a period of time having approximately the same weather as we will be using in the simulation. This would most likely require either a substantial startup period during which we run the models and collect the data, or somehow running the actual models twice during each timeslot, once for the current timeslot with current tariffs and weather, and once for a future timeslot with a weather forecast, and use the future-timeslot data as the forecast. This could require substantial computing horsepower beyond the needs of the server.
  3. We implement a prediction model of our own and broadcast the resulting predictions as forecasts.
We need to decide on an approach and get started on an implementation. This is an essential element of the simulation that is not yet started, and for which the approach used in the prototype server will not be adequate.

I am open to suggestions. Better yet would be a volunteer to own this issue.

John


Reply | Threaded
Open this post in threaded view
|

Re: Brokers need demand/supply forecasts

grampajohn
Administrator
ppr wrote
I am interested in this issue and can own or co-own it.
Excellent!

ppr wrote
Regarding 2a, even if we're using the same weather data as in the simulation, why does that have to require a substantial startup period?  Why couldn't we run the forecasting model beforehand; don't we have both the weather data and customer models beforehand?  (Since you're saying that 2a is based on default tariffs, I assume you're not implying that we would want to run the forecasting model with the exact set of brokers that will be participating in that simulation.)
The idea is that the simulation provides a forecast, not the actual load that will be experienced. But it's still an open question in my mind whether this is a proper function of the simulation, or whether it should be the broker's responsibility to build and run its own forecasting model. If we want to do the latter, we will need to provide a minimally-competent model as part of a baseline agent, and we'll need to provide the necessary bootstrap data for such a model. One idea for such bootstrap data might be a set of daily profiles collected at different times of the year under different weather conditions (and weekdays/weekends), along with the corresponding weather data.

Another important question in this area is the extent to which profile data is available for individual customer models. Originally this was going to be an issue to be resolved in the Market Intelligence Service.

If you are willing to own this issue, then you are invited to make a proposal about how it should work. Of course anyone else is welcome to share ideas also. This is a critical game-design issue, in my opinion, because it strongly affects the needed capabilities of a competent broker agent.

Cheers -

John
Reply | Threaded
Open this post in threaded view
|

AW: Brokers need demand/supply forecasts

chris.flath

We should not forget our prior Nabble discussion on this issue:

http://power-tac-developers.975333.n3.nabble.com/Source-form-and-granularity-of-consumption-production-records-and-predictions-td2029952.html#a2060312

 

I think we had a fair amount of ideas already compiled and we will probably just have to make some calls on how to proceed.

 

Cheers,

Chris

Reply | Threaded
Open this post in threaded view
|

Re: AW: Brokers need demand/supply forecasts

grampajohn
Administrator
On 02/25/2011 03:52 PM, chris.flath [via Power TAC Developers] wrote:
> We should not forget our prior Nabble discussion on this issue:
>...

Thanks, Chris, I had forgotten about that. I raised the issue because
it's clearly a problem that needs to be solved before we can offer a
server to the pilot participants. Also, there's a wiki page on the old
domain-data wiki at
https://github.com/powertac/domain-data/wiki/Consumption-and-Production-records-and-predictions.
I could move that over to the server wiki, or just let Prashant borrow
from it to create a page reflecting our current thinking. I think
Prashant should decide, if he is indeed going to own this issue.

Cheers -

John