Announcement: 2016 Power TAC specification and server 1.3.1-SNAPSHOT

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

Announcement: 2016 Power TAC specification and server 1.3.1-SNAPSHOT

grampajohn
Administrator
Dear colleagues -

Today we finalized and published the 2016 Power TAC specification. The primary change is to the assessment of distribution costs. Prior to this version, brokers were charged for transported energy. This provides no incentive to manage peak demand, and is a poor model of real-world costs. Starting with version 1.3.1, brokers will pay for customer connections and for their contributions to peak-demand events. In addition, brokers will see higher costs for balancing services, eliminating the possibility of a perverse incentive to carry a "short" market position into the current timeslot.

We have also deployed the first 1.3.1-SNAPSHOT of the server and broker-core, and have pushed a version of sample-broker that handles the new CapacityTransaction. These are sent once/week (every 168 timeslots) when peak-demand assessment is run. All brokers will receive them even if there are no charges, allowing brokers to track the peak-threshold value. The top-level server-distribution module 1.3.1-SNAPSHOT is available for download from github.

As always, please let us know if you have questions or concerns, or if you run into problems with this new version. We look forward to a vigorous competition this year.

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

Re: Announcement: 2016 Power TAC specification and server 1.3.1-SNAPSHOT

Ansel
Hi,

We have a problem with the server 1.3.1. When we run our broker and AgentUDE15 then the wholesale market per time slot scores shows our results as the results of AgentUDE15. Also when we refresh (F5) the browser then our broker and AgentUDE15 swap the results.

You has any idea of this behavior.

We have the screens that show this rare behavior.

https://www.dropbox.com/s/xbbyzg94g1ieosb/Screenshot%20from%202016-01-22%2009%3A26%3A46.png?dl=0
https://www.dropbox.com/s/dfvogtr014pfwvr/Screenshot%20from%202016-01-22%2009%3A26%3A57.png?dl=0

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

Re: Announcement: 2016 Power TAC specification and server 1.3.1-SNAPSHOT

grampajohn
Administrator
Hello, Ansel -

Ansel wrote
We have a problem with the server 1.3.1. When we run our broker and AgentUDE15 then the wholesale market per time slot scores shows our results as the results of AgentUDE15. Also when we refresh (F5) the browser then our broker and AgentUDE15 swap the results.

You has any idea of this behavior.
This is indeed strange. However, we are hard at work on a completely new Visualizer component, which should be available in a few weeks. I would be much more concerned if the log files were corrupted.

You can help our progress on the new visualizer if you respond to the query from Jurica last October on what folks would like to see in it.

Thanks!

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

Re: Announcement: 2016 Power TAC specification and server 1.3.1-SNAPSHOT

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

Today I deployed an update to the server and broker-core version 1.3.1-SNAPSHOT. If you are using the snapshot version without locally-built sources, you will see this change the next time you run the server or re-build your broker (assuming your broker uses the broker-core module).

The principal change is the addition of 1200 kW battery capacity that will subscribe to tariffs that include RegulationRates and provide both up-regulation and down-regulation based on broker balancing orders. There are 30 instances of the battery type, each with a 40kW charger, so there should be plenty of capacity to go around if multiple brokers offer competitive tariffs for them. Note that the usage profiles they use for tariff evaluation are all zeros, and they never consume or produce energy outside the scope of a balancing order, so they really don't care about the price of energy, only the prices for regulation. They all start with a stored charge of zero, so they can only down-regulate until they have some charge, and their per-unit capacity is about 90 kWh. There's some charging inefficiency and some self-discharge, so if you do it slowly a battery will absorb more than 90 kWh. This means they will work best when overall balance is near zero so they can alternate between up-regulation and down-regulation. This deployment also adds the BATTERY_STORAGE PowerType and fixes a minor startup bug that you have probably not noticed.

The Sample Broker now publishes a BATTERY_STORAGE tariff that you may want to inspect for an example of how to use the batteries.

We are close to release on version 1.3.1. Most of the remaining issues are related to the visualizer, which is about to be replaced. Other than that and a couple minor bugfixes, there are only two items near the top of our to-do list that we might find time for: (1) an electric-vehicle population model, to allow EV populations in the 10^4 range or higher rather than the current population in the range of 10^2; and (2) fixing several of the population models to handle regulation rates. Neither of these is trivial, and so may not get done in time for this year's competition.

If there is an issue or feature that you would very much like to see addressed for the 2016 competition, please let us know ASAP. At this point our focus is on stability, and so new features beyond the ones we are already looking at may be hard to justify.

We look forward to an interesting tournament.

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

Re: Announcement: 2016 Power TAC specification and server 1.3.1-SNAPSHOT

Ansel
In reply to this post by grampajohn
Hi John and Wolf,

