Need input on a backward-compatibility issue

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Need input on a backward-compatibility issue

grampajohn
Administrator
Dear colleagues -

I am working issue #862, which points out that brokers cannot easily tell exactly which customers are participating in regulation in response to the broker's balancing orders. That's because currently up-regulation by a customer shows up as a PRODUCE tariff transaction, while down-regulation shows up as a CONSUME tariff transaction. At this point, all customers that can participate in balancing orders subscribe to either consumption or storage tariffs, and so seeing a PRODUCE transaction on a consumption tariff is a clue that up-regulation is happening, while for a pure storage tariff the only PRODUCE or CONSUME transactions will be the result of either balancing actions or economic controls. For down-regulation, a customer might be named in two CONSUME transactions in the same timeslot, with different prices. I understand that this is confusing, and for that I apologize.

My proposal to fix this is to introduce two new transaction types, UP_REGULATION and DOWN_REGULATION. These would be issued in the case of balancing controls, or in the case of broker-ordered curtailment. As far as I know, prior to 2016 there was only one broker using balancing orders, and I don't believe I've seen a case of a broker using direct curtailment through economic controls. On the other hand, I assume that many of you are looking at regulation and curtailment to manage balancing and peak-demand costs. If so, you have probably discovered that it's hard to keep track of the actual customer responses to these actions.

I am also aware that some of you have probably written analysis code that pulls out PRODUCE and CONSUME transactions. Such code would presumably need to be updated to also handle the regulation transactions for future tournaments if we make this change. Note that the pom version information now shows up in the log files, so your analysis code would be able to determine whether it was looking at an old log or a newer one.

So my question for broker developers is whether this change would be desirable or not. I know it's a bit late, but I only discovered the problem a few days ago while looking at broker logs, trying to distinguish normal production and consumption transactions from regulation transactions. It's not too hard to do that in the server if you are willing to do some text analysis on the trace log, but it's not easy from the state log. I cannot see a way to do it in the broker.

If anyone objects in the next week or so, I will try to find another way to solve this problem. Any suggestions would be more than welcome. On the other hand, if you agree, it will not be difficult to implement my suggested approach; I should be able to do it in a few days. There are probably three server modules that would need to be updated, along with some tests.

As always, your suggestions are more than welcome.

John
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need input on a backward-compatibility issue

serkan
grampajohn wrote
...
On the other hand, if you agree, it will not be difficult to implement my suggested approach; I should be able to do it in a few days. There are probably three server modules that would need to be updated, along with some tests.
I would really appreciate if you could do that as I plan to use storage customers.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need input on a backward-compatibility issue

Ansel
In reply to this post by grampajohn
Hi John

Although the tournament is very close, any proposal to facilitate balance strategies is welcome.

However, I think for the 2017 tournament (with more time), it should rethink the structure of "Power Types - Tariff publication" as it is very rigid. To give just one example, suppose you want to publish a single tariff that allows that two subtypes of consumers can subscribe but not a third subtype of consumers. Today I can publish a tariff for a subtype but I can not publish a single tariff  for both at once. At least, I have not been able to achieve it.


Ansel,
COLD Team
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need input on a backward-compatibility issue

grampajohn
Administrator
Ansel wrote
Although the tournament is very close, any proposal to facilitate balance strategies is welcome.

However, I think for the 2017 tournament (with more time), it should rethink the structure of "Power Types - Tariff publication" as it is very rigid. To give just one example, suppose you want to publish a single tariff that allows that two subtypes of consumers can subscribe but not a third subtype of consumers. Today I can publish a tariff for a subtype but I can not publish a single tariff  for both at once. At least, I have not been able to achieve it.
Yes, this is a conceptual issue I've been struggling with. There is also the problem that you cannot define a tariff for paired PowerTypes. For example, there's no way to represent a "net metering" tariff for a household with solar. Any ideas on how to do this would be more than welcome. But your suggestion is a little different, so perhaps it will open up a way forward. Thanks!

John
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need input on a backward-compatibility issue

Wolf
Administrator
In reply to this post by Ansel
Hi Ansel,

Great that you are planning to participate in Power TAC 2016 again! Could you please register for the tournament now:


Thanks,

Wolf

On 13 Apr 2016, at 17:08, Ansel [via Power TAC Developers] <[hidden email]> wrote:

Hi John

Although the tournament is very close, any proposal to facilitate balance strategies is welcome.

However, I think for the 2017 tournament (with more time), it should rethink the structure of "Power Types - Tariff publication" as it is very rigid. To give just one example, suppose you want to publish a single tariff that allows that two subtypes of consumers can subscribe but not a third subtype of consumers. Today I can publish a tariff for a subtype but I can not publish a single tariff  for both at once. At least, I have not been able to achieve it.


