RegulationRate

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

RegulationRate

turban
Hi everyone,

I was testing the effect of "RegulationRate"s. But I don't see any evidence in the broker log that the rate has any effect.

this is the code how I create the tariff:
/*Storgae_RR*/
        TariffSpecification specContRR = new TariffSpecification(brokerContext.getBroker(), PowerType.STORAGE);
        Rate rrRate = new Rate();
        rrRate.withValue(marketPrice * 1.4);
        specContRR.addRate(rrRate);
        RegulationRate rr = new RegulationRate();
        RegulationRate rr1 = new RegulationRate();
        rr.withUpRegulationPayment(-marketPrice * 0.8D).withDownRegulationPayment(marketPrice*0.8D).withResponse(RegulationRate.ResponseTime.SECONDS);
        rr1.withUpRegulationPayment(-marketPrice * 0.7D).withDownRegulationPayment(marketPrice*0.7D).withResponse(RegulationRate.ResponseTime.MINUTES);
       
        specContRR.addRate(rr);
        specContRR.addRate(rr1);

I get this in the broker log:  
<tariff-tx id="40391" postedTimeslot="372" txType="CONSUME" customerCount="1" kWh="-41.77519635363427" charge="4.421878477670411" isRegulation="false">
  <broker>maxon16</broker>
  <customerInfo>3708</customerInfo>
  <tariffSpec>200000034</tariffSpec>
</tariff-tx>

Note the  isRegulation="false". I never get a  isRegulation="true". Also I don't see any other message that gives me any information about the actual regualtion.

Am I missing something?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RegulationRate

grampajohn
Administrator
turban wrote
I was testing the effect of "RegulationRate"s. But I don't see any evidence in the broker log that the rate has any effect.
...
Am I missing something?
Yes. The sample broker has a simple example of how this works. When a customer subscribes to a tariff with a RegulationRate, it means the customer is willing to reduce consumption or feed stored energy back to the grid (up-regulation) or to increase consumption (down-regulation) in exchange for compensation. In the case of up-regulation, you pay the customer for the energy provided; for down-regulation, the customer gets the extra energy for a discount and pays you, although you can even pay customers to take the extra energy if you like. That information is in the RegulationRate.

In order to make regulation happen, you must participate in the BalancingMarket by issuing BalancingOrders. Contrary to what the javadoc says, the only purpose of the exerciseRatio is to specify whether a particular order is for up-regulation (exerciseRatio > 0, price normally > 0) or down-regulation (exerciseRatio < 0, price normally < 0). Since the balancing market is cleared using the VCG algorithm, the actual clearing prices will always be at least as 'good' as your bid prices. A BalancingOrder against a particular tariff remains in effect until you issue another BalancingOrder against that same tariff.

So when regulation happens against your BalancingOrder, the market pays you and you pay the customer. The quantities traded are determined by the imbalance in a particular timeslot, by the amount of regulating capacity declared by your subscribed customers, and by the market clearing process.

Does this help?

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

Re: RegulationRate

turban
grampajohn wrote
Yes. The sample broker has a simple example of how this works. When a customer subscribes to a tariff with a RegulationRate, it means the customer is willing to reduce consumption or feed stored energy back to the grid (up-regulation) or to increase consumption (down-regulation) in exchange for compensation. In the case of up-regulation, you pay the customer for the energy provided; for down-regulation, the customer gets the extra energy for a discount and pays you, although you can even pay customers to take the extra energy if you like. That information is in the RegulationRate.

In order to make regulation happen, you must participate in the BalancingMarket by issuing BalancingOrders. Contrary to what the javadoc says, the only purpose of the exerciseRatio is to specify whether a particular order is for up-regulation (exerciseRatio > 0, price normally > 0) or down-regulation (exerciseRatio < 0, price normally < 0). Since the balancing market is cleared using the VCG algorithm, the actual clearing prices will always be at least as 'good' as your bid prices. A BalancingOrder against a particular tariff remains in effect until you issue another BalancingOrder against that same tariff.

So when regulation happens against your BalancingOrder, the market pays you and you pay the customer. The quantities traded are determined by the imbalance in a particular timeslot, by the amount of regulating capacity declared by your subscribed customers, and by the market clearing process.

Does this help?

John
Hi John,

