Major revision needed for Customer interface

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

Major revision needed for Customer interface

grampajohn
Administrator
This is a follow-on to the thread titled "Need for Abstract Customer type" The org.powertac.common.Customer interface in the server-interface plugin was apparently designed under the assumption that Customer models would be relatively static objects that wait until queried externally. In my opinion this is an unnecessary constraint that places too much responsibility for behavior on some other element of the system and not enough on the Customer. If we assume that some Customer models will be relatively complex, then this is perhaps an unrealistic assumption. I have tried to lay out some basic Customer behaviors in https://github.com/powertac/powertac-server/wiki/Scenarios. This model assumes that Customers will be responsible for running their models (perhaps in parallel) driven by the simulation clock. It also assumes that the various Tariffs to which a Customer is subscribed will influence the behaviors of individuals within a population model, and so it's not enough to just split production and consumption among the subscriptions after the fact. With this in mind, the only method in the existing Customer interface that remains relevant is generateCustomerInfo(). The Customer will then be responsible for retrieving its own Weather forecasts and reports if it needs them, for looking at the current available Tariffs and switching its subscriptions, and for producing and consuming power with respect to each of its current subscriptions. The TariffSubscription instances in turn will be responsible for generating the MeterReading objects, although I think that's not really the right name, because it needs also to encompass signup bonuses, early-withdrawal penalties, and periodic payments. The next step is to pare down the Customer interface and think about what responsibilities could be delegated to an AbstractCustomer that is common to all Customer types. I will create an issue to cover the changes to Customer while we discuss what an AbstractCustomer might need to do. Does this make sense? John
Reply | Threaded
Open this post in threaded view
|

Re: Major revision needed for Customer interface

grampajohn
Administrator
As part of this process I am going to rename MeterReading to TariffTransaction. See issue #106.

John
Reply | Threaded
Open this post in threaded view
|

Re: Major revision needed for Customer interface

achryso
In reply to this post by grampajohn
> The org.powertac.common.Customer interface in the server-interface plugin
> was apparently designed under the assumption that Customer models would be
> relatively static objects that wait until queried externally. In my
> opinion this is an unnecessary constraint that places too much
> responsibility for behavior on some other element of the system and not
> enough on the Customer.

I agree that customers (consumers - producers) should be more independent
entities than mere query-driven entities.

> If we assume that some Customer models will be relatively complex, then
> this
> is perhaps an unrealistic assumption. I have tried to lay out some basic
> Customer behaviors in
> https://github.com/powertac/powertac-server/wiki/Scenarios. This model
> assumes that Customers will be responsible for running their models
> (perhaps
> in parallel) driven by the simulation clock. It also assumes that the
> various Tariffs to which a Customer is subscribed will influence the
> behaviors of individuals within a population model, and so it's not enough
> to just split production and consumption among the subscriptions after the
> fact.

That is the way that made sense to me and how I implemented my models.
Though I had to manually create the timeslots and run the time service to
make time pass, but I guess that will be implemented as an automated
sequence in the server.


> With this in mind, the only method in the existing Customer interface that
> remains relevant is generateCustomerInfo(). The Customer will then be
> responsible for retrieving its own Weather forecasts and reports if it
> needs
> them, for looking at the current available Tariffs and switching its
> subscriptions, and for producing and consuming power with respect to each
> of
> its current subscriptions. The TariffSubscription instances in turn will
> be
> responsible for generating the MeterReading objects, although I think
> that's
> not really the right name, because it needs also to encompass signup
> bonuses, early-withdrawal penalties, and periodic payments.

I will need to change my code in order to utilize the TariffSubscription
as a source of the MeterReading objects because now we created by the
customer models: I read the time in simulation and created an MeterReading
for the according timeslot and insert it in the customer and the timeslot.
Now I guess I will do the same but through TarrifSubscription.


> The next step is to pare down the Customer interface and think about what
> responsibilities could be delegated to an AbstractCustomer that is common
> to
> all Customer types. I will create an issue to cover the changes to
> Customer
> while we discuss what an AbstractCustomer might need to do.
>
> Does this make sense?

That made perfect sense and I will be happy to help the best I can.

Anthony

Reply | Threaded
Open this post in threaded view
|

Re: Major revision needed for Customer interface

grampajohn
Administrator
On 02/14/2011 05:09 PM, achryso [via Power TAC Developers] wrote:

>  > The org.powertac.common.Customer interface in the server-interface
> plugin
>  > was apparently designed under the assumption that Customer models
> would be
>  > relatively static objects that wait until queried externally. In my
>  > opinion this is an unnecessary constraint that places too much
>  > responsibility for behavior on some other element of the system and not
>  > enough on the Customer.
>
> I agree that customers (consumers - producers) should be more independent
> entities than mere query-driven entities.
>
>  > ... I have tried to lay out some basic
>  > Customer behaviors in
>  > https://github.com/powertac/powertac-server/wiki/Scenarios. ...
>
> That is the way that made sense to me and how I implemented my models.
> Though I had to manually create the timeslots and run the time service to
> make time pass, but I guess that will be implemented as an automated
> sequence in the server.

Yes, that will be automatic. Timeslot is on my list of pieces to clean
up. There are only so many hours in the day; perhaps I should try to
write down exactly what needs to be done so someone else can do it.

>
>
>  > With this in mind, the only method in the existing Customer interface
> that
>  > remains relevant is generateCustomerInfo(). ...
 >  > The TariffSubscription instances in turn will be
>  > responsible for generating the MeterReading objects, although I think
>  > that's not really the right name. ...
>
> I will need to change my code in order to utilize the TariffSubscription
> as a source of the MeterReading objects because now we created by the
> customer models: I read the time in simulation and created an MeterReading
> for the according timeslot and insert it in the customer and the timeslot.
> Now I guess I will do the same but through TarrifSubscription.

You don't need to worry at all about generating TariffTransaction
instances (formerly called MeterReading). That will be done inside
TariffSubscription.usePower(). It's not committed yet, but it's all
written and partway through testing. The TariffSubscription will also
generate the transactions for signup bonus and early withdrawal.

>
>
>  > The next step is to pare down the Customer interface and think about
> what
>  > responsibilities could be delegated to an AbstractCustomer that is
> common
>  > to
>  > all Customer types. I will create an issue to cover the changes to
>  > Customer
>  > while we discuss what an AbstractCustomer might need to do.
>  >
>  > Does this make sense?
>
> That made perfect sense and I will be happy to help the best I can.

I think once I have this set of updates committed, I should look at your
code and we should talk. Thanks for your help.

John