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
|

Re: AW: Customer model capabilities implied by tariff options

JDcosta
 A very interesting exposition of the likely consumer behavior responsive to economic signals. I am particularly intrigued by your assessment of the likely difficulties in realizing the tariff choice and the consumption choice consumer models.

Assuming two of the determinants of the consumer's behavior are likely to be search costs (i.e. trying to find information that would maximize the benefit accruing to the consumer) and switching costs (i.e. the cost of ditching a retail arrangement for another that maximizes some utility function), several questions come to mind:

1) As far as the "reputation" metric of the broker is concerned:  The distribution of power to the consumer - the physical delivery, is fulfilled by the distribution and transmission operators independent of the broker/retailer with whom the customer has contracted with in any particular period. Any problems with the delivery of power and so forth will reflect on the broker/retailer's reputation metric because the consumer does not have a view of all of the variables (including costs and forward contracts to affect delivery) that go into this part of the marketplace but the broker does (or should). The other side of the coin is where the perception of lack of reliability arises in instances where a broker has entered into arrangements that necessitate frequent brown-outs / power shedding to one segment of the broker's portfolio base in favor of another segment that the broker considers to be premium customers because the broker has under-estimated demand etc. This is a legitimate instance where a broker's reputation should be impacted. But there is no way to separate the first and second instances. A good PR firm could easily convince a consumer that the unreliability is always due to the power transmission system not being able to deliver.

A tariff, besides including the price of power, typically also includes ancillary costs (power line maintenance, meter reading fee, etc). I presume, as far as this simulation goes, there is no way to tweak the "delivery" variable to provide a better quality of service (as far as power delivery) is concerned for a premium.

2) Information Asymmetries: The type of information available to the consumer and the broker is likely to be different - content wise and time of availability wise. In other words, the consumer may not be in a position to respond to the marginal cost (i.e. cost of an additional unit as the market changes) but must respond to some average (end of the day, month, etc). The demand and supply responsiveness have some distortions pre-built into them. This is likely to engender some form of consumer inertia which will be further magnified if switching costs are steep. Is it possible to account for and try to ameliorate  the supply and demand side information asymmetries to get the consumer to react more often

3) While it is important to charge a consumer for switching costs, is there a danger that a "padding" factor is introduced to dissuade the consumer from switching - how can one obtain a measure of the cost actually incurred by the system if a consumer were to switch?

Finally, all of the above points may not be "realistic" to this simulation but to quote John  [user: grampajohn ] in one of the discussions on this thread;

"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. "

JDcosta
Reply | Threaded
Open this post in threaded view
|

Re: AW: Customer model capabilities implied by tariff options

Prashant Reddy
In reply to this post by John
Hi John,

Totally agree that #6 is out of place there.  Chris may want to comment on it, but apparently there is some ongoing discussion on that topic in Karlsruhe and they were indeed planning on raising/proposing it separately -- it was premature to say anything about it in this document.  It certainly wasn't intended to be a takeaway from our discussion.

Regarding #2, I guess I misunderstood your message from yesterday then where I thought you were proposing this as well.  I do agree that it is too restrictive nevertheless, so we can just move on from it.

Glad to see you like #3.  We settled on that as a variation/simplification of the penalty-based reputation system (I had originally proposed the penalty as a fraction of realized average minus expected average).  Do you view the published realized average prices as a possible basis of a reputation system as suggested or do you think this is information that's independent of the reputation system?  Asked another way, should we start a reputation system thread based on this point, or leave it to Wolf or Yixin to start that thread?

Thanks,
Prashant


On Thu, Dec 16, 2010 at 5:07 PM, John [via Power TAC Developers] <[hidden email]> wrote:
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 change 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 mechan! ism.

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.



View message @ http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2101295.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
|

Re: AW: Customer model capabilities implied by tariff options

grampajohn
Administrator
In reply to this post by John
We discussed this issue today in our group meeting, and a couple of interesting ideas came out. We offer these in the hope of getting closure on this issue reasonably quickly.

