On customer model

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

On customer model

easwar1977
Dear all,
 
   I have some queries on the retail customer base that is part of a powertac game.  Let us for the sake of example pick a customer by name "EASTSIDEOFFICES" whose powertype is CONSUMPTION.

    a) Is it that a customer by the same name, albeit with different customer id, would be available in all games that are played ?  
   
    b) If so, what are the broad underlying factors, except weather, that causes change in his consumption behavior from one game to another ?

    d) Or is it that, from the perspective of the broker, in a given game, the customer is as good as a new one even though the broker has seen the customer with same name in a previous game ?

    e)  What can be said about a similar query on a EV vehicle customer like "MiddleIncome-3_20" ? We observe his attributes like upRegulation, downRegulation, Storage are all different across games. Are they as good as different customers for a broker across games ?  

    f) I never understood the boot file information such as the one given below :

     <property name="evcustomer.customers.evCustomer.MiddleIncome-1_9.driving" value="false"/>

     <property name="evcustomer.customers.evSocialClass.MiddleIncome-1.customerAttributeList" value="[6.male.Leaf24.x, 2.female.Leaf24.x, 2.male.Leaf24.x, 6.male.Tesla60.x, 4.female.Leaf24.x, 5.female.Tesla60.x, 7.male.Leaf24.x, 4.male.Tesla40.x, 3.male.Tesla60.x, 1.female.Leaf24.x, 7.male.Leaf24.x, 2.male.Leaf24.x, 2.male.Leaf24.x, 2.male.Tesla60.x, 2.female.Leaf24.x, 2.female.Leaf24.x, 2.male.Leaf24.x, 2.female.Tesla60.x, 2.female.Leaf24.x, 2.male.Leaf24.x, 2.female.Tesla60.x, 1.male.Leaf24.x, 2.female.Tesla60.x, 5.male.Leaf24.x, 2.female.Leaf24.x, 2.male.Leaf24.x, 5.female.Tesla40.x, 7.female.Leaf24.x, 5.female.Tesla40.x]"/>

    What is the significance of this information ? How and for what a broker can make use of this information ?

Regards,
Easwar
Reply | Threaded
Open this post in threaded view
|

Re: On customer model

grampajohn
Administrator
easwar1977 wrote
I have some queries on the retail customer base that is part of a powertac game.  Let us for the sake of example pick a customer by name "EASTSIDEOFFICES" whose powertype is CONSUMPTION.

    a) Is it that a customer by the same name, albeit with different customer id, would be available in all games that are played ?  
   
    b) If so, what are the broad underlying factors, except weather, that causes change in his consumption behavior from one game to another ?

    d) Or is it that, from the perspective of the broker, in a given game, the customer is as good as a new one even though the broker has seen the customer with same name in a previous game ?
Most customer models, including EASTSIDEOFFICES, are defined by the server configuration. Some of these configurations allow for some randomization when the model instances are created, but most do not. However, almost all models have a fair amount of randomization built into their behavior.

    e)  What can be said about a similar query on a EV vehicle customer like "MiddleIncome-3_20" ? We observe his attributes like upRegulation, downRegulation, Storage are all different across games. Are they as good as different customers for a broker across games ?  
The current EV model creates instances from several "social classes" like MiddleIncome. The number of instances of each class is randomized, so although the behavior of MiddleIncome instances is broadly similar, their detailed hour-by-hour behavior is mostly driven by random sequences.

    f) I never understood the boot file information such as the one given below :

     <property name="evcustomer.customers.evCustomer.MiddleIncome-1_9.driving" value="false"/>

     <property name="evcustomer.customers.evSocialClass.MiddleIncome-1.customerAttributeList" value="[6.male.Leaf24.x, 2.female.Leaf24.x, 2.male.Leaf24.x, 6.male.Tesla60.x, 4.female.Leaf24.x, 5.female.Tesla60.x, 7.male.Leaf24.x, 4.male.Tesla40.x, 3.male.Tesla60.x, 1.female.Leaf24.x, 7.male.Leaf24.x, 2.male.Leaf24.x, 2.male.Leaf24.x, 2.male.Tesla60.x, 2.female.Leaf24.x, 2.female.Leaf24.x, 2.male.Leaf24.x, 2.female.Tesla60.x, 2.female.Leaf24.x, 2.male.Leaf24.x, 2.female.Tesla60.x, 1.male.Leaf24.x, 2.female.Tesla60.x, 5.male.Leaf24.x, 2.female.Leaf24.x, 2.male.Leaf24.x, 5.female.Tesla40.x, 7.female.Leaf24.x, 5.female.Tesla40.x]"/>

    What is the significance of this information ? How and for what a broker can make use of this information ?
Very good question. Some of what's in the boot record is there to communicate model state from the end of a boot session to the start of a sim session. The server needs it to correctly start a sim session that starts in the same state where the boot session ended. For example, if an EV is currently "driving" (not plugged in) at the end of a boot session, it starts out unplugged in any sim session that uses that boot record. In the case of electric vehicles, the entire population is created through a stochastic process at the start of a boot session, and must be re-created at the start of a corresponding sim session. Otherwise the bootstrap data that describes customer consumption/production for the two weeks prior to the sim session would be invalid.

Does this make sense?

John
Reply | Threaded
Open this post in threaded view
|

Re: On customer model

easwar1977
Thanks John. Yes, that was helpful.

Easwar
Reply | Threaded
Open this post in threaded view
|

Re: On customer model

Demijan
I see the inconvenience=0.0 is consistent in the logs. Is this their conclusion switching is not inconvenient or is it an inconvenience default factor set at 0?

Kind regards,
Demijan
Reply | Threaded
Open this post in threaded view
|

Re: On customer model

grampajohn
Administrator
Demijan wrote
I see the inconvenience=0.0 is consistent in the logs. Is this their conclusion switching is not inconvenient or is it an inconvenience default factor set at 0?
That does seem odd. Note that you would only expect to see non-zero values in certain cases, such as evaluating a tariff for interruptible consumption, or with multiple rates (tiered or time-of-use tariff) or variable pricing. But the sample broker issues such tariffs, and it seems very likely that at least some brokers are using such features.

This may be a bug; I'm pretty sure I've seen non-zero values there in the past. I'll see if I can track this down.

John