Customer model capabilities implied by tariff options

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Customer model capabilities implied by tariff options

chris.flath
Hi together,

I spent the last days with a colleague from out economics group
brainstorming on how to generate simple and robust (i.e. predictable and not
exploitable) customer models to better understand the customer modeling
perspective / implications of the tariff object. We are still finalizing our
thoughts on a model that is parameterized around a given 24h load profile.
The load profile is split into fixed (non-shiftable / non-shedable),
semi-fixed (shiftable but not shedable) and variable (shiftable and
shedable) components. Shifting / Shedding causes (parmeterizable)
disutility. The customer can evaluate tariffs given the expected disutility
from cost and load modifications. Interestingly this modeling approach
naturally accommodates batteries, smart appliances and some types of
shedable load by means of the parameters as well as transformations of the
original load profile. We are not quite there yet but these talks have
advanced my understanding of what is required from a sensible customer
model.

Furthermore, we looked at the current list of tariff attributes and derived
the required customer model capabilities for both tariff choice as well as
consumption choice under a given tariff. Find the corresponding tables
attached and in the wiki under
https://github.com/powertac/domain-data/wiki/Tariff-representation. The
realization difficulty column is meant for discussion - my main focus was on
how exploitable the customer models could potentially be if we do not
address these points properly.

Cheers,

chris

customer model requirements.pptx (111K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Customer model capabilities implied by tariff options

grampajohn
Administrator
Very nice, Chris. Somehow there's a second, incomplete copy of the table
below the complete one.

This is a good summary of the intent and consequence of these features.
Of course, the most difficult feature, variable rates, is also probably
the most important. In our early discussions, we envisioned a
"reputation" service that customers would be "aware" of, that would
allow customer experiences with their brokers to be propagated to other
customers at some rate and level of penetration. There are websites in
Europe and the UK that could serve as models for this idea. Wolf should
have the URLs.

John


On 12/10/2010 07:06 AM, chris.flath [via Power TAC Developers] wrote:

> Hi together,
>
> I spent the last days with a colleague from out economics group
> brainstorming on how to generate simple and robust (i.e. predictable and
> not
> exploitable) customer models to better understand the customer modeling
> perspective / implications of the tariff object. We are still finalizing
> our
> thoughts on a model that is parameterized around a given 24h load profile.
> The load profile is split into fixed (non-shiftable / non-shedable),
> semi-fixed (shiftable but not shedable) and variable (shiftable and
> shedable) components. Shifting / Shedding causes (parmeterizable)
> disutility. The customer can evaluate tariffs given the expected disutility
> from cost and load modifications. Interestingly this modeling approach
> naturally accommodates batteries, smart appliances and some types of
> shedable load by means of the parameters as well as transformations of the
> original load profile. We are not quite there yet but these talks have
> advanced my understanding of what is required from a sensible customer
> model.
>
> Furthermore, we looked at the current list of tariff attributes and derived
> the required customer model capabilities for both tariff choice as well as
> consumption choice under a given tariff. Find the corresponding tables
> attached and in the wiki under
> https://github.com/powertac/domain-data/wiki/Tariff-representation. The
> realization difficulty column is meant for discussion - my main focus
> was on
> how exploitable the customer models could potentially be if we do not
> address these points properly.
>
> Cheers,
>
> chris
>
>
> *customer model requirements.pptx* (111K) Download Attachment
> </attachment/2063345/0/customer%20model%20requirements.pptx>
>
>
> ------------------------------------------------------------------------
> View message @
> http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2063345.html
> To start a new topic under Power TAC Developers, email
> [hidden email]
> To unsubscribe from Power TAC Developers, click here
> <
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: Customer model capabilities implied by tariff options

chris.flath

I just realized that there might be a very simple workaround to the variable rate issue I raised myself. In our MeRegio model region the variable tariff is legally spoken a tariff change and as such allows customers to always opt-out of a current contract upon a rate change. Hence, if for variable tariffs the early exit fee is 0, customers could just quit the contract if there was an excessive rate hike. Does that make sense?

 

Chris

 

Von: grampajohn [via Power TAC Developers] [mailto:[hidden email]]
Gesendet: Freitag, 10. Dezember 2010 20:39
An: Christoph Flath
Betreff: Re: Customer model capabilities implied by tariff options

 

Very nice, Chris. Somehow there's a second, incomplete copy of the table
below the complete one.

This is a good summary of the intent and consequence of these features.
Of course, the most difficult feature, variable rates, is also probably
the most important. In our early discussions, we envisioned a
"reputation" service that customers would be "aware" of, that would
allow customer experiences with their brokers to be propagated to other
customers at some rate and level of penetration. There are websites in
Europe and the UK that could serve as models for this idea. Wolf should
have the URLs.

John


On 12/10/2010 07:06 AM, chris.flath [via Power TAC Developers] wrote:


> Hi together,
>
> I spent the last days with a colleague from out economics group
> brainstorming on how to generate simple and robust (i.e. predictable and
> not
> exploitable) customer models to better understand the customer modeling
> perspective / implications of the tariff object. We are still finalizing
> our
> thoughts on a model that is parameterized around a given 24h load profile.
> The load profile is split into fixed (non-shiftable / non-shedable),
> semi-fixed (shiftable but not shedable) and variable (shiftable and
> shedable) components. Shifting / Shedding causes (parmeterizable)
> disutility. The customer can evaluate tariffs given the expected disutility
> from cost and load modifications. Interestingly this modeling approach
> naturally accommodates batteries, smart appliances and some types of
> shedable load by means of the parameters as well as transformations of the
> original load profile. We are not quite there yet but these talks have
> advanced my understanding of what is required from a sensible customer
> model.
>
> Furthermore, we looked at the current list of tariff attributes and derived
> the required customer model capabilities for both tariff choice as well as
> consumption choice under a given tariff. Find the corresponding tables
> attached and in the wiki under
> https://github.com/powertac/domain-data/wiki/Tariff-representation. The
> realization difficulty column is meant for discussion - my main focus
> was on
> how exploitable the customer models could potentially be if we do not
> address these points properly.
>
> Cheers,
>
> chris
>
>
> *customer model requirements.pptx* (111K) Download Attachment
> </attachment/2063345/0/customer%20model%20requirements.pptx>
>
>
> ------------------------------------------------------------------------
> View message @
>
http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2063345.html
> To start a new topic under Power TAC Developers, email
>
[hidden email]
> To unsubscribe from Power TAC Developers, click here
> <
lang=EN-US>>.
>




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: Customer model capabilities implied by tariff options

grampajohn
Administrator
On 12/12/2010 08:02 AM, chris.flath [via Power TAC Developers] wrote:
> I just realized that there might be a very simple workaround to the
> variable rate issue I raised myself. In our MeRegio model region the
> variable tariff is legally spoken a tariff change and as such allows
> customers to always opt-out of a current contract upon a rate change.
> Hence, if for variable tariffs the early exit fee is 0, customers could
> just quit the contract if there was an excessive rate hike. Does that
> make sense?

No, it does not make sense in the case of rates that are variable by the
hour. A customer can only evaluate the utility of such a tariff by
aggregating energy cost over some period of time. If all the customers
jumped ship instead of shifting their loads whenever there was an energy
price spike, then the whole purpose of the simulation is defeated, in my
opinion.

John

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: Customer model capabilities implied by tariff options

chris.flath
In reply to this post by grampajohn

The second table is not incomplete but a different table: the first one looks at requirements for tariff choice, the second looks at requirements for consumption choice requirements of the different tariff attributes. Looking at the two tables variable rates are both challenging from a tariff choice as well as from a consumption choice perspective. Hence I think we do have to reduce their complexity. IMHO I do not see hourly rate changes coming in the future, definitely not in Germany and therefore day-ahead 24hr prices seem like a good idea capturing both more increased demand control while at the same time retaining modeling parsimony.

 

Von: grampajohn [via Power TAC Developers] [mailto:[hidden email]]
Gesendet: Freitag, 10. Dezember 2010 20:39
An: Christoph Flath
Betreff: Re: Customer model capabilities implied by tariff options

 

Very nice, Chris. Somehow there's a second, incomplete copy of the table
below the complete one.

This is a good summary of the intent and consequence of these features.
Of course, the most difficult feature, variable rates, is also probably
the most important. In our early discussions, we envisioned a
"reputation" service that customers would be "aware" of, that would
allow customer experiences with their brokers to be propagated to other
customers at some rate and level of penetration. There are websites in
Europe and the UK that could serve as models for this idea. Wolf should
have the URLs.

John


On 12/10/2010 07:06 AM, chris.flath [via Power TAC Developers] wrote:


> Hi together,
>
> I spent the last days with a colleague from out economics group
> brainstorming on how to generate simple and robust (i.e. predictable and
> not
> exploitable) customer models to better understand the customer modeling
> perspective / implications of the tariff object. We are still finalizing
> our
> thoughts on a model that is parameterized around a given 24h load profile.
> The load profile is split into fixed (non-shiftable / non-shedable),
> semi-fixed (shiftable but not shedable) and variable (shiftable and
> shedable) components. Shifting / Shedding causes (parmeterizable)
> disutility. The customer can evaluate tariffs given the expected disutility
> from cost and load modifications. Interestingly this modeling approach
> naturally accommodates batteries, smart appliances and some types of
> shedable load by means of the parameters as well as transformations of the
> original load profile. We are not quite there yet but these talks have
> advanced my understanding of what is required from a sensible customer
> model.
>
> Furthermore, we looked at the current list of tariff attributes and derived
> the required customer model capabilities for both tariff choice as well as
> consumption choice under a given tariff. Find the corresponding tables
> attached and in the wiki under
> https://github.com/powertac/domain-data/wiki/Tariff-representation. The
> realization difficulty column is meant for discussion - my main focus
> was on
> how exploitable the customer models could potentially be if we do not
> address these points properly.
>
> Cheers,
>
> chris
>
>
> *customer model requirements.pptx* (111K) Download Attachment
> </attachment/2063345/0/customer%20model%20requirements.pptx>
>
>
> ------------------------------------------------------------------------
> View message @
> http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2063345.html
> To start a new topic under Power TAC Developers, email
> [hidden email]
> To unsubscribe from Power TAC Developers, click here
> <
>



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: Customer model capabilities implied by tariff options

grampajohn
Administrator
On 12/13/2010 02:17 AM, chris.flath [via Power TAC Developers] wrote:

> The second table is not incomplete but a different table: the first one
> looks at requirements for tariff choice, the second looks at
> requirements for consumption choice requirements of the different tariff
> attributes. Looking at the two tables variable rates are both
> challenging from a tariff choice as well as from a consumption choice
> perspective. Hence I think we do have to reduce their complexity. IMHO I
> do not see hourly rate changes coming in the future, definitely not in
> Germany and therefore day-ahead 24hr prices seem like a good idea
> capturing both more increased demand control while at the same time
> retaining modeling parsimony.

Chris and all -

Hourly rate changes are already here for large industrial users, at
least in North America. Of course, the largest ones do their own
purchasing in the wholesale market, but for many others, variable rates
have been around for a while.

We are not trying to model the world as it is, that would be pointless.
We are trying to model the world as it might be. One of the purposes of
our work is to provide a platform where the likely impact of variable
pricing and other policy options can be evaluated, free of economic and
political risk.

I think it would be reasonable to disallow notification intervals of
zero, but I think it's unreasonable to disallow intervals less than 24
hours, even for household users. Perhaps we could agree on a 2-hour
minimum, for the near term? In the longer term, I think it's important
to allow price changes without notification.

John


>
> *Von:* grampajohn [via Power TAC Developers] [mailto:[hidden email]
> </user/SendEmail.jtp?type=node&node=2077386&i=0>]
> *Gesendet:* Freitag, 10. Dezember 2010 20:39
> *An:* Christoph Flath
> *Betreff:* Re: Customer model capabilities implied by tariff options
>
> Very nice, Chris. Somehow there's a second, incomplete copy of the table
> below the complete one.
>
> This is a good summary of the intent and consequence of these features.
> Of course, the most difficult feature, variable rates, is also probably
> the most important. In our early discussions, we envisioned a
> "reputation" service that customers would be "aware" of, that would
> allow customer experiences with their brokers to be propagated to other
> customers at some rate and level of penetration. There are websites in
> Europe and the UK that could serve as models for this idea. Wolf should
> have the URLs.
>
> John
>
>
> On 12/10/2010 07:06 AM, chris.flath [via Power TAC Developers] wrote:
>
>
>  > Hi together,
>  >
>  > I spent the last days with a colleague from out economics group
>  > brainstorming on how to generate simple and robust (i.e. predictable and
>  > not
>  > exploitable) customer models to better understand the customer modeling
>  > perspective / implications of the tariff object. We are still finalizing
>  > our
>  > thoughts on a model that is parameterized around a given 24h load
> profile.
>  > The load profile is split into fixed (non-shiftable / non-shedable),
>  > semi-fixed (shiftable but not shedable) and variable (shiftable and
>  > shedable) components. Shifting / Shedding causes (parmeterizable)
>  > disutility. The customer can evaluate tariffs given the expected
> disutility
>  > from cost and load modifications. Interestingly this modeling approach
>  > naturally accommodates batteries, smart appliances and some types of
>  > shedable load by means of the parameters as well as transformations
> of the
>  > original load profile. We are not quite there yet but these talks have
>  > advanced my understanding of what is required from a sensible customer
>  > model.
>  >
>  > Furthermore, we looked at the current list of tariff attributes and
> derived
>  > the required customer model capabilities for both tariff choice as
> well as
>  > consumption choice under a given tariff. Find the corresponding tables
>  > attached and in the wiki under
>  > https://github.com/powertac/domain-data/wiki/Tariff-representation. The
>  > realization difficulty column is meant for discussion - my main focus
>  > was on
>  > how exploitable the customer models could potentially be if we do not
>  > address these points properly.
>  >
>  > Cheers,
>  >
>  > chris
>  >
>  >
>  > *customer model requirements.pptx* (111K) Download Attachment
>  > </attachment/2063345/0/customer%20model%20requirements.pptx>
>  >
>  >
>  > ------------------------------------------------------------------------
>  > View message @
>  >
> http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2063345.html
> <http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2063345.html?by-user=t&by-user=t>
>  > To start a new topic under Power TAC Developers, email
>  > [hidden email]
> </user/SendEmail.jtp?type=node&node=2065418&i=0&by-user=t>
>  > To unsubscribe from Power TAC Developers, click here
>  >
> < <
>
>  >
>
>
> ------------------------------------------------------------------------
>
> View message @
>
http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2065418.html
> <http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2065418.html?by-user=t>
> To start a new topic under Power TAC Developers, email [hidden email]
> </user/SendEmail.jtp?type=node&node=2077386&i=1>
> To unsubscribe from Power TAC Developers, click here
> <
>
>
>
>
> ------------------------------------------------------------------------
> View message @
>
http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2077386.html
> To start a new topic under Power TAC Developers, email
> [hidden email]
> To unsubscribe from Power TAC Developers, click here
> <
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: Customer model capabilities implied by tariff options

chris.flath

Dear all,
 
using the current list of tariff properties from the wiki as a base we tried to figure out possibilities on which attributes to realize with which “economic model / reasoning in behind”.
 
I will go through the list of tariff properties and provide examples how a customer would typically have to handle these. As before I will separate model requirements concerning a) tariff choice and b) consumption choice.
Note: These descriptions are on a high level – I will try to provide some more detailed ones soon. Moreover, they may have a certain bias towards households but most elements should be true for professional consumers / generators as well.
 