1. All tariffs are public knowledge.

2. It won't work to allow tariffs to have early-exit fees that are smaller than their sign-up bonuses.

3. We assume customers will be averse to large early-exit fees (more than the expected cost of power for a month, for example).

4. With two additional fields, the tariffs themselves could provide a nice reputation mechanism:
  - offerDate shows the date the tariff was first offered.
  - realizedPrice is initially unknown; it's filled in by the Accounting Service to reflect what customers are actually paying. We need to decide exactly how it's computed, of course. If it's a short-term rolling average, it could be pretty volatile. It could be something like the exponentially-smoothed daily mean price, with a small alpha to control volatility. That way, a broker could not get away with starting low and then raising prices once a good value of realized-price is achieved.

5. By making realized-price a feature of the Tariff, it's not only visible to customers, but also to other brokers.

6. We would not treat the price announcements for a dynamic-price tariff to be tariff modifications. But the record of prices should be public knowledge after the fact. Perhaps once/day or so?

7. Although Tariffs are public knowledge, the subscriptions to a Tariff are presumably not public. This limits the ability to describe exactly how much data is represented by a realized-price value. That's why we added the offer date.

8. One kind of tariff modification that should be allowed at any time is modifications that do not affect current subscriptions. An example would be a change in signup bonus. So a broker could try to entice customers into a dynamic-price deal with a substantial sign-up bonus, and then once the tariff has a good realized-price record, the bonus could be reduced.
Reply | Threaded
Open this post in threaded view
|

Re: AW: Customer model capabilities implied by tariff options

grampajohn
Administrator
In reply to this post by Prashant Reddy
On 12/16/2010 08:09 PM, ppr [via Power TAC Developers] wrote:

> Hi John,
>
> Glad to see you like #3.  We settled on that as a
> variation/simplification of the penalty-based reputation system (I had
> originally proposed the penalty as a fraction of realized average minus
> expected average).  Do you view the published realized average prices as
> a possible basis of a reputation system as suggested or do you think
> this is information that's independent of the reputation system?  Asked
> another way, should we start a reputation system thread based on this
> point, or leave it to Wolf or Yixin to start that thread?

I hope that my last post showed a way the realized-average price could
be exposed in a public way that works even for a new tariff that has no
record of realized price. Does it make sense?

We should let Wolf and Yixin take up the reputation idea separately; I
believe Yixin has some specific ideas.

John
Reply | Threaded
Open this post in threaded view
|

AW: AW: Customer model capabilities implied by tariff options

chris.flath
In reply to this post by grampajohn

Hi John this sounds very good and it seems to map very nicely into the database representation envisioned for tariffs:

 

1.       Right – this provides a learning opportunity for brokers as they can infer preferences of customers who did not sign up with them.

2.       Well, I guess we do not have to rule it out because it will be the brokers’ own fault if they are milked by customers J

3.       Yes this seems to be natural. I would assume even more so for dynamic contracts.

4.       I had a quick chat with Carsten on how tariff accounting works on the database level. We started a demo Google spreadsheet to illustrate how the data record evolves for different scenarios. This is work in progress and I invite everybody to join us at http://bit.ly/efINyj to improve this. Do we need realizedPrice as a column of its own or can any customer model just calculate it itself and thus use any type of price history it would like?

5.       Agreed. This probably is ok since brokers should have the same information available as any customer.

6.       Let me reinterpret this – brokers can only change dynamic tariffs. If they want to change their standard non-dynamic tariffs they have to revoke the old tariff offering and publish a new one. Thus, “changed” is an attribute exclusive for dynamic tariffs.

7.       Agreed.

8.       Very interesting point – this still works in the construct described in 6. We may want to limit the set of changeable attributes to keep things simple? E.g., sign-up fee, hourly price vectors can be changed but nothing else?

 

I will try to fill the Google spreadsheet to better illustrate these thoughts.

 

Cheers, Chris!

                                                                                                                            

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

 