Thanks for your clarification I have two more questions
First question:
This code is from the sample broker issues two BalancingOrders for the same tariff.
                    RegulationRate rr = spec.getRegulationRates().get(0);
                    double up = -rr.getUpRegulationPayment();
                    double down = -rr.getDownRegulationPayment();
                    BalancingOrder bup = new BalancingOrder(brokerContext.getBroker(),
                            spec, 1.0, up);
                    BalancingOrder bdown = new BalancingOrder(brokerContext.getBroker(),
                            spec, -1.0, down);
                    brokerContext.sendMessage(bup);
                    brokerContext.sendMessage(bdown);
You said: “A BalancingOrder against a particular tariff remains in effect until you issue another BalancingOrder against that same tariff.” Can I issue two balancing orders (1 for up- 1 for down-regualtion) if I use RegualtionsRates?

Second question:
The RegulationRate itself has a price and the BalancingOrder also has a price that I am willing to pay or that the customer has to pay. What is the difference between these two prices?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RegulationRate

grampajohn
Administrator
turban wrote
Thanks for your clarification I have two more questions
First question:
This code is from the sample broker issues two BalancingOrders for the same tariff.
                    RegulationRate rr = spec.getRegulationRates().get(0);
                    double up = -rr.getUpRegulationPayment();
                    double down = -rr.getDownRegulationPayment();
                    BalancingOrder bup = new BalancingOrder(brokerContext.getBroker(),
                            spec, 1.0, up);
                    BalancingOrder bdown = new BalancingOrder(brokerContext.getBroker(),
                            spec, -1.0, down);
                    brokerContext.sendMessage(bup);
                    brokerContext.sendMessage(bdown);
You said: “A BalancingOrder against a particular tariff remains in effect until you issue another BalancingOrder against that same tariff.” Can I issue two balancing orders (1 for up- 1 for down-regualtion) if I use RegualtionsRates?
Yes, that is exactly the intent. Typically you want to specify different prices for up-regulation than for down-regulation. In each timeslot, the actual imbalance is either positive or negative, and so only the corresponding BalancingOrders will be considered for clearing -- up-regulation when the overall imbalance is negative (actual demand is higher than actual production plus imports from the wholesale market), and down-regulation when the overall imbalance is positive.
Second question:
The RegulationRate itself has a price and the BalancingOrder also has a price that I am willing to pay or that the customer has to pay. What is the difference between these two prices?
The price in the RegulationRate is the price the customer sees -- that's a transaction between the broker and the customer. The price in the BalancingOrder participates in market clearing; if your BalancingOrder is cleared, then there will be a transaction between the balancing market and the broker at the clearing price. Since the VCG mechanism is incentive-compatible, it makes sense for the prices in your BalancingOrders to match the prices in your RegulationRates -- that way you never miss an opportunity, you never lose money, and in expectation you always win.

Does this help?

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

Re: RegulationRate

turban
Hi, thanks that helped a lot.

I have another Question regarding TariffTransaction and the "isRegulationFlag". I can see the flag in the brokers log. But there is no "getIsRegulation()" method in the "TariffTransaction" class. So I can not check at runtime if a transaction was a regualtion or not.

What am I missing?

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

Re: RegulationRate

grampajohn
Administrator
turban wrote
I have another Question regarding TariffTransaction and the "isRegulationFlag". I can see the flag in the brokers log. But there is no "getIsRegulation()" method in the "TariffTransaction" class. So I can not check at runtime if a transaction was a regulation or not.
Sorry, I slipped up. I added the field and made sure it worked, but I never added the method. Details are in Issue #867. I've re-named the field so the method can be called isRegulation(), added test cases in both common and accounting. Finally, I re-deployed common, the entire server, broker-core, and logtool-core. All had to be re-deployed because the change was in the common module, the bottom of the dependency tree. You would think I would be more careful about that...

So the 1.3.2-SNAPSHOT version is now corrected. To correct the released version, I will have to do a 1.3.2 release. That's enough work that I would prefer to wait a week or two and see if anything else crops up in the meantime. Does this work for you?

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

Re: RegulationRate

turban
I am getting a lot of NoSuchMethodException when Runnign my broker (with the newest snapshot) :

54253 ERROR state.StateLogging: Failed to introspect TariffTransaction
java.lang.NoSuchMethodException: Unknown property 'isRegulation' on class 'class org.powertac.common.TariffTransaction'

is this a problem of my code /configuration or a result of the an error in the commons module?

I also noticed, that the "DistributionReport" class does not have an instance variable"timeslot". Is this intentional? It makes the handling of the report a litte 'messy'.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RegulationRate

grampajohn
Administrator
turban wrote
I am getting a lot of NoSuchMethodException when Runnign my broker (with the newest snapshot) :