1. Tiered rates | should be included
-------------------------------------------------------------------------------
a) A customer model can easily use historic / expected load data and calculate the expected cost of a given tariff with tiered rate. Hence for tariff choice this is straight-forward to be implemented.
 
b) For consumption choice under such a tiered rate scheme we can imagine two aspects:
i)Demand reduction - if a consumer has a device which is not necessary to be run (e.g. electric heating, AC) he could be induced by the tiered rate to reduce the consumption of this device to remain below the threshold. Marginal utility from such devices will be decreasing in consumption and hence even simple customer model will be able to determine the optimal value beyond no more consumption takes place.
 
ii)Demand shifting to a different day to stay below threshold on both days - most shifting models currently focus on intra-day shifting only and – in case of Sebastian’s model for the Energy Policy paper - even suggest that there is little or no intraday shifting potential at least for household consumers. Consequently, at least end-consumer models, would probably ignore such tariff features (as they cannot really react to it).
-------------------------------------------------------------------------------
 
 
2. 24h-TOU | should be included
-------------------------------------------------------------------------------
a) A customer model can easily use historic / expected load data and calculate the expected cost of a given TOU tariff. Hence for tariff choice this is straight-forward to be implemented.
 
b) For consumption choice intraday TOU is easily modeled in a framework such as the one developed by Sebastian or Kishore and Snyder (
http://www.lehigh.edu/~lvs2/Papers/PID1051346.pdf).
-------------------------------------------------------------------------------
 
 
3. Weekend/weekday-TOU | status unclear
-------------------------------------------------------------------------------
As this is directly linked to the issue of simulation time / skipping days I excluded it from this list. As noted above it is difficult to find good consumer models which can evaluate shifting horizons greater than 24hrs - therefore may be only limited weekday-weekend interaction and in that case weekends could be treated as completely separate competitions. This topic requires a bigger picture game design discussion on whether and how we manage overall competition time.
-------------------------------------------------------------------------------
 
 
4. Two-part tariffs | should be included
-------------------------------------------------------------------------------
a) A customer model can easily include a daily fixed fee in the total cost of the contract. In effect, even a signup-fee can be interpreted as the “fixed part” in a two-part tariff.
 
b) no effect on consumption choices
-------------------------------------------------------------------------------
 
 
5. Sign-up fees | should be included
-------------------------------------------------------------------------------
a) A customer model can easily include the sign-up fee in the total cost of the contract. If there is automatic renewal without sign-up fee at the end of the contract period the customer model will find this contract more attractive than another contract with sign-up fee. This endogenously gives rise to lock-in effects.
 
b) no effect on consumption choices
-------------------------------------------------------------------------------
 
 
6. Early withdrawal fee | should be dropped
-------------------------------------------------------------------------------
Allowing (consumer initiated) early withdrawal from contracts creates a bookkeeping mess and requires all customer models to constantly evaluate offered contracts vs. its current contract - server load we can save. We suggest that customers stay in a contract until the end of its runtime and runtimes can be anywhere between 1 and X days. Most of the lock-in effects can be captured with the sign-up fee / automatic renewal combination described above.
-------------------------------------------------------------------------------
 
 
7. Dynamic contracts | should be included in limited scale
-------------------------------------------------------------------------------
Again to limit complexity with respect to both the AS and the customer models we would suggest to keep dynamic contracts simple. We propose a day-ahead price update communicated at day change with the publication of the new tariff list. Notice that we only hand out weather forecast once a day and hence the two intervals would nicely coincide.
 
Customers under such a dynamic contract are granted an exit option at the end of the day if a tariff changed during the day in order to prevent the brokers from milking them. Given the presence of a default contract offered by the default broker there is a baseline cost which a broker is unlikely to exceed in order not to lose customers to the default broker. When the rates are not adjusted customers are not allowed to exit. This is a simple but guided solution and avoids us to venture into reputation system territory in the first version which I would personally like to avoid.
 
Notice that using the different attributes skillfully we can even describe something like a remote shedding contract (albeit in a less typical form): The broker dynamically adjusts the tariff to a two-tiered tariff with the tier 2 rate very, very high – a customer model with enough sheddable consumption may still find this tariff attractive if it offers low cost in other time segments. At the same time the broker can still prevent too small consumers from choosing this tariff by imposing a relatively high fixed fee!
 
a) Since customers are offered an exit option upon rate change they can simply evaluate the next 24hrs of a dynamic contract. Conservative consumers will probably factor in any sign-up fees as an extra charge for this minimum contract duration forcing brokers to cut down on sign-up fees on dynamic contracts. Dynamic contracts are distinguished by a "isDynamic" variable.
 
b) A customer could just use an expected rate to formulate its consumption plan in a dynamic contract. This seems like a reasonable heuristic but we will have to closely check this to prevent loopholes.
-------------------------------------------------------------------------------

Summary of our tariff proposal:

·         Hourly consumption / generation prices as variable price components

·         2-tier pricing possible, specified via threshold level and extra consumption / generation prices

·         Daily fee (bonus) as fixed priced component

·         Sign-up fee (bonus) due on contract start

·         Boolean isVariable to indicate whether the broker can change tariff  terms

·         Tariff duration indicated by min / max interval, if a contract runs out and a customer does not choose a different tariff a contract is automatically renewed

·         Customers cannot prematurely quit contracts except if a tariff change occurred

Given such a specification we would feel confident to provide corresponding demo customer implementations which can interact with such tariff offerings in a meaningful manner for the first round of competition next summer. Lacking any further knowledge, at least these customer models would not be able to operate with more complex tariffs. But with insights from the first competition this is likely to change. Hence, overall we found this to be a fair “first shot”, which seems to be realizable in the next very few weeks (the game specification has to be out very soon and along with it a proof-of-concept realization) on the one hand but with still significant playground for brokers to explore the tariff space. We fear that a more complex scheme may just increase the risk that our first competition being mostly about finding loopholes within the customer models.

I remember Prashant was very much in favor of keeping the early exit fee. Since he was busy with exams I hope he can soon join our discussion so that we thinks about the recent ideas.

John, you wrote your email while I was typing mine – I tried to address your point by editing the dynamic tariff section, I hope this worked.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Customer model capabilities implied by tariff options

Prashant Reddy
Hi all,

Chris, thanks for this -- it's a nice way to structure the conversation. 

I mostly agree with the proposal, but I do disagree with a couple of points, and they all go hand in hand -

1) Unless it's imposed by regulation, treating a price change as an exit option from a contract is highly unlikely to happen in the US.  In my opinion.  price changes are far too frequent and the regulatory environment here too laissez-faire to impose such a mandate.

2a) Without that implicit exit option for variable prices, it is unreasonable to lock in customers into a contract for a fixed minimum period without an exit option.  Clearly that exit option should not be free and therefore the exit fee still makes sense, I think.

2b) Your proposal would imply that a fixed price tariff has no exit option for a customer -- again I think that's unreasonable.  They should be allowed to switch, at a cost, if a better tariff comes along.

3) I think 24 hours notice is too much time -- it really restricts a broker's ability to do "real-time balancing" through intra-day load-shifting and forces them to trade more heavily in the same day wholesale markets.  I do agree though that no notice is unreasonable as well.  I think the notice period should be at least 1 timeslot ahead, ideally 2-4 timeslots ahead.

The computational overhead of evaluating tariffs over all the customer models, potentially at every contracting period, is an engineering challenge that I don't think should affect the game design.  I actually don't think evaluating every tariff every period will be an issue, but if it does become an issue, we could consider running the customer models in a parallel server on a different machine or something like that?

Thanks,
Prashant



On Mon, Dec 13, 2010 at 11:42 AM, chris.flath [via Power TAC Developers] <[hidden email]> wrote:

Dear all,
 
