Problems with TOU Tariffs

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

Problems with TOU Tariffs

lea_jaentgen
Hey everybody,

I'm experiencing some issues using time of use tariffs. The broker is not doing anything, when I run it with TOU Tariff. The Subscriptions and cash will stay at 0. I think it might be due to a wrong set up of the tariffs.

Can you take a look?

TariffSpecification spec = new TariffSpecification(broker.getBroker(), PowerType.CONSUMPTION);

Rate rate1 = new Rate().withDailyBegin(0).withDailyEnd(6).withValue(-0.2);
Rate rate2 = new Rate().withDailyBegin(6).withDailyEnd(21).withValue(-0.5);
Rate rate3 = new Rate().withDailyBegin(21).withDailyEnd(24).withValue(-0.2);

spec.addRate(rate1).addRate(rate2).addRate(rate3);
                               
customerSubscriptions.put(spec, new HashMap<CustomerInfo, CustomerRecord>());
tariffRepo.addSpecification(spec);
broker.sendMessage(spec);



Would this work? If yes, do you have any other ideas on why it might not work? All the other tariffs work fine.

Cheers,

Lea
Reply | Threaded
Open this post in threaded view
|

Re: Problems with TOU Tariffs

grampajohn
Administrator
Hello, Lea -
lea_jaentgen wrote
I'm experiencing some issues using time of use tariffs. The broker is not doing anything, when I run it with TOU Tariff. The Subscriptions and cash will stay at 0. I think it might be due to a wrong set up of the tariffs.
I believe you have raised an exception and not realized it. Have you looked at the logs? The problem is that the hour value runs from 0 to 23. The correct way to specify this tariff would be

Rate rate1 = new Rate().withDailyBegin(6).withDailyEnd(21).withValue(-0.5);
Rate rate2 = new Rate().withDailyBegin(22).withDailyEnd(5).withValue(-0.2);

This would give you 16 hours at -0.5 starting at 6:00, and 8 hours at -0.2 starting at 22:00. Note that you can wrap the times around past midnight, and the times should be read as "the hour starting at x".

However, this error should result in a TariffStatus rather than an exception. I have created Issue #939 to track this problem. I will try to get it fixed before the final round, but it probably won't be until sometime next week at the earliest.

Does this help?

John
Reply | Threaded
Open this post in threaded view
|

Re: Problems with TOU Tariffs

lea_jaentgen
Hi John,

this worked! Thanks so much.
I'm not sure about the Exception, since I don't have the log files anymore.

I was only offering TOU Tariffs, so I guess if they were configured wrongly no customer would subscribe to them. Therefore, I'm not sure if an exception was the reason.

Cheers,

Lea
Reply | Threaded
Open this post in threaded view
|

Re: Problems with TOU Tariffs

grampajohn
Administrator
lea_jaentgen wrote
I was only offering TOU Tariffs, so I guess if they were configured wrongly no customer would subscribe to them. Therefore, I'm not sure if an exception was the reason.
It's very unlikely that the customers ever saw your mis-configured tariffs, because the exception would have prevented them from being published. Your broker can check for this by looking for the PUBLISH tariff transaction. Until that arrives, customers will not have access to your new tariff.

I'm glad it's working for you now. Best of luck in the competition.

John
Reply | Threaded
Open this post in threaded view
|

Update changes behavior for TOU Tariffs with bogus Rates

grampajohn
Administrator
In reply to this post by lea_jaentgen
Dear colleagues -

As a result of fixing Issue #939 there is a slight change in behavior when composing rates with daily and/or weekly start and end times. Previously, an out-of-range value for the day of week or hour of day would not generate an error in the broker, but would raise an exception in the server. In a tournament situation this is quite disruptive.