54253 ERROR state.StateLogging: Failed to introspect TariffTransaction
java.lang.NoSuchMethodException: Unknown property 'isRegulation' on class 'class org.powertac.common.TariffTransaction'

is this a problem of my code /configuration or a result of the an error in the commons module?
It is probably a configuration problem. The version I deployed a few days ago passes tests that include calls on the isRegulation() method, and the TariffTransaction entries show up correctly in the sample broker's state log. I suspect something is messed up with your pom.xml. It might help if you would send that, but first you might try a trick that is sometimes needed when maven gets mixed up - try clearing out the directory ~/.m2/repository/org/powertac and force it to reload everything.
I also noticed, that the "DistributionReport" class does not have an instance variable"timeslot". Is this intentional? It makes the handling of the report a litte 'messy'.
Yes, I see that. You are correct that there should be a timeslot index in that type. I have created Issue #868 to track this problem. Do you need fix right away? I could get it done and re-deploy later today if it's important. I'll also do a quick check to see if there are other message types that lack a timeslotIndex. In a way, it seems redundant to send the same datum over and over, but I can see that it might make data analysis a bit easier.

Cheers -

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

Re: RegulationRate

Miguel
Hello grampajohn, turban,

I had the same error ( 54253 ERROR state.StateLogging: Failed to introspect TariffTransaction
java.lang.NoSuchMethodException: Unknown property 'isRegulation' on class 'class org.powertac.common.TariffTransaction' ) and I believe that the problem is in the broker-core 1.3.1 release. The broker-core 1.3.1 SNAPSHOT and broker-core 1.3.2-SNAPSHOT works well.

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

Re: RegulationRate

grampajohn
Administrator
Miguel and all -

Miguel wrote
I had the same error ( 54253 ERROR state.StateLogging: Failed to introspect TariffTransaction
java.lang.NoSuchMethodException: Unknown property 'isRegulation' on class 'class org.powertac.common.TariffTransaction' ) and I believe that the problem is in the broker-core 1.3.1 release. The broker-core 1.3.1 SNAPSHOT and broker-core 1.3.2-SNAPSHOT works well.
Yes, that's exactly right. The last 1.3.1-SNAPSHOT version lacked the new regulation field, and so XStream skipped over that part of the xml. That was introduced in the 1.3.1 release, unfortunately without the method needed by the state logger. That's fixed in the current 1.3.2-SNAPSHOT version.

One thing that can cause confusion is that if you are compiling your broker into a jar file and running that, it may not pick up the latest deployed version of the modules. You need to re-build your broker, and your pom.xml needs to depend on server-master version 1.3.2-SNAPSHOT. See the sample-broker pom.xml to see what it should look like. Also, if you have installed local copies of broker-core or common (using mvn install), you may need to clear those out before re-building. On the other hand, if you are working with sources for common or broker-core, you will need to pull down the latest from github, then re-build and install them. Note that to get javadoc generated correctly in a source environment, you need to build common and broker-core as 'mvn clean source:jar install' in order to get integrated javadoc for your broker using 'mvn javadoc:javadoc'.

Does this help?

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

Re: RegulationRate

grampajohn
Administrator
In reply to this post by turban
Tobias and all -
turban wrote
I noticed that the "DistributionReport" class does not have an instance variable "timeslot". Is this intentional? It makes the handling of the report a little 'messy'.
As you know, the qualification round for the 2016 competition starts in a little over a week. I am considering one more release before then, probably on Friday this week. Should I add the timeslot index to the DistributionReport when I do that? Because the common module has already changed since the 1.3.1 release (to add TariffTransaction.isRegulation()), the dependency structure requires that all components be re-released whether or not we make this change.

If I hear no objections before Friday, I will add the timeslot index. You will then need to re-build your brokers in order to see these new data elements.

Thanks in advance for your thoughts.

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

Re: timeslot index in DistributionReport

grampajohn
Administrator
Dear colleagues -

I have deployed an update to common, powertac-server, and broker-core 1.3.2-SNAPSHOT to add id and timeslot fields to the DistributionReport message type, and I made sure it gets logged correctly in the broker's state log. If your pom.xml has a parent clause with server-master 1.3.2-SNAPSHOT, then you should see this update when you re-build your broker.

If I hear no objections, and if no other critical issues arise before tomorrow, then I plan to do a 1.3.2 release by sometime Saturday.

Good luck in the upcoming tournament!

John
Loading...