using the current list of tariff properties from the wiki as a base we tried to figure out possibilities on which attributes to realize with which “economic model / reasoning in behind”.
 
I will go through the list of tariff properties and provide examples how a customer would typically have to handle these. As before I will separate model requirements concerning a) tariff choice and b) consumption choice.
Note: These descriptions are on a high level – I will try to provide some more detailed ones soon. Moreover, they may have a certain bias towards households but most elements should be true for professional consumers / generators as well.
 
1. Tiered rates | should be included
-------------------------------------------------------------------------------
a) A customer model can easily use historic / expected load data and calculate the expected cost of a given tariff with tiered rate. Hence for tariff choice this is straight-forward to be implemented.
 
b) For consumption choice under such a tiered rate scheme we can imagine two aspects:
i)Demand reduction - if a consumer has a device which is not necessary to be run (e.g. electric heating, AC) he could be induced by the tiered rate to reduce the consumption of this device to remain below the threshold. Marginal utility from such devices will be decreasing in consumption and hence even simple customer model will be able to determine the optimal value beyond no more consumption takes place.
 
ii)Demand shifting to a different day to stay below threshold on both days - most shifting models currently focus on intra-day shifting only and – in case of Sebastian’s model for the Energy Policy paper - even suggest that there is little or no intraday shifting potential at least for household consumers. Consequently, at least end-consumer models, would probably ignore such tariff features (as they cannot really react to it).
-------------------------------------------------------------------------------
 
 
2. 24h-TOU | should be included
-------------------------------------------------------------------------------
a) A customer model can easily use historic / expected load data and calculate the expected cost of a given TOU tariff. Hence for tariff choice this is straight-forward to be implemented.
 
b) For consumption choice intraday TOU is easily modeled in a framework such as the one developed by Sebastian or Kishore and Snyder (
http://www.lehigh.edu/~lvs2/Papers/PID1051346.pdf).
-------------------------------------------------------------------------------
 
 
3. Weekend/weekday-TOU | status unclear
-------------------------------------------------------------------------------
As this is directly linked to the issue of simulation time / skipping days I excluded it from this list. As noted above it is difficult to find good consumer models which can evaluate shifting horizons greater than 24hrs - therefore may be only limited weekday-weekend interaction and in that case weekends could be treated as completely separate competitions. This topic requires a bigger picture game design discussion on whether and how we manage overall competition time.
-------------------------------------------------------------------------------
 
 
4. Two-part tariffs | should be included
-------------------------------------------------------------------------------
a) A customer model can easily include a daily fixed fee in the total cost of the contract. In effect, even a signup-fee can be interpreted as the “fixed part” in a two-part tariff.
 
b) no effect on consumption choices
-------------------------------------------------------------------------------
 
 
5. Sign-up fees | should be included
-------------------------------------------------------------------------------
a) A customer model can easily include the sign-up fee in the total cost of the contract. If there is automatic renewal without sign-up fee at the end of the contract period the customer model will find this contract more attractive than another contract with sign-up fee. This endogenously gives rise to lock-in effects.
 
b) no effect on consumption choices
-------------------------------------------------------------------------------
 
 
6. Early withdrawal fee | should be dropped
-------------------------------------------------------------------------------
Allowing (consumer initiated) early withdrawal from contracts creates a bookkeeping mess and requires all customer models to constantly evaluate offered contracts vs. its current contract - server load we can save. We suggest that customers stay in a contract until the end of its runtime and runtimes can be anywhere between 1 and X days. Most of the lock-in effects can be captured with the sign-up fee / automatic renewal combination described above.
-------------------------------------------------------------------------------
 
 
7. Dynamic contracts | should be included in limited scale
-------------------------------------------------------------------------------
Again to limit complexity with respect to both the AS and the customer models we would suggest to keep dynamic contracts simple. We propose a day-ahead price update communicated at day change with the publication of the new tariff list. Notice that we only hand out weather forecast once a day and hence the two intervals would nicely coincide.
 
Customers under such a dynamic contract are granted an exit option at the end of the day if a tariff changed during the day in order to prevent the brokers from milking them. Given the presence of a default contract offered by the default broker there is a baseline cost which a broker is unlikely to exceed in order not to lose customers to the default broker. When the rates are not adjusted customers are not allowed to exit. This is a simple but guided solution and avoids us to venture into reputation system territory in the first version which I would personally like to avoid.
 
Notice that using the different attributes skillfully we can even describe something like a remote shedding contract (albeit in a less typical form): The broker dynamically adjusts the tariff to a two-tiered tariff with the tier 2 rate very, very high – a customer model with enough sheddable consumption may still find this tariff attractive if it offers low cost in other time segments. At the same time the broker can still prevent too small consumers from choosing this tariff by imposing a relatively high fixed fee!
 
a) Since customers are offered an exit option upon rate change they can simply evaluate the next 24hrs of a dynamic contract. Conservative consumers will probably factor in any sign-up fees as an extra charge for this minimum contract duration forcing brokers to cut down on sign-up fees on dynamic contracts. Dynamic contracts are distinguished by a "isDynamic" variable.
 
b) A customer could just use an expected rate to formulate its consumption plan in a dynamic contract. This seems like a reasonable heuristic but we will have to closely check this to prevent loopholes.
-------------------------------------------------------------------------------

Summary of our tariff proposal:

·         Hourly consumption / generation prices as variable price components

·         2-tier pricing possible, specified via threshold level and extra consumption / generation prices

·         Daily fee (bonus) as fixed priced component

·         Sign-up fee (bonus) due on contract start

·         Boolean isVariable to indicate whether the broker can change tariff  terms

·         Tariff duration indicated by min / max interval, if a contract runs out and a customer does not choose a different tariff a contract is automatically renewed

·         Customers cannot prematurely quit contracts except if a tariff change occurred

Given such a specification we would feel confident to provide corresponding demo customer implementations which can interact with such tariff offerings in a meaningful manner for the first round of competition next summer. Lacking any further knowledge, at least these customer models would not be able to operate with more complex tariffs. But with insights from the first competition this is likely to change. Hence, overall we found this to be a fair “first shot”, which seems to be realizable in the next very few weeks (the game specification has to be out very soon and along with it a proof-of-concept realization) on the one hand but with still significant playground for brokers to explore the tariff space. We fear that a more complex scheme may just increase the risk that our first competition being mostly about finding loopholes within the customer models.

I remember Prashant was very much in favor of keeping the early exit fee. Since he was busy with exams I hope he can soon join our discussion so that we thinks about the recent ideas.

John, you wrote your email while I was typing mine – I tried to address your point by editing the dynamic tariff section, I hope this worked.




View message @ http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2079713.html

To start a new topic under Power TAC Developers, email [hidden email]
To unsubscribe from Power TAC Developers, click here.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Customer model capabilities implied by tariff options

Carsten Block
Administrator
Hi everybody,

back in office today after five days sick in bed.  Without directly adding to this discussion: What I particularly like about Chris approach is his "reverse style thinking", i.e. the reasoning what type of economic decision making a particular tariff feature requires on the customer model side. Given the remaining time until the release of the game specification, I suggest that - whatever set of tariff attributes we will finally agree upon - for each of the attributes we should have such a "sample realization plan" for corresponding customer models (i.e. those who react to that tariff feature) available too. That would make me feel much more comfortable about the subsequent realization timeline where both, tariff model and customer model(s), have to be realized.

Cheers,
Carsten 



Am 13.12.2010 um 18:23 schrieb ppr [via Power TAC Developers]:

Hi all,

Chris, thanks for this -- it's a nice way to structure the conversation. 

I mostly agree with the proposal, but I do disagree with a couple of points, and they all go hand in hand -

1) Unless it's imposed by regulation, treating a price change as an exit option from a contract is highly unlikely to happen in the US.  In my opinion.  price changes are far too frequent and the regulatory environment here too laissez-faire to impose such a mandate.

2a) Without that implicit exit option for variable prices, it is unreasonable to lock in customers into a contract for a fixed minimum period without an exit option.  Clearly that exit option should not be free and therefore the exit fee still makes sense, I think.

2b) Your proposal would imply that a fixed price tariff has no exit option for a customer -- again I think that's unreasonable.  They should be allowed to switch, at a cost, if a better tariff comes along.

3) I think 24 hours notice is too much time -- it really restricts a broker's ability to do "real-time balancing" through intra-day load-shifting and forces them to trade more heavily in the same day wholesale markets.  I do agree though that no notice is unreasonable as well.  I think the notice period should be at least 1 timeslot ahead, ideally 2-4 timeslots ahead.

The computational overhead of evaluating tariffs over all the customer models, potentially at every contracting period, is an engineering challenge that I don't think should affect the game design.  I actually don't think evaluating every tariff every period will be an issue, but if it does become an issue, we could consider running the customer models in a parallel server on a different machine or something like that?

Thanks,
Prashant



On Mon, Dec 13, 2010 at 11:42 AM, chris.flath [via Power TAC Developers] <<a href="x-msg://4/user/SendEmail.jtp?type=node&amp;node=2079980&amp;i=0" target="_top" rel="nofollow">[hidden email]> wrote:

Dear all,
 
using the current list of tariff properties from the wiki as a base we tried to figure out possibilities on which attributes to realize with which “economic model / reasoning in behind”.
 
I will go through the list of tariff properties and provide examples how a customer would typically have to handle these. As before I will separate model requirements concerning a) tariff choice and b) consumption choice.
Note: These descriptions are on a high level – I will try to provide some more detailed ones soon. Moreover, they may have a certain bias towards households but most elements should be true for professional consumers / generators as well.
 
1. Tiered rates | should be included
-------------------------------------------------------------------------------
a) A customer model can easily use historic / expected load data and calculate the expected cost of a given tariff with tiered rate. Hence for tariff choice this is straight-forward to be implemented.
 
b) For consumption choice under such a tiered rate scheme we can imagine two aspects:
i)Demand reduction - if a consumer has a device which is not necessary to be run (e.g. electric heating, AC) he could be induced by the tiered rate to reduce the consumption of this device to remain below the threshold. Marginal utility from such devices will be decreasing in consumption and hence even simple customer model will be able to determine the optimal value beyond no more consumption takes place.
 
ii)Demand shifting to a different day to stay below threshold on both days - most shifting models currently focus on intra-day shifting only and – in case of Sebastian’s model for the Energy Policy paper - even suggest that there is little or no intraday shifting potential at least for household consumers. Consequently, at least end-consumer models, would probably ignore such tariff features (as they cannot really react to it).
-------------------------------------------------------------------------------
 
 
2. 24h-TOU | should be included
-------------------------------------------------------------------------------
a) A customer model can easily use historic / expected load data and calculate the expected cost of a given TOU tariff. Hence for tariff choice this is straight-forward to be implemented.
 
b) For consumption choice intraday TOU is easily modeled in a framework such as the one developed by Sebastian or Kishore and Snyder (
http://www.lehigh.edu/~lvs2/Papers/PID1051346.pdf).
-------------------------------------------------------------------------------
 
 
3. Weekend/weekday-TOU | status unclear
-------------------------------------------------------------------------------
As this is directly linked to the issue of simulation time / skipping days I excluded it from this list. As noted above it is difficult to find good consumer models which can evaluate shifting horizons greater than 24hrs - therefore may be only limited weekday-weekend interaction and in that case weekends could be treated as completely separate competitions. This topic requires a bigger picture game design discussion on whether and how we manage overall competition time.
-------------------------------------------------------------------------------
 
 
4. Two-part tariffs | should be included
-------------------------------------------------------------------------------
a) A customer model can easily include a daily fixed fee in the total cost of the contract. In effect, even a signup-fee can be interpreted as the “fixed part” in a two-part tariff.
 
