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.
For a fixed tariff, the only number that matters is minValue. So the rate here is 0.0. Free power!
If this is for a consumption tariff, it should fail validation. It's OK in a production tariff, but does not make sense.
Those are really big numbers, and again, the min value is 0.0, so the charge/kwh for this one is 0.0.
Notice interval is ignored in this case
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.
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.
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?
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.
Am 12.01.13 16:16, schrieb grampajohn [via Power TAC Developers]:
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: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?
which comes with a full specification for all fields. For the default broker, a rate creation looks like this:
which is legible and fine, it's just different.
On 01/14/2013 09:05 AM, markus [via Power TAC Developers] wrote:
> ... Usually, a new rate is logged like this:
> which comes with a full specification for all fields. For the default
> broker, a rate creation looks like this:
> 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.
|Free forum by Nabble||Edit this page|