I am reviewing the Market-based balancing example of the specification for the 2016 competition, pages 27 and 28. But I do not understand the paragraph 3 page 28 "To compute the imbalance portion of the payment ...". A new broker named A4 appear in that paragraph. I am trying to reproduce the 2nd payment without success.

Thanks in advance,

Ansel
COLDTeam



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

Re: Announcement: 2016 Power TAC specification and server 1.3.1-SNAPSHOT

grampajohn
Administrator
Hello, Ansel -
Ansel wrote
I am reviewing the Market-based balancing example of the specification for the 2016 competition, pages 27 and 28. But I do not understand the paragraph 3 page 28 "To compute the imbalance portion of the payment ...". A new broker named A4 appear in that paragraph. I am trying to reproduce the 2nd payment without success.
Wow! That looks like a typo that's been there for at least two years. I believe A4 should have been A3. That's the one in this example with no balancing orders. I suspect an early draft had the brokers numbered 1-4 rather than 0-3.

As you might expect, this exact problem is one of the test cases in StaticSettlementProcessorTest in the balancing-market module. So this is the result produced by the code. If you look at the trace log from testing or from a sim where there are active balancing orders, the p2 value is the VCG payment, while the p1 value is the "second" payment. Here's a line reporting these values from a test run of the 1.3.1 server and the sample-broker:
131785 INFO  balancemkt.SettlementProcessor: DU static settlement <broker(p2,p1)>: default broker(-0.0,0.0) Sample(29.238963883805514,506.8485680493882)
and here's the corresponding line from the test.trace file that gets generated by that problem when running unit tests on the balancing-market module:
661 INFO  balancemkt.SettlementProcessor: DU static settlement <broker(p2,p1)>: A0(0.904,0.0) A1(1.3802,5.056444444444445) A2(0.5248,-15.2) A3(-0.0,-17.697555555555557)
The debug info from working this problem in the unit test might help you see what's happening.

I readily acknowledge that this is not simple stuff. It took me several false starts to get my head wrapped around it, and I always have to spend a bit of time getting back up to speed whenever I look at it again.

Please don't hesitate to follow up if you are still confused.

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

Re: Announcement: 2016 Power TAC specification and server 1.3.1-SNAPSHOT

serkan
In MarketManagerService and handleMessage (DistributionTransaction dt)

dt.getKWh() always returns zero whereas dt.getCharge() works fine. I think this is important since many things in the broker rely on this information.

Additional note:
Please have a look at sample broker in github. In MarketManagerService, I think you forgot to change the description and the parameter of capacity transaction. It is currently written as (CapacityTransaction dt) instead of, e.g. (CapacityTransaction ct).
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Announcement: 2016 Power TAC specification and server 1.3.1-SNAPSHOT

grampajohn
Administrator
Hello, Serkan -
serkan wrote
In MarketManagerService and handleMessage (DistributionTransaction dt)

dt.getKWh() always returns zero whereas dt.getCharge() works fine. I think this is important since many things in the broker rely on this information.
This is intentional. That's because the energy transport fee has been reduced to zero, replaced by the per-meter fee and the peak-demand assessments. So dt.getKWh is now zero, reflecting the fact that it is no longer part of the accounting, while dt.getCharge() is now the sum of the transport fee (which is always zero) and the per-meter fee. Does this make sense?
Additional note:
Please have a look at sample broker in github. In MarketManagerService, I think you forgot to change the description and the parameter of capacity transaction. It is currently written as (CapacityTransaction dt) instead of, e.g. (CapacityTransaction ct).
Thanks for spotting this - obviously a quick copy-paste that never got finished. I've created Issue #865 to track this problem.

Cheers -

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

Re: Announcement: 2016 Power TAC specification and server 1.3.1-SNAPSHOT

serkan
Thanks for the answer.

Another issue: I see a repeated error in broker's trace logs

<tariff-tx id="13009" postedTimeslot="362" txType="CONSUME" customerCount="1" kWh="-0.0" charge="0.0" isRegulation="false">
  <broker>AgentUDE</broker>
  <customerInfo>4283</customerInfo>
  <tariffSpec>200000003</tariffSpec>