b) no effect on consumption choices
-------------------------------------------------------------------------------
 
 
5. Sign-up fees | should be included
-------------------------------------------------------------------------------
a) A customer model can easily include the sign-up fee in the total cost of the contract. If there is automatic renewal without sign-up fee at the end of the contract period the customer model will find this contract more attractive than another contract with sign-up fee. This endogenously gives rise to lock-in effects.
 
b) no effect on consumption choices
-------------------------------------------------------------------------------
 
 
6. Early withdrawal fee | should be dropped
-------------------------------------------------------------------------------
Allowing (consumer initiated) early withdrawal from contracts creates a bookkeeping mess and requires all customer models to constantly evaluate offered contracts vs. its current contract - server load we can save. We suggest that customers stay in a contract until the end of its runtime and runtimes can be anywhere between 1 and X days. Most of the lock-in effects can be captured with the sign-up fee / automatic renewal combination described above.
-------------------------------------------------------------------------------
 
 
7. Dynamic contracts | should be included in limited scale
-------------------------------------------------------------------------------
Again to limit complexity with respect to both the AS and the customer models we would suggest to keep dynamic contracts simple. We propose a day-ahead price update communicated at day change with the publication of the new tariff list. Notice that we only hand out weather forecast once a day and hence the two intervals would nicely coincide.
 
Customers under such a dynamic contract are granted an exit option at the end of the day if a tariff changed during the day in order to prevent the brokers from milking them. Given the presence of a default contract offered by the default broker there is a baseline cost which a broker is unlikely to exceed in order not to lose customers to the default broker. When the rates are not adjusted customers are not allowed to exit. This is a simple but guided solution and avoids us to venture into reputation system territory in the first version which I would personally like to avoid.
 
Notice that using the different attributes skillfully we can even describe something like a remote shedding contract (albeit in a less typical form): The broker dynamically adjusts the tariff to a two-tiered tariff with the tier 2 rate very, very high – a customer model with enough sheddable consumption may still find this tariff attractive if it offers low cost in other time segments. At the same time the broker can still prevent too small consumers from choosing this tariff by imposing a relatively high fixed fee!
 
a) Since customers are offered an exit option upon rate change they can simply evaluate the next 24hrs of a dynamic contract. Conservative consumers will probably factor in any sign-up fees as an extra charge for this minimum contract duration forcing brokers to cut down on sign-up fees on dynamic contracts. Dynamic contracts are distinguished by a "isDynamic" variable.
 
b) A customer could just use an expected rate to formulate its consumption plan in a dynamic contract. This seems like a reasonable heuristic but we will have to closely check this to prevent loopholes.
-------------------------------------------------------------------------------

Summary of our tariff proposal:

·         Hourly consumption / generation prices as variable price components

·         2-tier pricing possible, specified via threshold level and extra consumption / generation prices

·         Daily fee (bonus) as fixed priced component

·         Sign-up fee (bonus) due on contract start

·         Boolean isVariable to indicate whether the broker can change tariff  terms

·         Tariff duration indicated by min / max interval, if a contract runs out and a customer does not choose a different tariff a contract is automatically renewed

·         Customers cannot prematurely quit contracts except if a tariff change occurred

Given such a specification we would feel confident to provide corresponding demo customer implementations which can interact with such tariff offerings in a meaningful manner for the first round of competition next summer. Lacking any further knowledge, at least these customer models would not be able to operate with more complex tariffs. But with insights from the first competition this is likely to change. Hence, overall we found this to be a fair “first shot”, which seems to be realizable in the next very few weeks (the game specification has to be out very soon and along with it a proof-of-concept realization) on the one hand but with still significant playground for brokers to explore the tariff space. We fear that a more complex scheme may just increase the risk that our first competition being mostly about finding loopholes within the customer models.

I remember Prashant was very much in favor of keeping the early exit fee. Since he was busy with exams I hope he can soon join our discussion so that we thinks about the recent ideas.

John, you wrote your email while I was typing mine – I tried to address your point by editing the dynamic tariff section, I hope this worked.




View message @ http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2079713.html

To start a new topic under Power TAC Developers, email <a href="x-msg://4/user/SendEmail.jtp?type=node&amp;node=2079980&amp;i=1" target="_top" rel="nofollow">[hidden email]
To unsubscribe from Power TAC Developers, click here.




View message @ http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2079980.html
To start a new topic under Power TAC Developers, email [hidden email]
To unsubscribe from Power TAC Developers, click here.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: Customer model capabilities implied by tariff options

grampajohn
Administrator
In reply to this post by chris.flath
Chris and all -

Thanks for the nice summary. It's important to keep in mind the
complexity engendered by our design decisions, and it's also important
to simplify our model when we can find simplifications that preserve
research value and keep the scenario interesting and challenging for
participants.

I agree with much, but not quite all of your proposals. I also agree
with Carsten that it makes sense to implement in stages. My concern is
with the stage that is ready to run in July.

My thoughts:

1. Cross-day demand shifting CAN happen, but probably not to a great
extent. For example, people often have considerable flexibility when
deciding when to do laundry. Also, I can easily imaging that people
would adjust temperature settings on air conditioning or heating systems
based on price. I would, and I know my children and their families
would. This is not just shifting, it's shedding. There are some
households, and many businesses, who have multiple energy sources for
heating (and perhaps other purposes), and will decide which to use based
on price. Many large buildings and campus facilities have central
heating systems that can use different inputs, and only need to use all
of them during extreme weather. In my case, I have an electric heat
pump, a gas-fired furnace, and a wood-burning stove. Somebody has to be
in the house to use the stove (it's running right now - the outdoor temp
has come up to -19C from about -25 earlier this morning), but if I had
variable pricing, I would use the gas furnace if gas was cheaper than
electricity. With my current flat rate for interruptible power, it
hardly ever is.

2. I think an important research and public policy issue is the extent
to which customers can be "locked in" to a contract for a period of
time. Early-exit fees are a way for brokers to hedge their risks and
therefore offer lower prices. It's an important feature of real-world
tariff contracts, and we need to be able to simulate it. Certainly we
could use (configurable) market rules to limit the constraints placed on
customers, but eliminating early-exit fees will make the competition
less interesting and less valuable by a significant margin, in my opinion.

3. As with exit fees, dynamic-pricing contracts, with relatively short
notification horizons, are an important risk-management strategy for
brokers, and therefore offer the potential for significantly lower
(average) prices for customers. Dropping this feature would also
significantly affect the research value of Power TAC. For this reason, I
am not in favor of allowing customers to opt out just because they
agreed to variable pricing and then prices vary. Such a provision would
destroy the risk-reduction value of dynamic pricing from the broker's
standpoint, and therefore would pretty much eliminate the price
advantage from the customer's standpoint.

4. Dynamic-pricing tariffs can include minimum and maximum rates, and
expected average rates. As long as we have a working reputation
mechanism, brokers will know that they cannot get away with "milking"
their variable-price customers. In fact, as a broker designer, I would
want to entice as many customers as possible to accept - and stay with -
variable-pricing plans, because they should make my ability to manage my
loads and financial risk much more robust.

As I said, your proposal could be an acceptable stage on the way to full
implementation, but it should be implemented as a subset of the full
tariff representation, not a substitute. It's not clear whether you are
proposing a completely different structure from the one given at
https://github.com/powertac/domain-data/wiki/Tariff-representation or not.

Cheers -

John


On 12/13/2010 10:42 AM, chris.flath [via Power TAC Developers] wrote:

> Dear all,
>
> using the current list of tariff properties from the wiki as a base we
> tried to figure out possibilities on which attributes to realize with
> which “economic model / reasoning in behind”.
>
> I will go through the list of tariff properties and provide examples how
> a customer would typically have to handle these. As before I will
> separate model requirements concerning a) *tariff choice* and b)
> *consumption choice*.
> Note: These descriptions are on a high level – I will try to provide
> some more detailed ones soon. Moreover, they may have a certain bias
> towards households but most elements should be true for professional
> consumers / generators as well.
>
> *1. Tiered rates | should be included
> *-------------------------------------------------------------------------------
> a) A customer model can easily use historic / expected load data and
> calculate the expected cost of a given tariff with tiered rate. Hence
> for tariff choice this is straight-forward to be implemented.
>
> b) For consumption choice under such a tiered rate scheme we can imagine
> two aspects:
> i)Demand reduction - if a consumer has a device which is not necessary
> to be run (e.g. electric heating, AC) he could be induced by the tiered
> rate to reduce the consumption of this device to remain below the
> threshold. Marginal utility from such devices will be decreasing in
> consumption and hence even simple customer model will be able to
> determine the optimal value beyond no more consumption takes place.
>
> ii)Demand shifting to a different day to stay below threshold on both
> days - most shifting models currently focus on intra-day shifting only
> and – in case of Sebastian’s model for the Energy Policy paper - even
> suggest that there is little or no intraday shifting potential at least
> for household consumers. Consequently, at least end-consumer models,
> would probably ignore such tariff features (as they cannot really react
> to it).
> -------------------------------------------------------------------------------
>
>
> *2. 24h-TOU | should be included
> *-------------------------------------------------------------------------------
> a) A customer model can easily use historic / expected load data and
> calculate the expected cost of a given TOU tariff. Hence for tariff
> choice this is straight-forward to be implemented.
>
> b) For consumption choice intraday TOU is easily modeled in a framework
> such as the one developed by Sebastian or Kishore and Snyder
> (http://www.lehigh.edu/~lvs2/Papers/PID1051346.pdf).
> -------------------------------------------------------------------------------
>
>
> *3. Weekend/weekday-TOU | status unclear
> *-------------------------------------------------------------------------------
> As this is directly linked to the issue of simulation time / skipping
> days I excluded it from this list. As noted above it is difficult to
> find good consumer models which can evaluate shifting horizons greater
> than 24hrs - therefore may be only limited weekday-weekend interaction
> and in that case weekends could be treated as completely separate
> competitions. This topic requires a bigger picture game design
> discussion on whether and how we manage overall competition time.
> -------------------------------------------------------------------------------
>
>
> *4. Two-part tariffs | should be included
> *-------------------------------------------------------------------------------
> a) A customer model can easily include a daily fixed fee in the total
> cost of the contract. In effect, even a signup-fee can be interpreted as
> the “fixed part” in a two-part tariff.
>
> b) no effect on consumption choices
> -------------------------------------------------------------------------------
>
>
> *5. Sign-up fees | should be included
> *-------------------------------------------------------------------------------
> a) A customer model can easily include the sign-up fee in the total cost
> of the contract. If there is automatic renewal without sign-up fee at
> the end of the contract period the customer model will find this
> contract more attractive than another contract with sign-up fee. This
> endogenously gives rise to lock-in effects.
>
> b) no effect on consumption choices
> -------------------------------------------------------------------------------
>
>
> *6. Early withdrawal fee | should be dropped
> *-------------------------------------------------------------------------------
> Allowing (consumer initiated) early withdrawal from contracts creates a
> bookkeeping mess and requires all customer models to constantly evaluate
> offered contracts vs. its current contract - server load we can save. We
> suggest that customers stay in a contract until the end of its runtime
> and runtimes can be anywhere between 1 and X days. Most of the lock-in
> effects can be captured with the sign-up fee / automatic renewal
> combination described above.
> -------------------------------------------------------------------------------
>
>
> *7. Dynamic contracts | should be included in limited scale
> *-------------------------------------------------------------------------------
> Again to limit complexity with respect to both the AS and the customer
> models we would suggest to keep dynamic contracts simple. We propose a
> day-ahead price update communicated at day change with the publication
> of the new tariff list. Notice that we only hand out weather forecast
> once a day and hence the two intervals would nicely coincide.
>
> Customers under such a dynamic contract are granted an exit option at
> the end of the day if a tariff changed during the day in order to
> prevent the brokers from milking them. Given the presence of a default
> contract offered by the default broker there is a baseline cost which a
> broker is unlikely to exceed in order not to lose customers to the
> default broker. When the rates are not adjusted customers are not
> allowed to exit. This is a simple but guided solution and avoids us to
> venture into reputation system territory in the first version which I
> would personally like to avoid.
>
> Notice that using the different attributes skillfully we can even
> describe something like a remote shedding contract (albeit in a less
> typical form): The broker dynamically adjusts the tariff to a two-tiered
> tariff with the tier 2 rate very, very high – a customer model with
> enough sheddable consumption may still find this tariff attractive if it
> offers low cost in other time segments. At the same time the broker can
> still prevent too small consumers from choosing this tariff by imposing
> a relatively high fixed fee!
>
> a) Since customers are offered an exit option upon rate change they can
> simply evaluate the next 24hrs of a dynamic contract. Conservative
> consumers will probably factor in any sign-up fees as an extra charge
> for this minimum contract duration forcing brokers to cut down on
> sign-up fees on dynamic contracts. Dynamic contracts are distinguished
> by a "isDynamic" variable.
>
> b) A customer could just use an expected rate to formulate its
> consumption plan in a dynamic contract. This seems like a reasonable
> heuristic but we will have to closely check this to prevent loopholes.
> -------------------------------------------------------------------------------
>
> Summary of our tariff proposal:
>
> · Hourly consumption / generation prices as variable price components
>
> · 2-tier pricing possible, specified via threshold level and extra
> consumption / generation prices
>
> · Daily fee (bonus) as fixed priced component
>
> · Sign-up fee (bonus) due on contract start
>
> · Boolean isVariable to indicate whether the broker can change tariff terms
>
> · Tariff duration indicated by min / max interval, if a contract runs
> out and a customer does not choose a different tariff a contract is
> automatically renewed
>
> · Customers cannot prematurely quit contracts except if a tariff change
> occurred
>
> Given such a specification we would feel confident to provide
> corresponding demo customer implementations which can interact with such
> tariff offerings in a meaningful manner for the first round of
> competition next summer. Lacking any further knowledge, at least these
> customer models would not be able to operate with more complex tariffs.
> But with insights from the first competition this is likely to change.
> Hence, overall we found this to be a fair “first shot”, which seems to
> be realizable in the next very few weeks (the game specification has to
> be out very soon and along with it a proof-of-concept realization) on
> the one hand but with still significant playground for brokers to
> explore the tariff space. We fear that a more complex scheme may just
> increase the risk that our first competition being mostly about finding
> loopholes within the customer models.
>
> I remember Prashant was very much in favor of keeping the early exit
> fee. Since he was busy with exams I hope he can soon join our discussion
> so that we thinks about the recent ideas.
>
> John, you wrote your email while I was typing mine – I tried to address
> your point by editing the dynamic tariff section, I hope this worked.
>
>
>
> ------------------------------------------------------------------------
> View message @
> http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2079713.html
> To start a new topic under Power TAC Developers, email
> [hidden email]
> To unsubscribe from Power TAC Developers, click here
> <
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Customer model capabilities implied by tariff options

