Minnesota group meetings

For Fall semester 2010, the Minnesota group is meeting on Thursdays at 17:30 in 6-212 Keller. Meeting agendas and minutes are listed in reverse chronological order.

16 December 2010
Agenda:
 * Make sure we are on track with a weather module.
 * Make sure everyone who wants/needs to can build the server.
 * Structure and process of balancing market. There's a paper with a European perspective on this, the study from Katholieke Universiteit Leuven, the last link at http://www.powertac.org/wiki/index.php/BackgroundReading
 * Catalog broker bootstrap data, see what we can contribute in addition to weather records. One possibility is wholesale market price history, similar to the Weather module. There should be sources both in North America (MISO, NYISO), and Europe (EEX).
 * Review the discussion http://power-tac-developers.975333.n3.nabble.com/Customer-model-capabilities-implied-by-tariff-options-tp2063345p2063345.html and see if we can help clarify.

Minutes:
 * The getting started guide on the wiki is revised. Now we have the ability to use maven to install all of the dependencies!
 * Remember the books? Check your email.
 * We will use git to maintain the integrity of the repository by assigning one person to be in charge of each module. You will need to create a fork to work on a new module. Remember to pull in changes from the master periodically to make integration easy. Once you are ready, to have master pull from you, notify the owner to verify that the code is good and to initiate the process.
 * We probably want the ability to allow the agents to download, using wget, a sort of database of the previous year’s weather data. This gives agents some idea regarding regional weather.
 * We want to share the physical environment fork with historic prices.
 * There are lots of interesting discussions going on right now on nabble. Especially with regards to the discussion tariff features and how customers are able to respond to them.
 * Should we get rid of variable rates?
 * The price you pay per kilowatt hour varies. You may get notice every x hours regarding the price.
 * This is a way for brokers to manage their loads by providing incentive for customers to change their usage. For example if a broker posts a high price there would be incentive for customers to cut back on usage.
 * This could potentially save the broker and customers money in the long run.
 * In a competitive market a variable price tariff should be lower than a fixed rate tariff since the broker is shifting some of the risk to the customer.
 * We need some sort of exit fee so that we can provide the brokers with some stability so that they can feel free to test elasticity.
 * The reputation system combined with the publishing of realized average price for variable rate tariffs should provide customers with an idea of what to expect from the tariff.
 * Should a variable rate tariff’s realized mean price start out as the expected mean price or should it start out with some sort of null value and only get a real value after x number of customers have had the tariff for y number of months.
 * wholesale market.
 * Broker market share will be public. Tariff market data will only be known by the broker selling it.
 * Market supply and demand curves will be cleared and available to all customers and brokers hourly. They will be open to bidding.
 * You will get load predictions that are more realistic since more data such as weather, estimated load and other parameters are closer to the actual value.
 * Every time the market clears all of the bids, as well as the clearing price, are published. However, it is not possible to identity of the bidders.
 * States of a tariff and their transitions.
 * When you offer a tariff, up until someone subscribes to it, you can withdraw it.
 * You can kill a tariff at any time. When a tariff is killed you will either supersede it with a different tariff or lose the customers.
 * Tariffs can be set to expire.
 * Catalog broker bootstrap data will include consumption history, weather history, customer profiles, ect.
 * No one is working on the web application yet. If you are interested please consider picking this up. We are currently thinking about doing it in Grails, although this is negotiable.

9 December 2010
Agenda:

Minutes:
 * John and Wolf are setting up the public wiki. It will contain everything you need to be a participant.
 * We still need to figure out some of the things like the physical environment’s commands and response.
 * Check out the ebooks that john posted.
 * The server, with spring integration, lets you declare the channels in the configuration. Build the modules to send and receive messages. Configuration tells you who sends what where.
 * We will want to add a database as a shared data recourse. This would probably use hibernate and graph.
 * The application server virgo is just a container for the modules.
 * We should have the setup moved to a script in a week. This should significantly decrease the amount of time it takes to set up the development environment.
 * Tariffs:
 * One thing that we cannot currently model is a tariff where a customer is offered a 30% discount for the first x months; and if the customer backs out early they would need to repay the difference to the broker.
 * You can offer a fee or bonus for signing up then have an early withdrawal penalty.
 * You can have a tariff that expires and forces customers to a different successor tariff unless the customer chooses a different tariff instead.
 * Fixed rate and variable rate tariffs. You could even have a tariff that uses both. For example, it could have a fixed rate at night and variable rate during the day or fixed up to some limit, then variable.
 * Peak events. We are not going to go here for now.
 * The big thing we are working on now is the domain types. They should be documented in the domain-data section of the wiki. This is where the physical environment should be documented.
 * Bootstrap data should be available to the web via a simple wget before the game.
 * Consumption data should have 2 years of hourly data for an entire region of net load coming in from the market. This gives you a nice view of things like seasonal variation. It would allow for the statistical analysis of the data's properties.
 * Correlated weather data weather data could be used by brokers.
 * Do we want to use real world data in the bootstrap and model data in the game? It could be different. We could perhaps generate the bootstrap data using model data, assuming that the model data has statistical significance.
 * Bootstrap data is generated using multiple customer populations. The basis of each population is the consumption and production behavior as well as their preferences.
 * What do we do with single large customers? We could make it so that the data is hidden unless the broker is actively engaged in negotiations with that customer. How detailed should that data be?
 * What should they brokers see during the simulation for every subscriber. The data could be broken down by customer population and tariff. Probably give them hourly meter data.
 * Any information on balancing that is taken would have to be in there as well.
 * The server had a major refractor. Domain data is now in the domain data repository, while the server is in server repository.
 * We started to create and clear tickets.
 * A broker needs to know what the state of a resource, such as a water heater, was in for the last time slot. This will allow them to figure out what state it should be in for the current time slot. For example if they turned it off in the last time slot they may not be able to turn it off in the current time slot.
 * In some cases appliances can actually bid in the whole sale market. Currently we are assuming that only a broker can bid in the wholesale market. In the beginning of the game the incumbent has all of the tariffs. This means that the brokers have very little say in market price until they gain a significant market share.
 * There will be a game rule with a maximum lock in period. We may go with something like 20% of the total game period.
 * Customers will need to be able to track what was promised in a tariff vs. what they actually end up paying.
 * We will want to build a reputation module for a broker so that the broker can build or lose reputation. Customers would be able to see this when making their decision.