We discussed this issue today in our group meeting, and a couple of interesting ideas came out. We offer these in the hope of getting closure on this issue reasonably quickly.

1. All tariffs are public knowledge.

2. It won't work to allow tariffs to have early-exit fees that are smaller than their sign-up bonuses.

3. We assume customers will be averse to large early-exit fees (more than the expected cost of power for a month, for example).

4. With two additional fields, the tariffs themselves could provide a nice reputation mechanism:
  - offerDate shows the date the tariff was first offered.
  - realizedPrice is initially unknown; it's filled in by the Accounting Service to reflect what customers are actually paying. We need to decide exactly how it's computed, of course. If it's a short-term rolling average, it could be pretty volatile. It could be something like the exponentially-smoothed daily mean price, with a small alpha to control volatility. That way, a broker could not get away with starting low and then raising prices once a good value of realized-price is achieved.

5. By making realized-price a feature of the Tariff, it's not only visible to customers, but also to other brokers.

6. We would not treat the price announcements for a dynamic-price tariff to be tariff modifications. But the record of prices should be public knowledge after the fact. Perhaps once/day or so?

7. Although Tariffs are public knowledge, the subscriptions to a Tariff are presumably not public. This limits the ability to describe exactly how much data is represented by a realized-price value. That's why we added the offer date.

8. One kind of tariff modification that should be allowed at any time is modifications that do not affect current subscriptions. An example would be a change in signup bonus. So a broker could try to entice customers into a dynamic-price deal with a substantial sign-up bonus, and then once the tariff has a good realized-price record, the bonus could be reduced.


View message @ http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2102564.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
|

Re: Customer model implementation

achryso
In reply to this post by chris.flath
Hello everybody from Christmas decorated Thessaloniki

I would like to inform you that I uploaded a functional project with my
Consumers' models.

The repository in Github is

https://github.com/chrysopoulos18/Consumer-Models

If you download the zip file of my repo, you can just add existing project
in the Repast 2.0 environment and run the Consumer Models.

I haven't fixed the javadocs fully yet, but that's my first priority (my
next commit). You can change the village number to your houses (now it's
just 2 houses) and the program will work as it should.

I am looking forward for any additions or notes over my models as well as
the necessary adjustments needed to put them in the server.

Thank you in advance.

Antonios.

>
>
> 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
> <http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilitie
> s-implied-by-tariff-options-tp2063345p2089921.html>
> To start a new topic under Power TAC Developers, email
> [hidden email]
> <mailto:[hidden email]>
> To unsubscribe from Power TAC Developers, click here
> <http://power-tac-developers.975333.n3.nabble.com/template/NamlServlet.jtp?m
> acro=unsubscribe_by_code&node=1884242&code=ZmxhdGhAZnppLmRlfDE4ODQyNDJ8NDIzO
> TkzNTUz> .
>
>
> ______________________________________
> View message @
> http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2090860.html
> To start a new topic under Power TAC Developers, email
> [hidden email]
> To unsubscribe from Power TAC Developers, visit
>
Reply | Threaded
Open this post in threaded view
|

Re: Customer model implementation

ddauer
Hello Antonios,

we've been looking at your customer model and here's what you need to do to get it working with the new Power TAC server:

1. Follow https://github.com/powertac/powertac-server/wiki/Plugin-development-getting-started to create your own "powertac-customer-simple" plugin. Feel free to change the name of course, but be more specific than "powertac-customer" as there will be multiple customer plugins.

2. Make sure to implement the org.powertac.common.interfaces.Customer interface

3. For now, you can do your model initialization in the service you created in Step 6. A specific initialization handler will be provided in a future update.

4. I'm not sure why you created your Repast agents visually since it seems like it took quite some time, but you probably will be able to just copy most of the generated Groovy files to the new plugin. I would however recommend you get rid of the Repast specific stuff in these files. Also, you'll have to change the business logic of your customer model to react to the events provided by the org.powertac.common.interfaces.Customer interface as opposed to relying on the Repast tick-based scheduling system and simply printing stuff out to the console.