</tariff-tx>
16870 ERROR state.StateLogging: Failed to introspect TariffTransaction
java.lang.NoSuchMethodException: Unknown property 'isRegulation' on class 'class org.powertac.common.TariffTransaction'
	at org.apache.commons.beanutils.PropertyUtilsBean.getSimpleProperty(PropertyUtilsBean.java:1257) ~[commons-beanutils-1.9.2.jar:1.9.2]
	at org.apache.commons.beanutils.PropertyUtils.getSimpleProperty(PropertyUtils.java:649) ~[commons-beanutils-1.9.2.jar:1.9.2]
	at org.powertac.common.state.StateLogging.collectProperties(StateLogging.java:113) [broker-core-1.3.1.jar:1.3.1]
	at org.powertac.common.state.StateLogging.newstate(StateLogging.java:95) [broker-core-1.3.1.jar:1.3.1]
	at org.powertac.common.state.XStreamStateLoggable.readResolve(XStreamStateLoggable.java:6) [broker-core-1.3.1.jar:1.3.1]
	at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source) ~[?:?]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_77]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_77]
	at com.thoughtworks.xstream.core.util.SerializationMembers.callReadResolve(SerializationMembers.java:76) [xstream-1.4.8.jar:1.4.8]
	at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:264) [xstream-1.4.8.jar:1.4.8]
	at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72) [xstream-1.4.8.jar:1.4.8]
	at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:65) [xstream-1.4.8.jar:1.4.8]
	at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:66) [xstream-1.4.8.jar:1.4.8]
	at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:50) [xstream-1.4.8.jar:1.4.8]
	at com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:134) [xstream-1.4.8.jar:1.4.8]
	at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.unmarshal(AbstractTreeMarshallingStrategy.java:32) [xstream-1.4.8.jar:1.4.8]
	at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1206) [xstream-1.4.8.jar:1.4.8]
	at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1190) [xstream-1.4.8.jar:1.4.8]
	at com.thoughtworks.xstream.XStream.fromXML(XStream.java:1061) [xstream-1.4.8.jar:1.4.8]
	at com.thoughtworks.xstream.XStream.fromXML(XStream.java:1052) [xstream-1.4.8.jar:1.4.8]
	at org.powertac.common.XMLMessageConverter.fromXML(XMLMessageConverter.java:93) [broker-core-1.3.1.jar:1.3.1]
	at org.powertac.samplebroker.core.BrokerMessageReceiver.onMessage(BrokerMessageReceiver.java:83) [broker-core-1.3.1.jar:1.3.1]
	at org.powertac.samplebroker.core.BrokerMessageReceiver.onMessage(BrokerMessageReceiver.java:74) [broker-core-1.3.1.jar:1.3.1]
	at org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:746) [spring-jms-4.2.3.RELEASE.jar:4.2.3.RELEASE]
	at org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:684) [spring-jms-4.2.3.RELEASE.jar:4.2.3.RELEASE]
	at org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:651) [spring-jms-4.2.3.RELEASE.jar:4.2.3.RELEASE]
	at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:315) [spring-jms-4.2.3.RELEASE.jar:4.2.3.RELEASE]
	at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:253) [spring-jms-4.2.3.RELEASE.jar:4.2.3.RELEASE]
	at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1150) [spring-jms-4.2.3.RELEASE.jar:4.2.3.RELEASE]
	at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:1044) [spring-jms-4.2.3.RELEASE.jar:4.2.3.RELEASE]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:1.8.0_77]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:1.8.0_77]
	at java.lang.Thread.run(Thread.java:745) [?:1.8.0_77]
16871 INFO  core.BrokerMessageReceiver: onMessage(String) - received message:
<tariff-tx id="13012" postedTimeslot="362" txType="CONSUME" customerCount="1" kWh="-0.0" charge="0.0" isRegulation="false">
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Announcement: 2016 Power TAC specification and server 1.3.1-SNAPSHOT

grampajohn
Administrator
Serkan -

serkan wrote
Another issue: I see a repeated error in broker's trace logs
This looks like a broker that's built with an old version of common receiving messages from the new server. I tested for backward-compatibility, but apparently I did not go backward far enough. My suspicion is that this can happen only for incoming messages that extend common.state.XStreamStateLoggable and that have added fields, such as the new isRegulation field in TariffTransaction. I added that field to address Issue #862 and I failed to anticipate this problem. Generally, the XStream decoder ignores unused fields, and supplies defaults for missing fields, on the receiving end. But the interaction with state logging overrides this relatively benign situation, forcing an exact match in the case of added fields.

I have created Issue #866 to track this problem, and I'm open to suggestions about how to fix it.

I apologize for the mess you've discovered. It should be easy enough to re-build brokers with the new common module (or the latest broker-core, which you get by updating your pom.xml to call for broker-core version 1.3.1), but that only works if you have the source. As a result, older brokers distributed as jar files probably cannot be used with the 1.3.1 server.

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

Re: Announcement: 2016 Power TAC specification and server 1.3.1-SNAPSHOT

grampajohn
Administrator
Serkan -
grampajohn wrote
serkan wrote
Another issue: I see a repeated error in broker's trace logs
This looks like a broker that's built with an old version of common receiving messages from the new server. I tested for backward-compatibility, but apparently I did not go backward far enough. ...
I just tried running a 1.2.0 broker with the new server, and it works fine. No errors, not exceptions. I would very much like to understand exactly how you got the errors you observed, because I now doubt that it's due to using an older broker. Even if you have resolved the problem yourself, I would like to be able to reproduce it.

Thanks.

John
Loading...