2 December 2010
Agenda: Minutes:
 * Tariff ontology.
 * Server architecture.
 * Setting up your development environment.
 * Join the nabble list (http://power-tac-developers.975333.n3.nabble.com/) if you want to get information on powertac development.
 * Create a user on the new wiki and on github. John will give you permissions.
 * Github repositories are up and ready to use.
 * You can use the readme in the server repository to help you set up your environment for programming and development.
 * Read up on git, it will be fun.
 * Set up eclipse.
 * Create a branch on github, check out that branch, do development checking into your branch as you desire, then request a pull to merge your branch into the master.
 * We have an ontology for the tariffs. Feel free to review the ontology to get a better idea of what we are doing.
 * customers can have multiple subscriptions.
 * New tariffs can supersede an old tariff, forcing customers to switch to the new one when their subscription ends unless they specifically request otherwise.
 * Payments can be one time or periodic.
 * Tariffs can charge a different rate for production than consumption. There can be a rate for storage. Different types of production, solar, wind, ect. Different types of time; absolute and relative. We have a way to query tariffs based on certain parameters. For example you could search for all tariffs for wind power that are better than the one you already have!
 * Xcel Energy has some tariffs listed on their web site http://smartgridcity.xcelenergy.com/ we should test our system with these. Some of these tariffs allow for Xcel to declare peak power times where customers with those tariffs are notified when peak power periods occur and are asked to reduce their consumption. If they do, they are paid based on the amount they cut back, based on the highest usage during the last 10 days.
 * Next step is to code up some tariffs, v1.0, so we can get some customer models using them.
 * Do we need to model subscriptions in the ontology or is that done in the code? We only need to model things that we want to reason about. We need to draw a line somewhere. Are there more things that should be added? Perhaps the process of balancing?
 * Get your environment set up.
 * Install protege to work on the ontology, install the pellet plugin.
 * Read up on owl and swrl (semantic web rule language). This stuff is very powerful and is used in genomics and biology to help query research data to find relevant information.
 * Still in the process of moving wiki content to the new wikis, git and the public one.

18 November 2010
Agenda: Minutes:
 * New team member, Mihir.
 * Paper: Joskow, Lessons Learned from Electricity Market Liberalization.
 * Discussion of architecture changes proposed by Carsten (not yet on the wiki).
 * Game initial conditions.
 * Balancing: is it a market-clearing problem, or an optimization problem?
 * Alternatives to Wikia?
 * Markets (from the paper Joskow)
 * Transition mechanisms put in place for the transition from the old system to the new system. There are two possible scenarios.
 * Begin with an endowment, brokers must immediately learn about customers and attempt to trade in the market. What about the first and second day, do they not count? Do default tariffs expire after some time.
 * Default services in the transition period. You start with an incumbent, usually regulated monopoly, then newcomers have to take away customers. Often government officials set the default too low, making competition difficult.
 * The paper discusses Europe, US, Chile, New Zealand.
 * Claims that the text book approach to energy market reform is the best approach and that the best is Wales, Argentina, Texas. Chile is often sited as the first one to adopt the text book model.
 * Departing significantly from the model is likely to lead to problems.
 * The last customers could take four or more years to switch from the incumbent and its default tariff.
 * Default tariffs help to put a ceiling on the tariff prices... is this important? This could be an interesting point to research.
 * We need to look into the formula for computing the market clearing price. There are two forms of energy supply, creating energy and reducing energy consumption. There are constraints on this; many could be associated with a physics model. Essentially this is a bunch of times and quantities associated with price. The quantities come from the market. Demand could be considered to be inelastic.
 * Who is allowed to shed power, distribution utility? broker? Someone is losing out. All imbalances must be traded and the net imbalance must be bought or sold in the wholesale market with the prices as described by the supply and demand curve.
 * Shedding load is not the same as offering capacity.
 * Still need Carsten to put his notes on the wiki. He was proposing a major rearrangement of the simulate model roles. Pictures would be nice.
 * Merging tariff model with customer model. What happens when you have different population groups of customer populations. What if a population choses two or more tariffs? We would probably split the population into as many new ones. If we get rid of the tariff model then we may not be able to do this nicely. Also, the tariff market is responsible for aggregating all available tariffs in one location eliminating the need for the brokers and customers to scan all of the brokers to determine what tariffs are available in a given time slot.
 * We need to figure this out since people want to start writing code soon.
 * There is a technology issue involving OSGi bundles. Should we use it? What would it help us with? Every bundle has its own class loaders. It seems like it would likely be difficult to keep different versions of classes in sync. If they need to share information you would need to find a way to keep them in sync. If we want to use repast to build the models then we will have a problem. Repast will not be able to see through that barrier. This would severely limit what can be done with repast or similar tools. Perhaps we could use excaliber as an alternative instead?
 * Bazaar vs other forms of distributed version control systems such as git or mercurical. Bazaar may be on its way out would mercurical be a better choice?
 * Link to mailing list (http://power-tac-developers.975333.n3.nabble.com/). You should join it!
 * Balancing, is it market clearing problem or optimization problem. We will need to do more research into it and discuss it at the next meeting.
 * What do we need to for next week?
 * Finalize the execution part of the project (primary activities during an execution time slot) What needs to be done and who should do it.
 * If you are not writing code sit down: learn groovy, set up eclipse with spring and groovy. There are notes on the wiki on the getting started page with directions on how to do this.

11 November 2010
Agenda: Minutes:
 * Paper: Fletten and Pettersen, Constructing Bidding Curves for a Price-Taking Retailer in the Norwegian Electricity Market.
 * Updates on architecture decisions.
 * Discuss proposed tariff structure (on Market Intelligence Service page).
 * Continue discussion on the Broker Portfolio. This is critical path, and very unclear so far. Background at Game Design (Execution scenario), and under Portfolio and Distribution Utility at Server Architecture.
 * Prioritize and assign development tasks.
 * Discussed constructing bidding curves as described in the paper Fletten and Pettersen.
 * We do not yet have a good way of representing the bidding curve, more research will need to be done to determine the best approach.
 * Architecture decisions:
 * Interaction between most modules will be done with Apache MQ.
 * Simulation server will start up, run one scenario, then quit.
 * All configuration for the server will be stored in the database so that it can be modified through a web front end.
 * We need to determine what the interaction between the brokers and the server during the login and discovery process. Should this use Apache MQ or rest?
 * At the beginning of the game what should the broker's default state be? Different options include:
 * The broker could start with nothing, as a new entry to the market. It would advertise its tariffs and build a customer base from there.
 * Brokers could start with a preexisting customer base and tariff portfolio. They would start with an endowment to purchase energy for the first day. Brokers would then fight each other for customers.
 * We still need an equation for the dispatch price. One book that may help us come up with one is "Fundamentals of Power System Economics".
 * The use of OSGi will let us deploy new and existing features on the fly without restarting the server. This would "make Java like Lisp". However, is there a reason to use it, what problems exist that this could solve?
 * Spring, a dependency injection framework, will be used for the server. Could use Spring Roo framework. If you will be working on the server or the agent framework you will want to install it. Instructions for installing it for eclipse 3.5 are on the wiki, however, the instructions do not work for 3.6 we will need to update them.
 * Tariff structure, market intelligence service and broker's portfolio must deal with it.
 * How do we handle the structure?
 * Consider an ontology based tariff structure instead of using a rigid structure.
 * We can only be so accurate without a physics model. We can use a simplified set of constraints in its place, such as a power ramp up of no more than x, without taping into reserves.
 * In the simulation we assume the power is piecewise linearly distributed during the hour.
 * What are the boundaries between the tariff and broker portfolio.
 * Issues that need action: must define functions called, data returned, and what decisions are made based on the returned data.
 * Brokers may adjust prices for customers with variable pricing. Updated prices may go into effect immediately, or be delayed, depending on tariff specification.
 * Price changes are communicated to Customers.
 * Customers retrieve Environment conditions.
 * Customers determine actual usage and production for the current time slot.
 * Portfolio retrieves supply, demand, and balancing capacity data from Customers.
 * Distribution Utility retrieves supply, demand from Broker Portfolios, and Broker positions from Wholesale Market.
 * DU determines prices for external balancing capacity.
 * DU performs intra-Broker, inter-Broker, and external balancing.
 * DU clears the balancing market and runs resulting Bank transactions.
 * Portfolios compute actual charges and credits based on tariff terms and customer usage and production, run resulting Bank transactions.
 * Brokers may retrieve demand/supply forecasts for future time slots (from where?).
 * We need to determine the incoming and outgoing dependencies between the modules. Who initiates an action and who responds. We would prefer that a module be all incoming or all out going. Modules should be able to call each others methods with repast and events should be property change based.
 * Repository structure, should we have one large project for everything, or separate projects in the repository, one for each module.

28 October 2010
Agenda:
 * Discuss Prashant's suggestion for game design, think through implications (if it's not posted by then, John will outline it for the group).
 * Paper: Anderson, Electricity restructuring: a review of efforts around the world and the consumer response.
 * Update from Dan, Ryan, and Erik on the environment model.

21 October 2010
Agenda:
 * Update on David's Repast tutorial.
 * Work through open questions in the Portfolio and Distribution Utility entities and behaviors. Add more as they come up.
 * If time permits, start thinking through what's needed to create a Portfolio instance, and where the information comes from. Presumably one gets created for each Broker at the beginning of each Execution phase.

14 October 2010
Agenda: Minutes:
 * Paper: Holmberg and Newbery, The Supply Function Equilibrium and Its Policy Implications for Wholesale Electricity Auctions. Talks about strategic bidding in oligopolistic wholesale electricity auctions.
 * Design session: Work out responsibilities and collaborations for the Portfolio type shown in the Server Architecture page. If there's time, also work out data content of its interfaces.

The paper is quite technical, and much of it is out of scope for our work, but it is quite useful to see how price varies with supply and demand. Our wholesale market needs to implement some version of this behavior.

We made considerable progress in working out the Portfolio and Distribution Utility behaviors. John has transcribed that in the linked pages.