Making Sense of Tariffs and Rates

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

Making Sense of Tariffs and Rates

markus
I'm currently trying to understand the types of tariffs used by various brokers during the Nuremberg pilots. Looking at the rate structure, I fail to see the semantics of some of them. Here are a few examples:

(1) Fixed = true, Min = 0.0, Max = -2.1, ExpMean = -0.6

This seems to be inconsistent for a fixed tariff. For a fixed tariff, I would expect something like the default broker in the same game published: Fixed = true, Min = Max = ExpMean = -0.5.

(2) Fixed = false, Min = -0.1, Max = 0, ExpMean = 0

This is not inconsistent per se. But, unless the minimum was chosen pathologically and this is really a fixed tariff, the mean will probably fall somewhere other than 0. Is there a mechanism in place that prevents brokers from announcing faulty expectations?

(3) Fixed = true, Min = 0, Max = -3.6, ExpMean = -1,1

Is this the right order for Min/Max? Why would a fixed tariff have different Min/Max/ExpMean values?

(4) Fixed = true, Min = Max = ExpMean = 0, NoticeInterval = 1

Can a fixed tariff have a notice interval? Also, the rate is pathological. Although I suppose there's nothing wrong with giving away energy for free as part of an aggressive strategy.

(5) There appear to be tariffs with inconsistent start/end specifications

  (a) A Tariff that has one rate with WeeklyBegin=WeeklyEnd=-1, and another with WeeklyBegin = 6, WeeklyEnd = 7 (both with the same Min/Max values)
  (b) A Tariff that has has three rates with hours (0,8), (8,17), (17,24) whereas another has three rates with hours (0,7),(8,20),(21,23). Only one of these specifications can be correct, either with or without overlap, either making use of hour 24 or not.

(6) The default broker makes use of empty fields for e.g. WeeklyBegin when they're not used, all others use the special value -1.

Anyone know which of these tariffs are correct and which aren't? The JavaDoc on Tariff and Rate alone don't answer this, in my eyes.

Cheers,

Markus
Reply | Threaded
Open this post in threaded view
|

Re: Making Sense of Tariffs and Rates

grampajohn
Administrator
markus wrote
I'm currently trying to understand the types of tariffs used by various brokers during the Nuremberg pilots. Looking at the rate structure, I fail to see the semantics of some of them. Here are a few examples:

(1) Fixed = true, Min = 0.0, Max = -2.1, ExpMean = -0.6

This seems to be inconsistent for a fixed tariff. For a fixed tariff, I would expect something like the default broker in the same game published: Fixed = true, Min = Max = ExpMean = -0.5.
For a fixed tariff, the only number that matters is minValue. So the rate here is 0.0. Free power!
(2) Fixed = false, Min = -0.1, Max = 0, ExpMean = 0

This is not inconsistent per se. But, unless the minimum was chosen pathologically and this is really a fixed tariff, the mean will probably fall somewhere other than 0. Is there a mechanism in place that prevents brokers from announcing faulty expectations?
If this is for a consumption tariff, it should fail validation. It's OK in a production tariff, but does not make sense.
(3) Fixed = true, Min = 0, Max = -3.6, ExpMean = -1,1

Is this the right order for Min/Max? Why would a fixed tariff have different Min/Max/ExpMean values?
Those are really big numbers, and again, the min value is 0.0, so the charge/kwh for this one is 0.0.
(4) Fixed = true, Min = Max = ExpMean = 0, NoticeInterval = 1

Can a fixed tariff have a notice interval? Also, the rate is pathological. Although I suppose there's nothing wrong with giving away energy for free as part of an aggressive strategy.
Notice interval is ignored in this case
(5) There appear to be tariffs with inconsistent start/end specifications

  (a) A Tariff that has one rate with WeeklyBegin=WeeklyEnd=-1, and another with WeeklyBegin = 6, WeeklyEnd = 7 (both with the same Min/Max values)
The first one applies all the time; the second is a weekend tariff. Rates are combined in such a way that more specific rates override less specific ones. So this is a valid weekday-weekend combination.
  (b) A Tariff that has has three rates with hours (0,8), (8,17), (17,24) whereas another has three rates with hours (0,7),(8,20),(21,23). Only one of these specifications can be correct, either with or without overlap, either making use of hour 24 or not.
We should be doing a mod 24 on these numbers, but it appears we are not, and I cannot find test cases that exercise these boundary conditions. But I believe the correct form would be 1-24, not 0-23. Given that this is likely to be very confusing to people, I think we should fix it to be 0-23 and do the mod operation to better tolerate misunderstanding. I've created issue #665 to fix this - feel free to add your thoughts.
(6) The default broker makes use of empty fields for e.g. WeeklyBegin when they're not used, all others use the special value -1.
I do not understand this one. These daily and weekly begin/end values are ints, and the "null" value is -1. I looked at a broker log, and the default broker's tariffs do indeed have -1 values for these fields. Where are you seeing this behavior?
Anyone know which of these tariffs are correct and which aren't? The JavaDoc on Tariff and Rate alone don't answer this, in my eyes.
I agree the documentation is inadequate in this area. It's on my list to fix, and it's high priority. We elected to not go into this level of detail in the game specification, but that means the javadoc needs to be very clear on how this is supposed to work. It's not, and I apologize.

Cheers -

John
Reply | Threaded
Open this post in threaded view
|

Re: Making Sense of Tariffs and Rates

markus
Am 12.01.13 16:16, schrieb grampajohn [via Power TAC Developers]:
(6) The default broker makes use of empty fields for e.g. WeeklyBegin when they're not used, all others use the special value -1.
I do not understand this one. These daily and weekly begin/end values are ints, and the "null" value is -1. I looked at a broker log, and the default broker's tariffs do indeed have -1 values for these fields. Where are you seeing this behavior?
Sorry, this one's on me. I was looking at state logs after one processing step instead of the raw originals. What's really happening is that the default broker's and everyone else's tariff creations are logged differently. Usually, a new rate is logged like this:

178459:org.powertac.common.Rate::500241301::new::500241307::-1::-1::0::8::0.0::true::-0.06514981421639458::0.0::0::0.0::0.0

which comes with a full specification for all fields. For the default broker, a rate creation looks like this:

3131:org.powertac.common.Rate::392::new
3131:org.powertac.common.Rate::392::withValue::-0.5
3131:org.powertac.common.Rate::392::setTariffId::391

which is legible and fine, it's just different.

Thanks,

Markus

Reply | Threaded
Open this post in threaded view
|

Re: Making Sense of Tariffs and Rates

grampajohn
Administrator
On 01/14/2013 09:05 AM, markus [via Power TAC Developers] wrote:

> ... Usually, a new rate is logged like this:
>
> 178459:org.powertac.common.Rate::500241301::new::500241307::-1::-1::0::8::0.0::true::-0.06514981421639458::0.0::0::0.0::0.0
>
> which comes with a full specification for all fields. For the default
> broker, a rate creation looks like this:
>
> 3131:org.powertac.common.Rate::392::new
> 3131:org.powertac.common.Rate::392::withValue::-0.5
> 3131:org.powertac.common.Rate::392::setTariffId::391
>
> which is legible and fine, it's just different.

Yes, that's because the state logger sees deserialization differently
from object creation. In fact, constructors are not called as you might
expect during deserialization. It's all done by reflection. Hence the
strange little class common.state.XStreamStateLoggable.

Cheers -

John