Please let us know if you have any questions during the migration process.

Cheers,

David

On Mon, Dec 20, 2010 at 8:25 AM, achryso [via Power TAC Developers] <[hidden email]> wrote:
Hello everybody from Christmas decorated Thessaloniki

I would like to inform you that I uploaded a functional project with my
Consumers' models.

The repository in Github is

https://github.com/chrysopoulos18/Consumer-Models

If you download the zip file of my repo, you can just add existing project
in the Repast 2.0 environment and run the Consumer Models.

I haven't fixed the javadocs fully yet, but that's my first priority (my
next commit). You can change the village number to your houses (now it's
just 2 houses) and the program will work as it should.

I am looking forward for any additions or notes over my models as well as
the necessary adjustments needed to put them in the server.

Thank you in advance.

Antonios.

>
>
> 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
> <http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilitie
> s-implied-by-tariff-options-tp2063345p2089921.html>
> To start a new topic under Power TAC Developers, email
> [hidden email]
> <mailto:[hidden email]>
> To unsubscribe from Power TAC Developers, click here
> <http://power-tac-developers.975333.n3.nabble.com/template/NamlServlet.jtp?m
> acro=unsubscribe_by_code&node=1884242&code=ZmxhdGhAZnppLmRlfDE4ODQyNDJ8NDIzO
> TkzNTUz> .
>
>
> ______________________________________
> [hidden email]
> To unsubscribe from Power TAC Developers, visit
>







Reply | Threaded
Open this post in threaded view
|

RE: Customer model implementation

Wolf
Administrator

Hello David,

 

Thanks for the update! I have three master students at RSM who are planning to write their thesis on the Repast broker agent (focusing on different parts, i.e. portfolio management, prediction, balancing, etc.). Given the new server structure, do you have an estimate when the first demo Repast agent is ready for use (assuming that you work on this)?

 

Thanks,

 

Wolf

 

From: ddauer [via Power TAC Developers] [mailto:[hidden email]]
Sent: Friday, January 14, 2011 11:05 AM
To: Wolf Ketter
Subject: Re: Customer model implementation

 

Hello Antonios,

 

we've been looking at your customer model and here's what you need to do to get it working with the new Power TAC server:

 

1. Follow https://github.com/powertac/powertac-server/wiki/Plugin-development-getting-started to create your own "powertac-customer-simple" plugin. Feel free to change the name of course, but be more specific than "powertac-customer" as there will be multiple customer plugins.

 

2. Make sure to implement the org.powertac.common.interfaces.Customer interface

 

3. For now, you can do your model initialization in the service you created in Step 6. A specific initialization handler will be provided in a future update.

 

4. I'm not sure why you created your Repast agents visually since it seems like it took quite some time, but you probably will be able to just copy most of the generated Groovy files to the new plugin. I would however recommend you get rid of the Repast specific stuff in these files. Also, you'll have to change the business logic of your customer model to react to the events provided by the org.powertac.common.interfaces.Customer interface as opposed to relying on the Repast tick-based scheduling system and simply printing stuff out to the console.

 

Please let us know if you have any questions during the migration process.

 

Cheers,

 

David

 

On Mon, Dec 20, 2010 at 8:25 AM, achryso [via Power TAC Developers] <[hidden email]> wrote:

Hello everybody from Christmas decorated Thessaloniki

I would like to inform you that I uploaded a functional project with my
Consumers' models.

The repository in Github is

https://github.com/chrysopoulos18/Consumer-Models

If you download the zip file of my repo, you can just add existing project
in the Repast 2.0 environment and run the Consumer Models.

I haven't fixed the javadocs fully yet, but that's my first priority (my
next commit). You can change the village number to your houses (now it's
just 2 houses) and the program will work as it should.

I am looking forward for any additions or notes over my models as well as
the necessary adjustments needed to put them in the server.

Thank you in advance.

Antonios.