Wolf
Administrator
In reply to this post by Prashant Reddy

Hello all,

 

Thanks Chris for your work on this, and, as Prashant, I almost agree with your proposal, but I have the same issues as he has with your approach. I strongly believe that we have to go in that way to make it more realistic and reasonable.  It’s definitely unreasonable that customer’s leaving because of a price change.

 

Thanks,

 

Wolf

 

From: ppr [via Power TAC Developers] [mailto:[hidden email]]
Sent: Monday, December 13, 2010 06:24 PM
To: Wolf Ketter
Subject: Re: Customer model capabilities implied by tariff options

 

Hi all,

Chris, thanks for this -- it's a nice way to structure the conversation. 

I mostly agree with the proposal, but I do disagree with a couple of points, and they all go hand in hand -

1) Unless it's imposed by regulation, treating a price change as an exit option from a contract is highly unlikely to happen in the US.  In my opinion.  price changes are far too frequent and the regulatory environment here too laissez-faire to impose such a mandate.

2a) Without that implicit exit option for variable prices, it is unreasonable to lock in customers into a contract for a fixed minimum period without an exit option.  Clearly that exit option should not be free and therefore the exit fee still makes sense, I think.

2b) Your proposal would imply that a fixed price tariff has no exit option for a customer -- again I think that's unreasonable.  They should be allowed to switch, at a cost, if a better tariff comes along.

3) I think 24 hours notice is too much time -- it really restricts a broker's ability to do "real-time balancing" through intra-day load-shifting and forces them to trade more heavily in the same day wholesale markets.  I do agree though that no notice is unreasonable as well.  I think the notice period should be at least 1 timeslot ahead, ideally 2-4 timeslots ahead.

The computational overhead of evaluating tariffs over all the customer models, potentially at every contracting period, is an engineering challenge that I don't think should affect the game design.  I actually don't think evaluating every tariff every period will be an issue, but if it does become an issue, we could consider running the customer models in a parallel server on a different machine or something like that?

Thanks,
Prashant


On Mon, Dec 13, 2010 at 11:42 AM, chris.flath [via Power TAC Developers] <[hidden email]> wrote:

Dear all,
 
using the current list of tariff properties from the wiki as a base we tried to figure out possibilities on which attributes to realize with which “economic model / reasoning in behind”.
 
I will go through the list of tariff properties and provide examples how a customer would typically have to handle these. As before I will separate model requirements concerning a) tariff choice and b) consumption choice.
Note: These descriptions are on a high level – I will try to provide some more detailed ones soon. Moreover, they may have a certain bias towards households but most elements should be true for professional consumers / generators as well.
 
1. Tiered rates | should be included
-------------------------------------------------------------------------------
a) A customer model can easily use historic / expected load data and calculate the expected cost of a given tariff with tiered rate. Hence for tariff choice this is straight-forward to be implemented.
 
b) For consumption choice under such a tiered rate scheme we can imagine two aspects:
i)Demand reduction - if a consumer has a device which is not necessary to be run (e.g. electric heating, AC) he could be induced by the tiered rate to reduce the consumption of this device to remain below the threshold. Marginal utility from such devices will be decreasing in consumption and hence even simple customer model will be able to determine the optimal value beyond no more consumption takes place.
 
ii)Demand shifting to a different day to stay below threshold on both days - most shifting models currently focus on intra-day shifting only and – in case of Sebastian’s model for the Energy Policy paper - even suggest that there is little or no intraday shifting potential at least for household consumers. Consequently, at least end-consumer models, would probably ignore such tariff features (as they cannot really react to it).
-------------------------------------------------------------------------------
 
 
2. 24h-TOU | should be included
-------------------------------------------------------------------------------
a) A customer model can easily use historic / expected load data and calculate the expected cost of a given TOU tariff. Hence for tariff choice this is straight-forward to be implemented.
 
b) For consumption choice intraday TOU is easily modeled in a framework such as the one developed by Sebastian or Kishore and Snyder (http://www.lehigh.edu/~lvs2/Papers/PID1051346.pdf).
-------------------------------------------------------------------------------
 
 
3. Weekend/weekday-TOU | status unclear
-------------------------------------------------------------------------------
As this is directly linked to the issue of simulation time / skipping days I excluded it from this list. As noted above it is difficult to find good consumer models which can evaluate shifting horizons greater than 24hrs - therefore may be only limited weekday-weekend interaction and in that case weekends could be treated as completely separate competitions. This topic requires a bigger picture game design discussion on whether and how we manage overall competition time.
-------------------------------------------------------------------------------
 
 
4. Two-part tariffs | should be included
-------------------------------------------------------------------------------
a) A customer model can easily include a daily fixed fee in the total cost of the contract. In effect, even a signup-fee can be interpreted as the “fixed part” in a two-part tariff.
 
b) no effect on consumption choices
-------------------------------------------------------------------------------
 
 
5. Sign-up fees | should be included
-------------------------------------------------------------------------------
a) A customer model can easily include the sign-up fee in the total cost of the contract. If there is automatic renewal without sign-up fee at the end of the contract period the customer model will find this contract more attractive than another contract with sign-up fee. This endogenously gives rise to lock-in effects.
 
b) no effect on consumption choices
-------------------------------------------------------------------------------
 
 
6. Early withdrawal fee | should be dropped
-------------------------------------------------------------------------------
Allowing (consumer initiated) early withdrawal from contracts creates a bookkeeping mess and requires all customer models to constantly evaluate offered contracts vs. its current contract - server load we can save. We suggest that customers stay in a contract until the end of its runtime and runtimes can be anywhere between 1 and X days. Most of the lock-in effects can be captured with the sign-up fee / automatic renewal combination described above.
-------------------------------------------------------------------------------
 
 
7. Dynamic contracts | should be included in limited scale
-------------------------------------------------------------------------------
Again to limit complexity with respect to both the AS and the customer models we would suggest to keep dynamic contracts simple. We propose a day-ahead price update communicated at day change with the publication of the new tariff list. Notice that we only hand out weather forecast once a day and hence the two intervals would nicely coincide.
 
Customers under such a dynamic contract are granted an exit option at the end of the day if a tariff changed during the day in order to prevent the brokers from milking them. Given the presence of a default contract offered by the default broker there is a baseline cost which a broker is unlikely to exceed in order not to lose customers to the default broker. When the rates are not adjusted customers are not allowed to exit. This is a simple but guided solution and avoids us to venture into reputation system territory in the first version which I would personally like to avoid.
 
Notice that using the different attributes skillfully we can even describe something like a remote shedding contract (albeit in a less typical form): The broker dynamically adjusts the tariff to a two-tiered tariff with the tier 2 rate very, very high – a customer model with enough sheddable consumption may still find this tariff attractive if it offers low cost in other time segments. At the same time the broker can still prevent too small consumers from choosing this tariff by imposing a relatively high fixed fee!
 
a) Since customers are offered an exit option upon rate change they can simply evaluate the next 24hrs of a dynamic contract. Conservative consumers will probably factor in any sign-up fees as an extra charge for this minimum contract duration forcing brokers to cut down on sign-up fees on dynamic contracts. Dynamic contracts are distinguished by a "isDynamic" variable.
 
b) A customer could just use an expected rate to formulate its consumption plan in a dynamic contract. This seems like a reasonable heuristic but we will have to closely check this to prevent loopholes.
-------------------------------------------------------------------------------

Summary of our tariff proposal:

·         Hourly consumption / generation prices as variable price components

·         2-tier pricing possible, specified via threshold level and extra consumption / generation prices

·         Daily fee (bonus) as fixed priced component

·         Sign-up fee (bonus) due on contract start

·         Boolean isVariable to indicate whether the broker can change tariff  terms

·         Tariff duration indicated by min / max interval, if a contract runs out and a customer does not choose a different tariff a contract is automatically renewed

·         Customers cannot prematurely quit contracts except if a tariff change occurred

Given such a specification we would feel confident to provide corresponding demo customer implementations which can interact with such tariff offerings in a meaningful manner for the first round of competition next summer. Lacking any further knowledge, at least these customer models would not be able to operate with more complex tariffs. But with insights from the first competition this is likely to change. Hence, overall we found this to be a fair “first shot”, which seems to be realizable in the next very few weeks (the game specification has to be out very soon and along with it a proof-of-concept realization) on the one hand but with still significant playground for brokers to explore the tariff space. We fear that a more complex scheme may just increase the risk that our first competition being mostly about finding loopholes within the customer models.

