Release history prior to version 1.0.0:
- 1 Power TAC server, sample broker framework, and game visualizer, version 0.6.3, December 2012
- 2 Power TAC server version 0.6.2, September 2012
- 3 Power TAC server, sample broker framework, and game visualizer, version 0.6.1, July 2012
- 4 Power TAC server version 0.5.1, 7 May 2012
- 5 Power TAC server version 0.5.0, April 2012
- 6 Power TAC server version 0.2.0, February 2012
- 7 Power TAC server version 0.1.0, December 2011
Power TAC server, sample broker framework, and game visualizer, version 0.6.3, December 2012
This is the final release in the 0.6 series that was used in the 2012 competitions. There are several changes affecting the sim server and brokers, most of them focused on stability and validation of broker-server interactions.
Server release notes
- Stability improvements, including
- Improve interaction between sim and tournament scheduler (issue #575).
- Fail gracefully when boot-data file is not found (issue #535).
- Fix visualizer initialization sequence (issue #611).
- Fix a serious performance problem in the JMS interactions among brokers, the sim server, and the visualizer (issue #629).
- Clean up properly when game is aborted by tournament scheduler (issue #619).
- Fix customer faults (issues #630, #631, #649).
- Fix a race condition that caused clock sync errors when the java process was stalled (issue #519).
- Clean up visualizer faults (issues #605, #634).
- Remove dead code related to PluginConfig abstraction (issue #528).
- Close a window in tariff revocation processing (issue #618).
- Clean up customer tariff evaluation (issues #620, #621, #626, #633, #650).
- Fix an accounting error with variable-rate tariffs (issue #627).
- Add validation rules to reject badly-formed tariff specifications (issues #624, #625, #640).
- Correct the weather forecasts, which were not tracking weather reports correctly (issue #645).
- Add command-line option to allow re-use of random sequences from previous games (issue #648).
Sample broker release notes
- Broker now bails from stalled games (issue https://github.com/powertac/powertac-server/issues/623 #623). The default setting is two minutes of inactivity. Note that this can be somewhat annoying for server developers, since the broker will bail if you put a breakpoint in the server. Also, those experimenting with using pause-mode to enable user interaction with brokers will almost certainly want to disable this feature or set the timeout much longer for all brokers in the sim.
- It is now easy to package up a binary-only version of a broker, to allow sharing broker implementations without sharing sources (issue #652). It is described in the updated README file.
Most of the outstanding issues are related to the visualizer and to the format of the state log, which is unnecessarily difficult to parse in a few areas. There will be some changes in the state log format for version 1.0, but they will require changes in the common module, which will in turn necessitate re-compilation of brokers, and may invalidate some existing log-parsing tools.
Power TAC server version 0.6.2, September 2012
This is a point release that fixes two problems with 0.6.1. The first is a correction to the tariff evaluation logic in the customer models, and the second is an update to the DU balancing market that correctly handles a non-zero slope in the cost function of the external "regulating market". The result is that the cost of imbalance is a fairly noticeable function of the size of the imbalance (default is .01/10 MWh), and that a broker can benefit from being on the "good side" of the overall imbalance. So if the overall imbalance is positive (surplus power), then a broker with an individual negative imbalance is better off than it would be if the overall imbalance were negative.
This release does not change the common or server-master modules, so there is no need to recompile brokers.
Power TAC server, sample broker framework, and game visualizer, version 0.6.1, July 2012
This release is focused on stability rather than functionality, especially stability in a multi-game tournament situation. The only significant functional changes are in the operation of the balancing market, which should effectively discourage running large current-timeslot deficits, and in the tariff-evaluation behavior of the customer models, which will discourage excessive periodic charges in tariff offerings. It includes an updated server, broker framework, and game visualizer, and works with an updated tournament manager.
The tournament manager is not formally released at this point, but we believe it is stable and performs correctly. Although there is some documentation on setting it up, it is incomplete and fairly complex, and it requires several server machines dedicated to it in order to do anything useful.
In addition to the functional changes, there have been some API changes and a thorough re-working of the interactions among brokers, simulation servers, visualizers, and the tournament scheduler at the beginning of each game. Brokers and visualizers no longer create queues on the simulation servers; rather, the servers create all the queues. Queue names are generated by the tournament scheduler, and provided to both brokers and visualizers when they log in.
Changes to the simulation server in this release include:
- Wind data in the weather reports are interpolated in cases of missing data (Issue #536). This should make the output of wind turbines more predictable.
- Customer models do a better job of evaluating tariff offerings, especially when periodic payments are included (Issue #556).
- The simulator does a better job validating and interpreting broker tariff offers (Issue #557).
- The trace log files are somewhat smaller, partly because the xml messages are not included, and partly because most unsuccessful broker and visualizer logins are invisible to the server and therefore are not logged (Issue #560).
- Processing of tariff revocations has been refactored and improved, and customers are no longer able to subscribe to or use power against revoked tariffs once the revocation processing is complete. But revocations are processed at the end of timeslot processing, so customers can use power for at most one further timeslot after a broker has sent the revoke message (Issue #565).
- Brokers can no longer re-use the ID values of revoked tariffs. All tariff specifications are now rejected if they do not have unique ID values (Issue #567).
- The balancing market has been updated in two ways. First, the marginal cost of imbalance increases as the size of the imbalance increases (Issue #568); and second, the imbalance penalties can be reduced substantially with balancing orders, and in cases where a broker is on the "good" side of the imbalance (in surplus when the market has a shortage, and in deficit when the market has a surplus) (Issue #593).
Changes to the sample broker framework include:
- The broker framework now runs multiple sessions without need of an external shell script (Issue #561). The command-line interface allows specification of number of sessions (games) or the length of time to keep trying to log in to a tournament. This is accomplished by a complete re-load of the Spring context, and so does not depend on careful management of data structures.
- The broker login protocol for both tournaments and individual simulations has changed (Issue #574). Specifically, brokers are no longer permitted to create queues in the server. Instead, in a development situation the queue name is the broker's username (although this can be overridden with command-line arguments for testing), and in a tournament situation both the broker and simulator are given the queue names as part of the game setup by the tournament manager.
In addition to a number of small improvements, changes to the game visualizer include:
- Customers and PowerTypes are represented much more clearly (Issue #525), and power producers are listed separately from consumers.
- There is much more detail on the wholesale power market (Issue #530), including a history of spot prices, and the leadtime-cost curve for each timeslot.
- The interaction of the visualizers with the tournament manager and simulation servers has been completely refactored and tested (Issue #576).
There remain a few annoying, mostly cosmetic issues, that have not yet been addressed, including:
- Market transactions are posted sooner than they should be, causing a slight distortion of a Broker's cash position (Issue #474).
- The user interactions in the Customer and Broker panels of the visualizer do not always work as expected (Issues #570, #602, and #603).
- The format of the simulation state logs is a bit awkward in places. See for example Issues #539 and #541.
Power TAC server version 0.5.1, 7 May 2012
This is a bugfix update of 0.5.0. Specifically, issue #531 is fixed, so the balancing market should work correctly without producing NaN values. The download package is available on github. The sample broker is unmodified, and remains at version 0.5.0.
Power TAC server version 0.5.0, April 2012
As with previous releases, the server is distributed in the form of a small directory called "server-distribution" that contains a README.txt file, a sample server configuration file, and a maven pom.xml file. Detailed instructions for configuring and running the server are in the README.txt file.
The sample broker implementation is also updated for this release.
This release is feature-complete for the 2012 international competition. It includes a web-based front-end for controlling and viewing simulations, several new features, and a number of bugfixes. New features include:
- The Visualizer, a web-based front-end that lets you set up and start games, and then watch them.
- Controllable capacity in customer models, indicated by a PowerType of INTERRUPTIBLE_CONSUMPTION, and supported by new representation including
- Customers that support interruption will generally shift their demand to the subsequent timeslot, on in some cases will spread the shift out over a couple of timeslots.
- EconomicControlEvents that allow a broker to curtail some portion of the power demand for a specific tariff over a specified timeslot,
- BalancingOrders that allow a broker to offer some portion of the customer demand for a specific tariff to the DU to be used to offset supply-demand imbalances. Brokers are paid when their BalancingOrders are exercised according to the scheme described in Section 6.2.3 of the game specification.
- BalancingControlEvents notify brokers when their BalancingOrders are exercised.
- A Rate for a Tariff with a PowerType of INTERRUPTIBLE_CONSUMPTION can specify the maximum proportion of the customer's offered load that can be curtailed in a given timeslot.
- Broker login is much more forgiving - you can start brokers before the server is running, and they will periodically re-try their logins until the server is ready for them. You can also limit the time the server will wait for all specified brokers to log in. This feature requires the updated core elements of the sample broker package.
- Server configuration information is communicated to brokers in the form of a Properties object rather than the earlier, somewhat idiosyncratic PluginConfig instances.
- Communication between the server and brokers uses a simple 2-secret scheme to discourage spoofing (presumably by other brokers). The broker logs in with the name of its queue, and the server passes a short token when the login is accepted, which must be pre-pended to each message sent to the server. This is implemented in the updated sample broker package.
- Boot sessions run much faster. The default currently is 400 msec/timeslot, and it could probably be half that without causing problems.
In addition, a number of issues have been resolved, including
- Weather data now includes cloud cover information (#308), and the solar producers use it to adjust output.
- The competition length computation correctly accounts for the bootstrap period (#486).
- Incoming message from brokers are now written to the server state log (#490).
- The synchronization between the server and brokers is much improved (#492). The clock will be paused if the interval between the TimeslotComplete message and the beginning of the following timeslot falls below a configurable threshold.
- The server has not been known to crash at the end of a simulation since #498 was fixed.
- The sample broker has been refactored to cleanly separate the core framework from the agent behaviors (#501).
- A race condition that existed when a broker tried to revoke a tariff before it was published has been resolved (#505, #507).
- TariffTransactions are no longer crediting brokers when they should be debits (for example, when customers produce power, the broker needs to pay them, not charge them) (#517).
- The Timeslot sequence no longer gets messed up if the machine goes out to lunch past the expected end of a timeslot (#519).
- Customer bootstrap data now shows correct PowerType information, needed by brokers to compose tariffs (#520).
Known defects in this release:
- #531: When the balancing market curtails a customer under an INTERRUPTIBLE_CONSUMPTION tariff in the same timeslot when that customer has reduced its subscription to that tariff to zero, the order of operations is incorrect (the unsubscribe happens before the curtailment), and we get a divide-by-zero error. You should not see then unless you are offering a tariff for interruptible consumption. The sample broker offers such a tariff; until we have a fix, you can not use the sample broker, or you can reduce the rate for that tariff so customers are much less likely to ever unsubscribe.
Power TAC server version 0.2.0, February 2012
(Preliminary) As was the case with the 0.1.0 release, the server is distributed in the form of a small directory that contains a README.txt file, a sample server configuration file, and a maven "project object model" file called pom.xml. Detailed instructions for configuring and running the server are in the README.txt file.
This release also comes with a companion sample broker implementation, written in Java, that provides all the message types, the interaction with the server, and very simple behaviors for offering tariffs and bidding in the wholesale market.
For more information on the status, design, and development process for the server, there is a developer-oriented writeup at GitHub on getting started with the new Power TAC server.
This release represents a significant milestone toward the 2012 competition, but it still lacks the web-based front-end, and there are still no analysis tools. In addition to a number of bugfixes and code cleanups, there are a number of important issues resolved and new features with respect to the 1.0 release:
- New command-line interface gives much more control over server configuration (#463, #481). It is documented in the README file.
- New configuration system provides a uniform way to configure the server, eliminates the need to keep track of server configuration options in three different places, and gets rid of the PluginConfig instances that were showing up in the bootstrap-data file (#462). Instead, the broker is now sent a single Properties instance at the beginning of a simulation session containing all the public configuration data.
- Broker login now works correctly (#467).
- There is now a Java-based sample agent available (#444).
- Server and sample broker can now be configured to run on different hosts (#475).
- Tariff publication and revocation fees are now randomized (#483).
- Customer unsubscribe events are now correctly communicated to brokers, so they can accurately track the number of customers subscribed to each tariff (#487).
- The customer models (both the bottom-up "household-customer" model and the statistical "factored-customer" model) use weather reports to decide how much power to use in certain appliance types, such as air conditioners (#446).
Power TAC server version 0.1.0, December 2011
The server is distributed in the form of a small directory that contains a README.txt file, a sample server configuration file, and a maven "project object model" file called pom.xml. The first time you run the server, there will be a significant pause, and considerable console output, while maven retrieves all the components that make up the server. Detailed instructions for configuring and running the server are in the README.txt file.
For more information on the status, design, and development process for the server, there is a developer-oriented writeup at GitHub on getting started with the new Power TAC server.
This release is a "developers" release. The simulator portion of the Power TAC server is quite usable, but missing a few features that we intend to support for the 2012 competition in June. However, the web-based front-end is missing, the web application for scheduling tournaments and large-scale experiments is not included, and there are as yet no log-analysis tools available.
Specific unresolved issues for this release include (with links to the original github issues)
- We currently do not have a Java-based broker framework to offer (issue #444), although we expect to have one in a few weeks, and there are a couple of people who have already done Java-based brokers. There is also a Grails-based broker framework that has been updated to work with the new server.
- Some modules are not currently configurable through the server properties file (issues #419 and #454.
- Customer models, including the solar and wind models in the factored-customer module, do not react to current weather conditions (issue #441).
- The balancing charges are not generated exactly as described in the specification (issue #435). Instead, the older balancing scheme from the Grails prototype is still in place.
- An anomaly has been observed in wholesale market clearing (issue #457), in a forked version of the server. At this point we have not been able to make it happen in the current codebase, but we are leaving the issue open until we are confident that it's been resolved.
- Brokers do not get information about total net load per timeslot (issue #431).
- Cloud cover in weather reports is always zero (issue #308).
- Customer models currently do not implement controllable/interruptible capacity, and the distribution utility does not exercise them in any case (issue #243).