>
>
> 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
> <http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilitie
> s-implied-by-tariff-options-tp2063345p2089921.html>
> To start a new topic under Power TAC Developers, email
> [hidden email]

> <mailto:[hidden email]>

> To unsubscribe from Power TAC Developers, click here

> <http://power-tac-developers.975333.n3.nabble.com/template/NamlServlet.jtp?m
> acro=unsubscribe_by_code&node=1884242&code=ZmxhdGhAZnppLmRlfDE4ODQyNDJ8NDIzO
> TkzNTUz> .
>
>
> ______________________________________

> [hidden email]
> To unsubscribe from Power TAC Developers, visit
> class=MsoNormal style='margin-bottom:12.0pt'>






 

 


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



Disclaimer
De informatie verzonden in dit e-mail bericht inclusief de bijlage(n) is vertrouwelijk en is uitsluitend bestemd voor de geadresseerde van dit bericht. Lees verder: http://www.eur.nl/email-disclaimer.

The information in this e-mail message is confidential and may be legally privileged. Read more: http://www.eur.nl/english/email-disclaimer.

Reply | Threaded
Open this post in threaded view
|

Re: Customer model implementation

ddauer
Hi Wolf,

our plan is to have the server core components ready by the end of January. This means that all modules will be created and linked but complex business logic still needs to be implemented afterwards. Daniel will take care of a Grails demo broker agent while I will update my old Repast demo broker agent. Due to our exams being in a couple of weeks and some core server work, including adding business logic to modules, that needs to be done first, we estimate to have the demo clients ready around the end of February.

This does not mean that your students won't be able to work until then. They will need to come up with strategies and corresponding algorithms and so on before working with Repast anyway. I talked to them a couple of days ago and they seemed to have a pretty good idea about how the Repast broker agent from my thesis works and how the Power TAC environment is set up. Also, the new Repast broker agent will not be that much different, so with that in mind I think they should have enough to go on for the next couple of weeks.

Cheers,
David

On Fri, Jan 14, 2011 at 11:37 AM, Wolf [via Power TAC Developers] <[hidden email]> wrote:

Hello David,

 

Thanks for the update! I have three master students at RSM who are planning to write their thesis on the Repast broker agent (focusing on different parts, i.e. portfolio management, prediction, balancing, etc.). Given the new server structure, do you have an estimate when the first demo Repast agent is ready for use (assuming that you work on this)?

 

Thanks,

 

Wolf

 

From: ddauer [via Power TAC Developers] [mailto:[hidden email]]
Sent: Friday, January 14, 2011 11:05 AM
To: Wolf Ketter
Subject: Re: Customer model implementation

 

Hello Antonios,

 

we've been looking at your customer model and here's what you need to do to get it working with the new Power TAC server:

 

1. Follow https://github.com/powertac/powertac-server/wiki/Plugin-development-getting-started to create your own "powertac-customer-simple" plugin. Feel free to change the name of course, but be more specific than "powertac-customer" as there will be multiple customer plugins.

 

2. Make sure to implement the org.powertac.common.interfaces.Customer interface

 

3. For now, you can do your model initialization in the service you created in Step 6. A specific initialization handler will be provided in a future update.

 

4. I'm not sure why you created your Repast agents visually since it seems like it took quite some time, but you probably will be able to just copy most of the generated Groovy files to the new plugin. I would however recommend you get rid of the Repast specific stuff in these files. Also, you'll have to change the business logic of your customer model to react to the events provided by the org.powertac.common.interfaces.Customer interface as opposed to relying on the Repast tick-based scheduling system and simply printing stuff out to the console.

 

Please let us know if you have any questions during the migration process.

 

Cheers,

 

David

 

On Mon, Dec 20, 2010 at 8:25 AM, achryso [via Power TAC Developers] <[hidden email]> wrote:

Hello everybody from Christmas decorated Thessaloniki

I would like to inform you that I uploaded a functional project with my
Consumers' models.

The repository in Github is