I remember Prashant was very much in favor of keeping the early exit fee. Since he was busy with exams I hope he can soon join our discussion so that we thinks about the recent ideas.

John, you wrote your email while I was typing mine – I tried to address your point by editing the dynamic tariff section, I hope this worked.

 


View message @ http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2079713.html


To start a new topic under Power TAC Developers, email [hidden email]
To unsubscribe from Power TAC Developers, click here.




View message @ http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2079980.html
To start a new topic under Power TAC Developers, email [hidden email]
To unsubscribe from Power TAC Developers, click here.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: Customer model capabilities implied by tariff options

achryso
In reply to this post by grampajohn
Hello all, from the freezing (for our standards) Thessaloniki.

We are following this conversation with Andreas some time now and I would
like to share what we have already implemented, so that you can give us
some more work to do and also you don't have to go through work we have
already ready.

We have created the household models of the consumers. This models are
crated in Repast as it has been agreed right from the beginning, but I can
make them work in simple Java too.

We have already implemented random houses, so that the are filled with
random number of persons and appliances working through week intervals and
providing with the hourly load of each day. We have given them the
opportunity to read the hourly cost vector, even though we have not
implemented any shifting capabilities yet.

A village, city etc model has been integrated so that you can have many
households that give aggregated load for each weekday and can also read
the cost vector.

Prof. Collins, in his late discussion with Andreas, said that it would be
really useful to implement load profiles from different household types
(such as families, single-man or single-woman household, couples'
households etc) so now we are doing some experiments with the help of some
undergrads students so that we create feasible and realist models of these
households.

In this discussion, Prof. Collins also noted that weather should play a
part in this load profiles. Thought, we don't have any data on how weather
can affect household consumption. We would be glad if you could give us
some feedback on how to work on this.

Finally, we would like to know if we could help with implementing some (or
all) of the proposed tariff shifting capabilities in our models, even
though we should need the specifications on that matter.

Really looking forward to your feedback on our work. I will shortly upload
it (the completely implemented parts) on Launchpad.

Thank you in advance.

Anthony

>
>
> Chris and all -
>
> Thanks for the nice summary. It's important to keep in mind the
> complexity engendered by our design decisions, and it's also important
> to simplify our model when we can find simplifications that preserve
> research value and keep the scenario interesting and challenging for
> participants.
>
> I agree with much, but not quite all of your proposals. I also agree
> with Carsten that it makes sense to implement in stages. My concern is
> with the stage that is ready to run in July.
>
> My thoughts:
>
> 1. Cross-day demand shifting CAN happen, but probably not to a great
> extent. For example, people often have considerable flexibility when
> deciding when to do laundry. Also, I can easily imaging that people
> would adjust temperature settings on air conditioning or heating systems
> based on price. I would, and I know my children and their families
> would. This is not just shifting, it's shedding. There are some
> households, and many businesses, who have multiple energy sources for
> heating (and perhaps other purposes), and will decide which to use based
> on price. Many large buildings and campus facilities have central
> heating systems that can use different inputs, and only need to use all
> of them during extreme weather. In my case, I have an electric heat
> pump, a gas-fired furnace, and a wood-burning stove. Somebody has to be
> in the house to use the stove (it's running right now - the outdoor temp
> has come up to -19C from about -25 earlier this morning), but if I had
> variable pricing, I would use the gas furnace if gas was cheaper than
> electricity. With my current flat rate for interruptible power, it
> hardly ever is.
>
> 2. I think an important research and public policy issue is the extent
> to which customers can be "locked in" to a contract for a period of
> time. Early-exit fees are a way for brokers to hedge their risks and
> therefore offer lower prices. It's an important feature of real-world
> tariff contracts, and we need to be able to simulate it. Certainly we
> could use (configurable) market rules to limit the constraints placed on
> customers, but eliminating early-exit fees will make the competition
> less interesting and less valuable by a significant margin, in my opinion.
>
> 3. As with exit fees, dynamic-pricing contracts, with relatively short
> notification horizons, are an important risk-management strategy for
> brokers, and therefore offer the potential for significantly lower
> (average) prices for customers. Dropping this feature would also
> significantly affect the research value of Power TAC. For this reason, I
> am not in favor of allowing customers to opt out just because they
> agreed to variable pricing and then prices vary. Such a provision would
> destroy the risk-reduction value of dynamic pricing from the broker's
> standpoint, and therefore would pretty much eliminate the price
> advantage from the customer's standpoint.
>
> 4. Dynamic-pricing tariffs can include minimum and maximum rates, and
> expected average rates. As long as we have a working reputation
> mechanism, brokers will know that they cannot get away with "milking"
> their variable-price customers. In fact, as a broker designer, I would
> want to entice as many customers as possible to accept - and stay with -
> variable-pricing plans, because they should make my ability to manage my
> loads and financial risk much more robust.
>
> As I said, your proposal could be an acceptable stage on the way to full
> implementation, but it should be implemented as a subset of the full
> tariff representation, not a substitute. It's not clear whether you are
> proposing a completely different structure from the one given at
> https://github.com/powertac/domain-data/wiki/Tariff-representation or not.
>
> Cheers -
>
> John
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: AW: Customer model capabilities implied by tariff options

chris.flath
In reply to this post by grampajohn

Hi all!

 

Good to see that we are making progress in our tariff discussion. Let me once again underline that my main intention was sketching the customer model perspective of tariff objects, i.e. how to handle them intelligently without creating loopholes in the competition.

 

Considering your specific points:

-          John – my proposal was definitely meant as a concrete implementation of the tariff representation from the wiki, not an alternative specification. Also this proposal was mainly aimed to speed up the specification process until June ’11.

-          John – I am unsure if your response with respect to multi-day shifting was aimed towards requiring this capability from customer models or not. It seems that you mostly agree that the main effect of a tiered rate should be an incentive to reduce loads if possible?

-          John, Prashant & Wolf – I feel we mixed multiple elements into a single discussion: exit fees, exit option upon rate change and dynamic rate notification intervals. I think we should try to evaluate these options separately.

-          John, Prashant & Wolf – the exit option was meant to provide protection from milking for the customers. If a broker does not excessively change a tariff there should be no risk of major parts of the customer base quitting the broker.

-          Prashant – correct, my proposal implied no exit option from static tariffs – however, if maximum contract lengths are reasonably short customers get enough decision points to reevaluate their tariff choice. Especially for household customers it seems unlikely to continuously evaluate available tariff offers. More likely they only do it when their contract runs out.

-          Prashant & John – notification time of tariff changes. Can there be any robust scheduling / shifting of customer activities if prices can change all the time? Do you have any papers on this subject matter – it almost seems like a TAC for energy customers optimally timing their energy purchases!

-          Prashant – I very much liked your suggestion that engineering obstacles should not obstruct game design. We should keep this in mind for future evaluation of customer model issues (e.g. number of customer models in parallel)

 

Moreover, I agree with Carsten that feature proposals should include some kind of customer model guideline how to properly evaluate such a tariff feature with respect to both power planning and tariff choice. The group can scrutinize the integrity of this guideline and we thus have a gatekeeper for game design that may limit the risk of major design flaws arising.

 

Cheers from Karlsruhe,

 

Chris

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: Customer model capabilities implied by tariff options

Prashant Reddy
Hi all,

It seems that we're converging on (at least) two central issues -

1) Utility values, not just utility rankings:  In order for a customer to evaluate whether the exit fees are worth incurring, they need to be able to quantify the expected advantage of a different tariff; i.e., it's not enough to just rank order the tariffs, but actually be able to say approximately how much better one tariff is compared to the next.  Question to those implementing customer models: is this doable?  Even if it's not possible to quantify the exact advantage of one tariff, would it be possible to say whether it's likely to be greater than or lesser than some fixed amount (e.g. the exit fee)?


2) Customer protection:  As Chris suggests, it does seem that in order to prevent "milking" of customers by brokers, we need a safeguard which could be:

  a) a reputation system:  Does anyone already know what the best way to do this is?  I'm not sure how it's done in TAC SCM -- would that same method work here?  Is it difficult to implement?  If we don't already have a plan, see (c) below for one possible approach.

  b) an average price guarantee.  I don't see how this would work... if a customer knows that their aggregate price is not going to change, the incentive for load-shifting disappears, no?

  c) some sort of penalty fee on the broker for not staying within some confidence interval around the advertised "expected mean".  This confidence interval would be distinct from the max and min prices because a broker can have the flexibility to raise prices to max for a short period if they think they can lower them later to bring the average price back in line. If the penalty is equal to the difference between billed amount and expected amount, then this would become the same as average price guarantee, so it would not work -- the penalty needs to be smaller than that difference.  Maybe the penalty fees can then be used to partially reimburse the customer and also as an input into that brokers' reputation score?  If most brokers incurred similar penalties around the same timeslot, then the penalty wouldn't affect the reputation score as much (reflecting possibly higher cost price for the electricity in those timeslots).  This would give us a quantitive reputation score instead of just subjective "I don't like this broker" votes from customers.  The biggest problem with this approach is that it would be difficult to implement such a system in the real world unless all customers are willing to report the deviations, from advertised expected mean, that they are experiencing.  Thoughts?  Is this too complex?  Probably yes, but is it necessary complexity though?


Thanks,
Prashant



On Tue, Dec 14, 2010 at 9:36 AM, chris.flath [via Power TAC Developers] <[hidden email]> wrote:

Hi all!

 

Good to see that we are making progress in our tariff discussion. Let me once again underline that my main intention was sketching the customer model perspective of tariff objects, i.e. how to handle them intelligently without creating loopholes in the competition.

 

Considering your specific points:

-          John – my proposal was definitely meant as a concrete implementation of the tariff representation from the wiki, not an alternative specification. Also this proposal was mainly aimed to speed up the specification process until June ’11.

-          John – I am unsure if your response with respect to multi-day shifting was aimed towards requiring this capability from customer models or not. It seems that you mostly agree that the main effect of a tiered rate should be an incentive to reduce loads if possible?

-          John, Prashant & Wolf – I feel we mixed multiple elements into a single discussion: exit fees, exit option upon rate change and dynamic rate notification intervals. I think we should try to evaluate these options separately.

-          John, Prashant & Wolf – the exit option was meant to provide protection from milking for the customers. If a broker does not excessively change a tariff there should be no risk of major parts of the customer base quitting the broker.

-          Prashant – correct, my proposal implied no exit option from static tariffs – however, if maximum contract lengths are reasonably short customers get enough decision points to reevaluate their tariff choice. Especially for household customers it seems unlikely to continuously evaluate available tariff offers. More likely they only do it when their contract runs out.

-          Prashant & John – notification time of tariff changes. Can there be any robust scheduling / shifting of customer activities if prices can change all the time? Do you have any papers on this subject matter – it almost seems like a TAC for energy customers optimally timing their energy purchases!

-          Prashant – I very much liked your suggestion that engineering obstacles should not obstruct game design. We should keep this in mind for future evaluation of customer model issues (e.g. number of customer models in parallel)

 

Moreover, I agree with Carsten that feature proposals should include some kind of customer model guideline how to properly evaluate such a tariff feature with respect to both power planning and tariff choice. The group can scrutinize the integrity of this guideline and we thus have a gatekeeper for game design that may limit the risk of major design flaws arising.

 

Cheers from Karlsruhe,

 

Chris

 




View message @ http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2085774.html

To start a new topic under Power TAC Developers, email [hidden email]
To unsubscribe from Power TAC Developers, click here.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: Customer model capabilities implied by tariff options

grampajohn
Administrator
On 12/14/2010 10:05 AM, ppr [via Power TAC Developers] wrote:

> Hi all,
>
> It seems that we're converging on (at least) two central issues -
>
> 1) Utility values, not just utility rankings:  In order for a customer
> to evaluate whether the exit fees are worth incurring, they need to be
> able to quantify the expected advantage of a different tariff; i.e.,
> it's not enough to just rank order the tariffs, but actually be able to
> say approximately how much better one tariff is compared to the next.
>   Question to those implementing customer models: is this doable?  Even
> if it's not possible to quantify the exact advantage of one tariff,
> would it be possible to say whether it's likely to be greater than or
> lesser than some fixed amount (e.g. the exit fee)?
>
>
> 2) Customer protection:  As Chris suggests, it does seem that in order
> to prevent "milking" of customers by brokers, we need a safeguard which
> could be:
>
>    a) a reputation system:  Does anyone already know what the best way
> to do this is?  I'm not sure how it's done in TAC SCM -- would that same
> method work here?  Is it difficult to implement?  If we don't already
> have a plan, see (c) below for one possible approach.

In SCM, the reputation of an agent is based on the (weighted) proportion
of its supplier RFQs that are actually ordered. This prevents agents
from jacking up prices by creating bogus demand. Once you pass a
threshold (you don't have to place orders for ALL your RFQs), then your
demand becomes invisible to your competitors for the purpose of price
calculation, but the demand of the higher-reputation agents IS visible
to the lower-reputation agents.

I think this is a pretty domain-specific technique, but the general idea
is that if you try to jerk around your competitors and business
partners, you get punished.

I'm not in favor of the penalty fee, because I don't see how it would
work in the real world. Let's remember that we expect tariff uptake to
be relatively slow, and so a fairly simple reputation mechanism should
be effective.

There is one other scenario that could be a problem, though: an end-game
strategy in which some broker convinces a large number of customers to
adopt a variable-price tariff with a low expected price, and then jack
up the prices late in the game (but before the customers' subscriptions
run out) at a time when reputation effects won't have much impact.

There is a way to completely avoid this problem; That would be to allow
variable rates that are a straight markup over the wholesale market
prices. Is this enough?

John


>
>    b) an average price guarantee.  I don't see how this would work... if
> a customer knows that their aggregate price is not going to change, the
> incentive for load-shifting disappears, no?
>
>    c) some sort of penalty fee on the broker for not staying within some
> confidence interval around the advertised "expected mean".  This
> confidence interval would be distinct from the max and min prices
> because a broker can have the flexibility to raise prices to max for a
> short period if they think they can lower them later to bring the
> average price back in line. If the penalty is equal to the difference
> between billed amount and expected amount, then this would become the
> same as average price guarantee, so it would not work -- the penalty
> needs to be smaller than that difference.  Maybe the penalty fees can
> then be used to partially reimburse the customer and also as an input
> into that brokers' reputation score?  If most brokers incurred similar
> penalties around the same timeslot, then the penalty wouldn't affect the
> reputation score as much (reflecting possibly higher cost price for the
> electricity in those timeslots).  This would give us a quantitive
> reputation score instead of just subjective "I don't like this broker"
> votes from customers.  The biggest problem with this approach is that it
> would be difficult to implement such a system in the real world unless
> all customers are willing to report the deviations, from advertised
> expected mean, that they are experiencing.  Thoughts?  Is this too
> complex?  Probably yes, but is it necessary complexity though?
>
>
> Thanks,
> Prashant
>
>
>
> On Tue, Dec 14, 2010 at 9:36 AM, chris.flath [via Power TAC Developers]
> <[hidden email] </user/SendEmail.jtp?type=node&node=2086276&i=0>> wrote:
>
>     Hi all!
>
>     Good to see that we are making progress in our tariff discussion.
>     Let me once again underline that my main intention was sketching the
>     customer model perspective of tariff objects, i.e. how to handle
>     them intelligently without creating loopholes in the competition.
>
>     Considering your specific points:
>
>     -John – my proposal was definitely meant as a concrete
>     implementation of the tariff representation from the wiki, not an
>     alternative specification. Also this proposal was mainly aimed to
>     speed up the specification process until June ’11.
>
>     -John – I am unsure if your response with respect to multi-day
>     shifting was aimed towards requiring this capability from customer
>     models or not. It seems that you mostly agree that the main effect
>     of a tiered rate should be an incentive to reduce loads if possible?
>
>     -John, Prashant & Wolf – I feel we mixed multiple elements into a
>     single discussion: exit fees, exit option upon rate change and
>     dynamic rate notification intervals. I think we should try to
>     evaluate these options separately.
>
>     -John, Prashant & Wolf – the exit option was meant to provide
>     protection from milking for the customers. If a broker does not
>     excessively change a tariff there should be no risk of major parts
>     of the customer base quitting the broker.
>
>     -Prashant – correct, my proposal implied no exit option from static
>     tariffs – however, if maximum contract lengths are reasonably short
>     customers get enough decision points to reevaluate their tariff
>     choice. Especially for household customers it seems unlikely to
>     continuously evaluate available tariff offers. More likely they only
>     do it when their contract runs out.
>
>     -Prashant & John – notification time of tariff changes. Can there be
>     any robust scheduling / shifting of customer activities if prices
>     can change all the time? Do you have any papers on this subject
>     matter – it almost seems like a TAC for energy customers optimally
>     timing their energy purchases!
>
>     -Prashant – I very much liked your suggestion that engineering
>     obstacles should not obstruct game design. We should keep this in
>     mind for future evaluation of customer model issues (e.g. number of
>     customer models in parallel)
>
>     Moreover, I agree with Carsten that feature proposals should include
>     some kind of customer model guideline how to properly evaluate such
>     a tariff feature with respect to both power planning and tariff
>     choice. The group can scrutinize the integrity of this guideline and
>     we thus have a gatekeeper for game design that may limit the risk of
>     major design flaws arising.
>
>     Cheers from Karlsruhe,
>
>     Chris
>
>
>
>     ------------------------------------------------------------------------
>     View message @
>     http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2085774.html
>     <http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2085774.html?by-user=t>
>
>     To start a new topic under Power TAC Developers, email [hidden
>     email] </user/SendEmail.jtp?type=node&node=2086276&i=1>
>     To unsubscribe from Power TAC Developers, click here
>     <
>
>
>
>
>
> ------------------------------------------------------------------------
> View message @
>
http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2086276.html
> To start a new topic under Power TAC Developers, email
> [hidden email]
> To unsubscribe from Power TAC Developers, click here
> <
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: AW: Customer model capabilities implied by tariff options

grampajohn
Administrator
In reply to this post by chris.flath
Chris, Carsten, Prashant, and all -

On 12/14/2010 08:36 AM, chris.flath [via Power TAC Developers] wrote:
> Hi all!
>
> Good to see that we are making progress in our tariff discussion. Let me
> once again underline that my main intention was sketching the customer
> model perspective of tariff objects, i.e. how to handle them
> intelligently without creating loopholes in the competition.

It's been a long day, and I'm pretty sleepy, so my responses may lack
some coherence. But I thought it would be good to get something out today.

>
> Considering your specific points:
>
> -John – my proposal was definitely meant as a concrete implementation of
> the tariff representation from the wiki, not an alternative
> specification. Also this proposal was mainly aimed to speed up the
> specification process until June ’11.

Understood. This is important.

>
> -John – I am unsure if your response with respect to multi-day shifting
> was aimed towards requiring this capability from customer models or not.
> It seems that you mostly agree that the main effect of a tiered rate
> should be an incentive to reduce loads if possible?

Yes. But I'm also saying that it's reasonable to expect some load
shedding in addition to shifting under variable rates. Whether we
implement multi-day load shifting or not is a separate issue.

>
> -John, Prashant & Wolf – I feel we mixed multiple elements into a single
> discussion: exit fees, exit option upon rate change and dynamic rate
> notification intervals. I think we should try to evaluate these options
> separately.
>
> -John, Prashant & Wolf – the exit option was meant to provide protection
> from milking for the customers. If a broker does not excessively change
> a tariff there should be no risk of major parts of the customer base
> quitting the broker.

I just don't see this type of regulation being imposed on the markets we
are trying to model. Any variable-price tariff, including one that
simply passes on wholesale prices with a markup, will show price peaks
that are considerably higher than any acceptable fixed rate. But since
variable pricing shifts some risk to the customer, and gives the broker
a way to improve its balancing ability, the average price should be
lower than fixed rates in a competitive market.

What we don't want to do is effectively disable variable pricing in the
simulation, because it is an important type of tariff that's discussed
in the literature. In the Smart Grid literature, it's called "Prices to
Devices". We need to be able to model it.

>
> -Prashant – correct, my proposal implied no exit option from static
> tariffs – however, if maximum contract lengths are reasonably short
> customers get enough decision points to reevaluate their tariff choice.
> Especially for household customers it seems unlikely to continuously
> evaluate available tariff offers. More likely they only do it when their
> contract runs out.
>
> -Prashant & John – notification time of tariff changes. Can there be any
> robust scheduling / shifting of customer activities if prices can change
> all the time? Do you have any papers on this subject matter – it almost
> seems like a TAC for energy customers optimally timing their energy
> purchases!

My assumption is NOT that the price for a given timeslot would be
changed repeatedly, but that it would be communicated once with the
agreed leadtime. So if your tariff says variable prices with 2-hour
notification, then you would know the price for the 13:00-14:00 timeslot
at 11:00. Just one announcement for each timeslot.

>
> -Prashant – I very much liked your suggestion that engineering obstacles
> should not obstruct game design. We should keep this in mind for future
> evaluation of customer model issues (e.g. number of customer models in
> parallel)
>
> Moreover, I agree with Carsten that feature proposals should include
> some kind of customer model guideline how to properly evaluate such a
> tariff feature with respect to both power planning and tariff choice.
> The group can scrutinize the integrity of this guideline and we thus
> have a gatekeeper for game design that may limit the risk of major
> design flaws arising.

As an experienced software professional, I always tend to think of
software design first. But in this case, market design is at least as
important as technical software design. If the market design is flawed
or too constrained to be interesting to researchers, all our work will
be wasted. Perhaps this is an area where we should get Mathijs de Weert
involved.

John
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: Customer model capabilities implied by tariff options

grampajohn
Administrator
In reply to this post by achryso
On 12/14/2010 02:12 AM, achryso [via Power TAC Developers] wrote:

> Hello all, from the freezing (for our standards) Thessaloniki.
>
> We are following this conversation with Andreas some time now and I would
> like to share what we have already implemented, so that you can give us
> some more work to do and also you don't have to go through work we have
> already ready.
>
> We have created the household models of the consumers. This models are
> crated in Repast as it has been agreed right from the beginning, but I can
> make them work in simple Java too.
>
> We have already implemented random houses, so that the are filled with
> random number of persons and appliances working through week intervals and
> providing with the hourly load of each day. We have given them the
> opportunity to read the hourly cost vector, even though we have not
> implemented any shifting capabilities yet.
>
> A village, city etc model has been integrated so that you can have many
> households that give aggregated load for each weekday and can also read
> the cost vector.

It sounds to me like we should put high priority on getting Antonios'
models integrated into the server. Do we have a plan for that?

>
> Prof. Collins, in his late discussion with Andreas, said that it would be
> really useful to implement load profiles from different household types
> (such as families, single-man or single-woman household, couples'
> households etc) so now we are doing some experiments with the help of some
> undergrads students so that we create feasible and realist models of these
> households.
>
> In this discussion, Prof. Collins also noted that weather should play a
> part in this load profiles. Thought, we don't have any data on how weather
> can affect household consumption. We would be glad if you could give us
> some feedback on how to work on this.