Ansel,
COLD Team


If you reply to this email, your message will be added to the discussion below:
http://power-tac-developers.975333.n3.nabble.com/Need-input-on-a-backward-compatibility-issue-tp4026157p4026163.html
To start a new topic under Power TAC Developers, email [hidden email]
To unsubscribe from Power TAC Developers, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need input on a backward-compatibility issue

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

Today I pushed and deployed a fix for Issue #862, and brokers can now distinguish between "ordinary" tariff transactions and those that represent regulating energy. Rather than add additional Types to the TariffTransaction, I added a boolean flag isRegulation. If this flag is true, then a CONSUME tx represents down-regulation, while a PRODUCE tx represents up-regulation.

If you want your broker to see this flag, it's enough to re-build it, since the deployed common-1.3.1-SNAPSHOT includes it. If you don't re-build your broker, the flag will not be processed from the incoming xml messages. I've tested both scenarios.

As always, please let me know if you have questions or encounter problems with this.

Cheers -

John
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need input on a backward-compatibility issue

serkan
Dear John,

I have seen a problem with the "BalancingOrder". It seems that the exercise ratio has no effect. Whatever I set to the exercise ratio, batteries charge or discharge in full capacity. Is that normal?

Secondly, I am trying to run some "economic control events" in the broker for the next time slot. I can see in the broker and server logs that the message is delivered. However, server ignores the orders. Am I missing something here?

Best regards,
Serkan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need input on a backward-compatibility issue

grampajohn
Administrator
Serkan and all --
serkan wrote
I have seen a problem with the "BalancingOrder". It seems that the exercise ratio has no effect. Whatever I set to the exercise ratio, batteries charge or discharge in full capacity. Is that normal?
Thanks for spotting this. It looks like documentation I wrote is incorrect and causing confusion.

When we were first designing this feature, we started with the BalancingOrder, and wrote the javadoc. But once we got to the customer side, we decided that the exercise ratio was really quite useless, because the customers are advertising how much regulation they are willing to provide in each timeslot. So yes, the exercise ratio is ignored, except to determine whether a given BalancingOrder can be used for up-regulation (exerciseRatio > 0) or for down-regulation (exerciseRatio < 0). Current customers also ignore whether the exercise ratio r is 0 < r <= 1 (curtailment) or 1 < r <=2 (battery discharge). That's mostly because the RegulationRate does not (currently) allow you to set different prices for those cases anyway. Also, contrary to what the javadoc says, a Balancing Order remains in effect until a different BalancingOrder for the same tariff is sent. You don't need to re-send it in each timeslot.
Secondly, I am trying to run some "economic control events" in the broker for the next time slot. I can see in the broker and server logs that the message is delivered. However, server ignores the orders. Am I missing something here?
I assume the ECO instances are for future timeslots, that they are against tariffs for INTERRUPTIBLE_CONSUMPTION that have active subscriptions, and that you are seeing no error messages in the server trace log? If that's true, they should work. I would be willing to inspect a server log where this is happening and see if I can see what's wrong. It wold be best if you post the trace log and state log somewhere and send me a link.

Again, I apologize for the confusion over the exercise ratio in the balancing order.

John
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need input on a backward-compatibility issue

serkan
Thank you for the clarification.

I got the point with balancing orders.

Regarding the ECO instances, I want to control batteries just before the current time slot (instead of giving that control to DU). After all, I would like to see their consumption or production activities just like households and local producers.

My intention is to use them as a buffer to reduce my wholesale cost and to have some flexibility. Are those instances for only interruptibles or may I also control batteries?

Best,
Serkan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need input on a backward-compatibility issue

grampajohn
Administrator
Hello, Serkan -
serkan wrote
Regarding the ECO instances, I want to control batteries just before the current time slot (instead of giving that control to DU). After all, I would like to see their consumption or production activities just like households and local producers.

My intention is to use them as a buffer to reduce my wholesale cost and to have some flexibility. Are those instances for only interruptibles or may I also control batteries?
ECO will not do anything with batteries, because they don't "consume" at all. All they do is offer regulation capacity, and the only way to use them is through BalancingOrders. If they are completely discharged they won't offer up-regulation capacity, and if they are completely charged they won't offer down-regulation capacity. On the other hand, many of the household models will subscribe to (appropriately priced) INTERRUPTIBLE_CONSUMPTION tariffs, and should respond correctly to ECOs

Does this help?

John
Loading...