https://github.com/chrysopoulos18/Consumer-Models

If you download the zip file of my repo, you can just add existing project
in the Repast 2.0 environment and run the Consumer Models.

I haven't fixed the javadocs fully yet, but that's my first priority (my
next commit). You can change the village number to your houses (now it's
just 2 houses) and the program will work as it should.

I am looking forward for any additions or notes over my models as well as
the necessary adjustments needed to put them in the server.

Thank you in advance.

Antonios.


>
>
> 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
> <http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilitie
> s-implied-by-tariff-options-tp2063345p2089921.html>
> To start a new topic under Power TAC Developers, email
> [hidden email]

> <mailto:[hidden email]>

>


Disclaimer
De informatie verzonden in dit e-mail bericht inclusief de bijlage(n) is vertrouwelijk en is uitsluitend bestemd voor de geadresseerde van dit bericht. Lees verder: http://www.eur.nl/email-disclaimer.

The information in this e-mail message is confidential and may be legally privileged. Read more: http://www.eur.nl/english/email-disclaimer.




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
|

RE: Customer model implementation

Wolf
Administrator

Thanks David. I have met with them and discussed, of course, several strategies on the broker, and I’ll meet them again today. I just needed a good estimate for the Repast broker.

 

Cheers,

 

Wolf

 

From: ddauer [via Power TAC Developers] [mailto:[hidden email]]
Sent: Friday, January 14, 2011 01:38 PM
To: Wolf Ketter
Subject: Re: Customer model implementation

 

Hi Wolf,

 

our plan is to have the server core components ready by the end of January. This means that all modules will be created and linked but complex business logic still needs to be implemented afterwards. Daniel will take care of a Grails demo broker agent while I will update my old Repast demo broker agent. Due to our exams being in a couple of weeks and some core server work, including adding business logic to modules, that needs to be done first, we estimate to have the demo clients ready around the end of February.

 

This does not mean that your students won't be able to work until then. They will need to come up with strategies and corresponding algorithms and so on before working with Repast anyway. I talked to them a couple of days ago and they seemed to have a pretty good idea about how the Repast broker agent from my thesis works and how the Power TAC environment is set up. Also, the new Repast broker agent will not be that much different, so with that in mind I think they should have enough to go on for the next couple of weeks.

 

Cheers,

David

 

On Fri, Jan 14, 2011 at 11:37 AM, Wolf [via Power TAC Developers] <[hidden email]> wrote:

Hello David,

 

Thanks for the update! I have three master students at RSM who are planning to write their thesis on the Repast broker agent (focusing on different parts, i.e. portfolio management, prediction, balancing, etc.). Given the new server structure, do you have an estimate when the first demo Repast agent is ready for use (assuming that you work on this)?

 

Thanks,

 

Wolf

 

From: ddauer [via Power TAC Developers] [mailto:[hidden email]]
Sent: Friday, January 14, 2011 11:05 AM
To: Wolf Ketter
Subject: Re: Customer model implementation

 

Hello Antonios,

 

we've been looking at your customer model and here's what you need to do to get it working with the new Power TAC server:

 

1. Follow https://github.com/powertac/powertac-server/wiki/Plugin-development-getting-started to create your own "powertac-customer-simple" plugin. Feel free to change the name of course, but be more specific than "powertac-customer" as there will be multiple customer plugins.

 

2. Make sure to implement the org.powertac.common.interfaces.Customer interface

 

3. For now, you can do your model initialization in the service you created in Step 6. A specific initialization handler will be provided in a future update.

 

4. I'm not sure why you created your Repast agents visually since it seems like it took quite some time, but you probably will be able to just copy most of the generated Groovy files to the new plugin. I would however recommend you get rid of the Repast specific stuff in these files. Also, you'll have to change the business logic of your customer model to react to the events provided by the org.powertac.common.interfaces.Customer interface as opposed to relying on the Repast tick-based scheduling system and simply printing stuff out to the console.

 

Please let us know if you have any questions during the migration process.

 