We found a couple of papers that might help. See near the bottom of
http://www.powertac.org/wiki/index.php/BackgroundReading, under "Impact
of weather ...".

>
> Finally, we would like to know if we could help with implementing some (or
> all) of the proposed tariff shifting capabilities in our models, even
> though we should need the specifications on that matter.
>
> Really looking forward to your feedback on our work. I will shortly upload
> it (the completely implemented parts) on Launchpad.

We are not using Launchpad any more; we were concerned with the
long-term viability of bazaar. We have switched everything over to
github. See https://github.com/powertac/. David should be able to give
you a guided tour.

Cheers -

John
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Customer model implementation

chris.flath

Antonios,

 

I am about to start working on default customer implementation in the next few days – as soon as I start working on this I will keep you in the loop and we can collaborate more closely on implementation.

 

I am unsure on how to integrate Repast customer models but I guess David can shed some light on this question soon.

 

Cheers,

 

Chris

 

Von: grampajohn [via Power TAC Developers] [mailto:[hidden email]]
Gesendet: Mittwoch, 15. Dezember 2010 05:10
An: Christoph Flath
Betreff: Re: AW: Customer model capabilities implied by tariff options

 

On 12/14/2010 02:12 AM, achryso [via Power TAC Developers] wrote:


> Hello all, from the freezing (for our standards) Thessaloniki.
>
> We are following this conversation with Andreas some time now and I would
> like to share what we have already implemented, so that you can give us
> some more work to do and also you don't have to go through work we have
> already ready.
>
> We have created the household models of the consumers. This models are
> crated in Repast as it has been agreed right from the beginning, but I can
> make them work in simple Java too.
>
> We have already implemented random houses, so that the are filled with
> random number of persons and appliances working through week intervals and
> providing with the hourly load of each day. We have given them the
> opportunity to read the hourly cost vector, even though we have not
> implemented any shifting capabilities yet.
>
> A village, city etc model has been integrated so that you can have many
> households that give aggregated load for each weekday and can also read
> the cost vector.

It sounds to me like we should put high priority on getting Antonios'
models integrated into the server. Do we have a plan for that?




View message @ http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2089921.html
To start a new topic under Power TAC Developers, email
[hidden email]
To unsubscribe from Power TAC Developers,
click here.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: Customer model capabilities implied by tariff options

Prashant Reddy
In reply to this post by grampajohn
Hi all,

On Tuesday afternoon, Chris and I had an impromptu Skype chat on the "customer protection" topic.  Some of what we discussed then has been superseded by the subsequent discussion on this thread, but we figured it would be useful to post the summary of our discussion nonetheless.  (Thanks to Chris for writing up the summary -- I made some edits.)  Please review the summary in the attached text file.  Sorry for the delay in posting this -- I was travelling yesterday.

John, what you've since said about restricting dynamic tariffs to only allow prices that are pegged to the wholesale market is one of the options we considered (#2 in the first bullet list).  This may indeed be the best short term option, if we don't want to implement a reputation system for this year.

Thanks,
Prashant

[PS:  We should post this summary in meeting notes somewhere on the wiki -- we'll do that.]



On Tue, Dec 14, 2010 at 10:46 PM, grampajohn [via Power TAC Developers] <[hidden email]> wrote:
On 12/14/2010 10:05 AM, ppr [via Power TAC Developers] wrote:

> Hi all,
>
> It seems that we're converging on (at least) two central issues -
>
> 1) Utility values, not just utility rankings:  In order for a customer
> to evaluate whether the exit fees are worth incurring, they need to be
> able to quantify the expected advantage of a different tariff; i.e.,
> it's not enough to just rank order the tariffs, but actually be able to
> say approximately how much better one tariff is compared to the next.
>   Question to those implementing customer models: is this doable?  Even
> if it's not possible to quantify the exact advantage of one tariff,
> would it be possible to say whether it's likely to be greater than or
> lesser than some fixed amount (e.g. the exit fee)?
>
>
> 2) Customer protection:  As Chris suggests, it does seem that in order
> to prevent "milking" of customers by brokers, we need a safeguard which
> could be:
>
>    a) a reputation system:  Does anyone already know what the best way
> to do this is?  I'm not sure how it's done in TAC SCM -- would that same
> method work here?  Is it difficult to implement?  If we don't already
> have a plan, see (c) below for one possible approach.
In SCM, the reputation of an agent is based on the (weighted) proportion
of its supplier RFQs that are actually ordered. This prevents agents
from jacking up prices by creating bogus demand. Once you pass a
threshold (you don't have to place orders for ALL your RFQs), then your
demand becomes invisible to your competitors for the purpose of price
calculation, but the demand of the higher-reputation agents IS visible
to the lower-reputation agents.

I think this is a pretty domain-specific technique, but the general idea
is that if you try to jerk around your competitors and business
partners, you get punished.

I'm not in favor of the penalty fee, because I don't see how it would
work in the real world. Let's remember that we expect tariff uptake to
be relatively slow, and so a fairly simple reputation mechanism should
be effective.

There is one other scenario that could be a problem, though: an end-game
strategy in which some broker convinces a large number of customers to
adopt a variable-price tariff with a low expected price, and then jack
up the prices late in the game (but before the customers' subscriptions
run out) at a time when reputation effects won't have much impact.

There is a way to completely avoid this problem; That would be to allow
variable rates that are a straight markup over the wholesale market
prices. Is this enough?

John


>
>    b) an average price guarantee.  I don't see how this would work... if
> a customer knows that their aggregate price is not going to change, the
> incentive for load-shifting disappears, no?
>
>    c) some sort of penalty fee on the broker for not staying within some
> confidence interval around the advertised "expected mean".  This
> confidence interval would be distinct from the max and min prices
> because a broker can have the flexibility to raise prices to max for a
> short period if they think they can lower them later to bring the
> average price back in line. If the penalty is equal to the difference
> between billed amount and expected amount, then this would become the
> same as average price guarantee, so it would not work -- the penalty
> needs to be smaller than that difference.  Maybe the penalty fees can
> then be used to partially reimburse the customer and also as an input
> into that brokers' reputation score?  If most brokers incurred similar
> penalties around the same timeslot, then the penalty wouldn't affect the
> reputation score as much (reflecting possibly higher cost price for the
> electricity in those timeslots).  This would give us a quantitive
> reputation score instead of just subjective "I don't like this broker"
> votes from customers.  The biggest problem with this approach is that it
> would be difficult to implement such a system in the real world unless
> all customers are willing to report the deviations, from advertised
> expected mean, that they are experiencing.  Thoughts?  Is this too
> complex?  Probably yes, but is it necessary complexity though?
>
>
> Thanks,
> Prashant
>
>
>
> On Tue, Dec 14, 2010 at 9:36 AM, chris.flath [via Power TAC Developers]
> <[hidden email] </user/SendEmail.jtp?type=node&node=2086276&i=0>> wrote:

>
>     Hi all!
>
>     Good to see that we are making progress in our tariff discussion.
>     Let me once again underline that my main intention was sketching the
>     customer model perspective of tariff objects, i.e. how to handle
>     them intelligently without creating loopholes in the competition.
>
>     Considering your specific points:
>
>     -John – my proposal was definitely meant as a concrete
>     implementation of the tariff representation from the wiki, not an
>     alternative specification. Also this proposal was mainly aimed to
>     speed up the specification process until June ’11.
>
>     -John – I am unsure if your response with respect to multi-day
>     shifting was aimed towards requiring this capability from customer
>     models or not. It seems that you mostly agree that the main effect
>     of a tiered rate should be an incentive to reduce loads if possible?
>
>     -John, Prashant & Wolf – I feel we mixed multiple elements into a
>     single discussion: exit fees, exit option upon rate change and
>     dynamic rate notification intervals. I think we should try to
>     evaluate these options separately.
>
>     -John, Prashant & Wolf – the exit option was meant to provide
>     protection from milking for the customers. If a broker does not
>     excessively change a tariff there should be no risk of major parts
>     of the customer base quitting the broker.
>
>     -Prashant – correct, my proposal implied no exit option from static
>     tariffs – however, if maximum contract lengths are reasonably short
>     customers get enough decision points to reevaluate their tariff
>     choice. Especially for household customers it seems unlikely to
>     continuously evaluate available tariff offers. More likely they only
>     do it when their contract runs out.
>
>     -Prashant & John – notification time of tariff changes. Can there be
>     any robust scheduling / shifting of customer activities if prices
>     can change all the time? Do you have any papers on this subject
>     matter – it almost seems like a TAC for energy customers optimally
>     timing their energy purchases!
>
>     -Prashant – I very much liked your suggestion that engineering
>     obstacles should not obstruct game design. We should keep this in
>     mind for future evaluation of customer model issues (e.g. number of
>     customer models in parallel)
>
>     Moreover, I agree with Carsten that feature proposals should include
>     some kind of customer model guideline how to properly evaluate such
>     a tariff feature with respect to both power planning and tariff
>     choice. The group can scrutinize the integrity of this guideline and
>     we thus have a gatekeeper for game design that may limit the risk of
>     major design flaws arising.
>
>     Cheers from Karlsruhe,
>
>     Chris
>
>
>
>     ------------------------------------------------------------------------
>     View message @
>     http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2085774.html
>     <http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2085774.html?by-user=t>
>
>     To start a new topic under Power TAC Developers, email [hidden
>     email] </user/SendEmail.jtp?type=node&node=2086276&i=1>
>     To unsubscribe from Power TAC Developers, click here
>     <
>
>
>
>
>
> ------------------------------------------------------------------------
> View message @
>
http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2086276.html

> To start a new topic under Power TAC Developers, email
> [hidden email]
> To unsubscribe from Power TAC Developers, click here
> <
>






cflath_preddy_on_tariffs.txt (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: Customer model capabilities implied by tariff options

John
The attachment function in Nabble is pretty inconvenient; probably better to just write up a wiki page.

In any case, I have a few responses to the points raised in the attachment (I'll re-number the last four items as 6-9). But first, I want to offer another way to think about the issue of "customer milking" with variable-rate contracts. I don't see it as a big deal, because customers can bail on contracts any time they want. Sure, many contracts will have early-exit penalties; as a Broker, I want to achieve some measure of stability in my portfolio so I get some chance to learn the responses of customers to my actions. But the customer can always decide that they would be better off paying the penalty than continuing to pay the exorbitant rates its broker is posting. I also think some sort of simple reputation system will help control this effectively. That's a favorite topic of Wolf and Yixin - perhaps one or both of them could jump in here with a more concrete suggestion on how it would work, or better yet, start a new thread to discuss a reputation mechanism.

My thoughts on the attachment:

1. Average hourly rate ceiling - sounds impractical and unworkable.

2. Restrict dynamic prices to some strict relationship to wholesale market prices - defeats much of the risk-management purpose of dynamic pricing.

3. Publishing realized average prices for dynamic-price tariffs sounds like a really good idea.

4. I expect rates to be announced every single hour on every dynamic-price contract. That's what I would do as a broker-writer. Perhaps that should be the expected behavior? As I said earlier, the price for each timeslot should be announced exactly once, with the leadtime specified in the tariff.

5. These are variable-rate contracts. Rates will in general change every hour.

6. "Skipping days in the simulation should be avoided"??? This is a major change in the design of the simulation, buried in an attachment on a completely unrelated topic. If you really want to propose this, then please start a new thread so folks will be able to find the discussion later.

7. I don't think it's going to be productive to speculate further on cross-day load shifting until we have specific models to discuss.

8. I agree that tariff evaluation should happen more than once/24 hours.

9. Agreed, but as I said, we should expect prices to be announced for variable-rate tariffs every hour.
123
Loading...