The behavior now is that out-of-range values are not accepted as input when composing the Rates, which means the fluent setters for those values can return null, after logging an ERROR to the trace log. If the bad value was not the last setter in the chain, you can now get a NullPointerException in the broker in the code that's composing the rates. If you see this, take a look in the log to see what the offending value was. If the bad value was the last setter in a chain, then your broker may not crash, but the ERROR message will be written to the trace log, and the Rate will fail the isValid() test when it's unpacked in the server, and most likely the tariff will be rejected (you will get an invalidTariff back in the TariffStatus message). Of course, you can avoid this by checking validity of Rate instances before sending a new tariff to the server. Validity tests are run when you create and init() a Tariff; the return value of Tariff.init() is true just in case all the Rates are valid.

I believe the updated behavior is much better than the original behavior, because bad input is caught in the broker rather than in the server. If you disagree, I would be interested in your thoughts. In general, you should always check for ERROR entries in the trace log the first few times you run your broker after you've made a change.

As always, please let us know if you encounter problems with this.

John
Reply | Threaded
Open this post in threaded view
|

Re: Update changes behavior for TOU Tariffs with bogus Rates

susobhang70
This post was updated on .
Hello John,

I apologize to bring up such an old thread, but it seemed the most apt one considering the issue at hand. I'm presuming this bug was fixed, and there has been no update on the way how TOU Tariffs are designed?

If that is true, it seems the issue has not not been fixed completely. I can confirm from the logs that such tariffs are being offered and do get published in the market. For example, in one of the logs, I managed to find a tariff like -

    <rate id="401221710" tariffId="401221709" weeklyBegin="-1" weeklyEnd="-1" dailyBegin="0" dailyEnd="1" tierThreshold="0.0" fixed="true" minValue="-0.1141484344563597" maxValue="0.0" noticeInterval="0" expectedMean="0.0" maxCurtailment="0.0">
      <rateHistory/>
    </rate>
    <rate id="401221712" tariffId="401221709" weeklyBegin="-1" weeklyEnd="-1" dailyBegin="1" dailyEnd="2" tierThreshold="0.0" fixed="true" minValue="-0.11460203727326981" maxValue="0.0" noticeInterval="0" expectedMean="0.0" maxCurtailment="0.0">
      <rateHistory/>
    </rate>

As one can see, dailyEnd from one rate overlaps with dailyBegin of the next rate - which is precisely highlighted as the issue of the thread. Please let me know if I've missed something.

EDIT: Overlapping was not the main issue of this thread, but John did highlight the correct way to offer a TOU Tariff Rate, and this looks to be different from that. I believe there should be one set precedent on how TOU Tariff Rates are offered - either overlapping is allowed, or it is not (raises exception or something).

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

Re: Update changes behavior for TOU Tariffs with bogus Rates

Porag
I believe the problem was not overlapping, it was for hour '24' as there are no such hours! Valid hours are [0~23].
Reply | Threaded
Open this post in threaded view
|

Re: Update changes behavior for TOU Tariffs with bogus Rates

susobhang70
Hi Porag,

You're correct - the original thread indeed was about the '24' not being valid.

On the other hand, overlapping is the issue I'm trying to point out. Given the way John mentioned about giving out TOU tariffs, which of these rates get applied for which hour - given that the end and start times overlap? This is absolutely not clear.

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

Re: Update changes behavior for TOU Tariffs with bogus Rates

grampajohn
Administrator
In reply to this post by susobhang70
Hello, Susobhan and all -
susobhang70 wrote
As one can see, dailyEnd from one rate overlaps with dailyBegin of the next rate - which is precisely highlighted as the issue of the thread. Please let me know if I've missed something.
This is confusing, I admit, but it's not an error. The tariff market does not check for overlaps, it just checks for gaps. What happens is that the Rates are sorted by start time and tier, and their values are entered into a big map. Rates that appear later in the sorted list may overwrite earlier ones. The only check is to ensure that there are no coverage gaps. So this tariff specification is valid, and the second rate applies during hours 1 and 2. If you want to see what the value is for a particular hour, you can make a Tariff from the TariffSpecification, and call tariff.init(). This will run the analysis and fill in the array. You can then call tariff.getUsageCharge(when, kwh, cumulativeUsage) to see what the value is for a particular time of day or week.

Perhaps this is a bug, but I hesitate to fix it, especially close to a competition, because it may break some brokers. Perhaps it is worth addressing in the future?

John