Cheers,

 

David

 

On Mon, Dec 20, 2010 at 8:25 AM, achryso [via Power TAC Developers] <[hidden email]> wrote:

Hello everybody from Christmas decorated Thessaloniki

I would like to inform you that I uploaded a functional project with my
Consumers' models.

The repository in Github is

https://github.com/chrysopoulos18/Consumer-Models

If you download the zip file of my repo, you can just add existing project
in the Repast 2.0 environment and run the Consumer Models.

I haven't fixed the javadocs fully yet, but that's my first priority (my
next commit). You can change the village number to your houses (now it's
just 2 houses) and the program will work as it should.

I am looking forward for any additions or notes over my models as well as
the necessary adjustments needed to put them in the server.

Thank you in advance.

Antonios.


>
>
> 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
> <http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilitie
> s-implied-by-tariff-options-tp2063345p2089921.html>
> To start a new topic under Power TAC Developers, email
> [hidden email]

> <mailto:[hidden email]>

>


Disclaimer

De informatie verzonden in dit e-mail bericht inclusief de bijlage(n) is vertrouwelijk en is uitsluitend bestemd voor de geadresseerde van dit bericht. Lees verder: http://www.eur.nl/email-disclaimer.


The information in this e-mail message is confidential and may be legally privileged. Read more: http://www.eur.nl/english/email-disclaimer.





 

 


View message @ http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2255165.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
|

Re: Customer model implementation

achryso
In reply to this post by ddauer
Hello David.

I have spent the last two weeks trying to master Grails and I think I understood the inner logic of project creation.

I would like to ask a question as far as the migration from Repast is concerned. Up to now I have created the randomizers and the configuration file in order to create object from the models automatically.

In my Grails plugin, you want to create just a Grails Wrapper, to initialize my models and just give the aggregated results in Grails-like web pages.

Or you want me to create the persons - appliances - households etc and put them into the databases and
be able to see the list of them and their status - load - cost etc.

What I'm asking is, do I have to rewrite my groovy models in order to have Controllers - Views so that can be seen as a database or I just have to migrate them, just making my results appear in a Grails Enviroment as a whole?

Thank you in advance. Looking forward to your reply.

Cheers,

Antonios
Reply | Threaded
Open this post in threaded view
|

Re: Customer model implementation

ddauer
Hello Antonios,

the latter option is definitely the better one - you however don't have to add controllers/views to get database access. Just rewrite your domain classes (person, appliance) according to the GORM documentation (http://grails.org/doc/latest/guide/5.%20Object%20Relational%20Mapping%20(GORM).html).

You can put your work in another Github Repository if you want me to take a closer look at it.

Also, have you looked at the plugin development guide at https://github.com/powertac/powertac-server/wiki/Plugin-development-getting-started? A basic customer skeleton is available at https://github.com/powertac-plugins/powertac-customer-default.

David
Reply | Threaded
Open this post in threaded view
|

Re: Customer model implementation

achryso
Hello David.

I have rewrite and checked my models in GRAILS. They are working fine, as they were before.

Now I will try to see how your default Customer is written to try and manipulate my models the same way.

The Repository of my GRAILS customer models is in https://github.com/chrysopoulos18/Consumer-Grails if you want to check them out.

I will try to encapsulate the clock of the simulation server on it and then I will make the plugin. Or should I do it the other way around?? Any comment on the code or hints on the correct procedure will be appreciated.

Cheers

Antonios
Reply | Threaded
Open this post in threaded view
|

Re: Customer model implementation

Carsten Block
Administrator
Hi Antonios,

> I will try to encapsulate the clock of the simulation server on it and then I will make the plugin. Or should I do it the other way around?? Any comment on the code or hints on the correct procedure will be appreciated.

Today we want to release 0.5 version of powertac-common plugin. It will ship with the simulation clock as part of the package. So after the official release announcement here on the mailing list just run grails install-plugin powertac-common 0.5 from your command line and then you should have the auction clock installed into your plugin too.

