However I could not see any significant change on the results. I would expect that, on a simple experiment with two brokers, for a lambda of 0, about half of the customers subscribe to my tariff, since it is a random decision between two brokers. As I increase the lambda, more customers would suscribe to my tariff, which is better than the reference. I assume customers evaluate a tariff at each evaluation period.
So I tried to check if the server was reading the lambda values. First of all I modified the RaS Lambda values on configuration file:
I then added some lines on /household-customer/src/main/java/org/powertac/householdcustomer/HouseholdCustomerService.java :
int testlambda =
log.info("testlambda:" + testlambda);
I compiled the whole server and ran the simulation, I observed this line on the server's log trace:
53335 INFO householdcustomer.HouseholdCustomerService: testlambda: 43
Which is the value I configured on the VillageType1.properties... so far so good, the configuration value was read by the server. However, with different lambdas, no difference was seen on the customer preferences.
So I digged a little bit more and arrived to this file /server-interface/src/main/java/org/powertac/common/TariffEvaluator.java, the lines that caught my eye were this ones:
Because it calculates another lambda based on lambdaMax and rationality values, which are declared on this class as fixed values. The value calculated at each evaluation interval is: 32.81216689031207. And it uses this lambda to decide which tariff is to be selected regardless of the lambda configured on VillageType1.properties.
I arrived to this file following this steps:
1) Method publishNewTariffs at /household-customer/src/main/java/org/powertac/householdcustomer/HouseholdCustomerService.java
2) Method evaluateNewTariffs at /household-customer/src/main/java/org/powertac/householdcustomer/customers/Village.java
3) Method evaluateTariffs at /server-interface/src/main/java/org/powertac/common/TariffEvaluator.java
The questions that are in my mind are:
1) With a high value of lambda the customers will pick my tariff, given that it is better that the reference (lets say reference is 0.5$/energy and mine 0.4$/energy for a consumption tariff), with a probability of almost one. If the lambda is 0, they will pick a random tariff regardless the perceived utility.
2) Is there some error on the server evaluation process where the lambda saved on /VillageType1.properties is not considered on the tariff decision process at TariffEvaluator.java?
Thank you very much. I'll appreciate any thought on these issues.
I apologize for being slow to respond. I have had very little time for the last couple of weeks, and it's unlikely to get better for a couple more weeks.
As you have seen, the "lambda" value specified in Section 4.1.2 of the 2014 spec is not directly specified by customer models. Instead, the customer specifies a "rationality" value, which is then used to compute the value of lambda in the evaluation process as you have discovered. So the number you want to modify to change a customer's decision is the rationality value. The reason for this design decisions was to (1) ensure we don't run into overflow problems with bad choices of lambda, and (2) to allow "rationality" to be specified in the range [0..1]. So the lambda values in the model are not used; they are dead code, left over from early experiments with tariff evaluation that was superseded when we implemented the TariffEvaluator scheme. They should be removed to reduce confusion.
However, the rationality factor for the household-customer models is not specified in the config file, but in the VillageConstants class, where it is set to 0.9. This should probably be fixed. I don't have time to work on this for at least the next two weeks; I suggest you either fix it yourself (and if you do that, I would invite you to submit your changes as a pull request), or talk it over with Antonios and see if he is willing to work with you to fix it. I would post an issue on this, but there's something weird going on with GitHub this evening.
Antonios has pushed a fix for Issue #770, which makes "Rationality" a configurable value for both household-customer and officecomplex-customer. I don't have time to set up my environment and test it for at least a few days. If you are willing, I invite you to pull down the updates and try it out.