Carsten
Reply | Threaded
Open this post in threaded view
|

Re: Customer model implementation

achryso
Hi Carsten,

It's been a week or so since your email, and yet the release version 0.5 of the powertac-common plugin hasn't been out. It's there a problem or I'm missing something else??

Is there any way to make my through without it?

Antonios
Reply | Threaded
Open this post in threaded view
|

Re: Customer model implementation

grampajohn
Administrator
On 02/07/2011 03:02 AM, achryso [via Power TAC Developers] wrote:
> Hi Carsten,
>
> It's been a week or so since your email, and yet the release version 0.5
> of the powertac-common plugin hasn't been out. It's there a problem or
> I'm missing something else??
>
> Is there any way to make my through without it?

The repository at KIT does not seem to be actively maintained, and the
0.5 version is very out-of-date in any case. I recommend you use the
current master branch of powertac-common from github instead.
Instructions for using a local plugin are at
http://power-tac-developers.975333.n3.nabble.com/ANN-powertac-common-0-3-3-td2249093.html.

Cheers -

John
Reply | Threaded
Open this post in threaded view
|

Re: Customer model implementation

Carsten Block
Administrator
Hi!

I think it's the binary plugin repository at http://ibwstinger.iw.uni-karlsruhe.de/artifactory that Anthonis means. This does not comprise a 0.5 version of the powertac-common plugin yet as it has not been released.
If you want to compile your own powertac-common plugin from the latest source version do the following:

1.) check out the powertac-common main branch from <a href="git://github.com/powertac-plugins/powertac-common.git">git://github.com/powertac-plugins/powertac-common.git (or download and unzip it from https://github.com/powertac-plugins/powertac-common)
2.) go to the checkout directory and do "grails package-plugin"
3.) cd to you own working directory (e.g. your customer plugin) and do grails install-plugin /local/path/to/grails-powertac-common-0.5-SNAPSHOT.zip

Cheers,
Carsten

Am 07.02.2011 um 15:45 schrieb grampajohn [via Power TAC Developers]:

On 02/07/2011 03:02 AM, achryso [via Power TAC Developers] wrote:
> Hi Carsten,
>
> It's been a week or so since your email, and yet the release version 0.5
> of the powertac-common plugin hasn't been out. It's there a problem or
> I'm missing something else??
>
> Is there any way to make my through without it?

The repository at KIT does not seem to be actively maintained, and the
0.5 version is very out-of-date in any case. I recommend you use the
current master branch of powertac-common from github instead.
Instructions for using a local plugin are at
http://power-tac-developers.975333.n3.nabble.com/ANN-powertac-common-0-3-3-td2249093.html.

Cheers -

John



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
|

Re: Customer model implementation

grampajohn
Administrator
Carsten Block wrote
Hi!

...
2.) go to the checkout directory and do "grails package-plugin"
3.) cd to you own working directory (e.g. your customer plugin) and do grails install-plugin /local/path/to/grails-powertac-common-0.5-SNAPSHOT.zip
If you do the package-plugin command, the result will be powertac-common-0.9. I changed the config and pushed it yesterday.
Reply | Threaded
Open this post in threaded view
|

Re: Customer model implementation

achryso
I would like to thank both of you.

I have encapsulated the powertac-common plugin correctly and now I am experimenting with the TimeService in order to make my models functtion by using this time clock. Hopefully it's not going to be hard.

Next I will try to change my models so that they become similar with the dummy consumer model that you have imported in the common plugin.

Have a good night (or day depending on where you are)!

Antonios
Reply | Threaded
Open this post in threaded view
|

Re: Customer model implementation

grampajohn
Administrator
I have just pushed a significant set of updates to powertac-common that expands the functionality of Tariff and TariffSubscription, and generates all the transaction types (other than PRODUCTION so far) needed to represent Customer interactions with a Tariff and TariffSubscription. For the purposes of Accounting, all these transactions are attached to the current Timeslot, making it easy to collect them together and process them.
123