Simulation startup

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Simulation startup

grampajohn
Administrator

I am reading through the wiki page on the broker login process, and I'm a little uncertain how to integrate this single-broker-login scenario with the start-of-game process. Do we set a specific start time, and use the brokers who have logged in by that deadline? In SCM, there are two different scenarios:

  1. The server is running, an agent logs in, and the server sets a start time starting on the next minute boundary not less than 1 minute in the future. Up to 5 other agents will be included if they log in by that deadline, otherwise they will be turned away. If fewer than 6 agents log in by the start time, the remaining slots will be filled with "dummy" agents provided by the server.
  2. A simulation can be started with a specific set of agents at a specific time (this is the tournament setup), and those agents can log in at any time before the end of the game. Of course if they are not there at the beginning they may not do too well. Other agent logins will be turned away until the next game.

The second method works well for a tournament situation, but the first is awkward, and makes it hard to build a decent experiment-automation system. You have to get all the agents started within about a minute of each other, on different hosts. So here's an idea for Power TAC:

  • When we start a simulation on the server, we can specify the set of agents and a start time. This is exactly the same as the tournament setup in SCM. Only those agents will be allowed to log in, and the sim starts at the stated time. What do we do if an agent has not logged in by the start time? Do we leave them out, or assume they will start late. I suspect that a late start will be somewhat less perilous in Power TAC and in TAC SCM.
  • We can specify a start time and a maximum number of agents, and accept logins from any agents that try to log in before the start time, up to the max. This may allow promiscuous login (no pre-registration required) or not. Only the agents that arrive before the start time will be included.
Is this enough? Does it make sense?

John

Reply | Threaded
Open this post in threaded view
|

Re: Simulation startup

grampajohn
Administrator

There appears to be a much bigger problem with simulation startup than simply how we get brokers logged in. That's because the Grails bootstrap process seems to be messed up, and more importantly because we want to be able to run multiple games in sequence without shutting down and restarting the server.

I've spent the morning trying to get a game to start in the server, and somehow the default broker is not getting saved in the database, which causes the accounting service to blow up when it tries to send out transactions. I cannot find anywhere a description of exactly how the Grails bootstrap process is supposed to work, but there seems to be agreement in the various message boards that the app bootstrap runs before the plugin bootstrap code. That seems backwards to me, and it breaks our existing startup sequence.

Perhaps it's a good thing this has happened now and a week from now, because our use of the bootstrap process so far is assuming that a single run of the server is equivalent to a single run of the simulation. This does not seem correct.

So here is a proposal for getting the server startup sequence to work correctly:

  1. No objects are created at bootstrap time - no default Competition, no default Broker. The database is initially empty.
  2. Through either an http POST or through a web page, we create a Competition instance. The controller creates the instance and hands it to the CompetitionControlService, which orchestrates all startup activity, including virtually all the activity that's currently in the plugin bootstrap methods. If there are startup sequence dependencies among plugins, then either we need to invent a decoupled sequencing scheme (I can think of a couple ways to do this) or we can just embed the sequence dependencies in the CompetitionControlService. The latter might be quicker to implement in the short term, but it would seriously break the Grails plugin contract.
  3. Initialization should be done by convention, the same way in every plugin, so the CompetitionControlService can discover the initialization classes and invoke an init() method on each of them. I suggest we recycle David's original idea for plugin configuration, by creating an InitializationService superclass in powertac-server-interface, and then creating a subclass service in every plugin that needs initialization. The init() method can take a list of plugin role names, representing the plugins that have so far been successfully initialized. Plugins can then "reject" the initialization attempt if its sequence dependencies are not satisfied (the necessary roles are not represented in the list). So an init() method returns true if it was successful, false otherwise. This will work as long as we do not create cycles in the dependency graph among our plugins.
  4. When a simulation is complete, its database and log file are saved, and the database completely cleared out. Then creation of a new Competition instance will start the cycle again.

Does this make sense? Can anyone find holes in it?

John

Reply | Threaded
Open this post in threaded view
|

Re: Simulation startup

grampajohn
Administrator
grampajohn wrote
  1. No objects are created at bootstrap time - no default Competition, no default Broker. The database is initially empty.
  2. Through either an http POST or through a web page, we create a Competition instance. The controller creates the instance and hands it to the CompetitionControlService, which orchestrates all startup activity, including virtually all the activity that's currently in the plugin bootstrap methods. If there are startup sequence dependencies among plugins, then either we need to invent a decoupled sequencing scheme (I can think of a couple ways to do this) or we can just embed the sequence dependencies in the CompetitionControlService. The latter might be quicker to implement in the short term, but it would seriously break the Grails plugin contract.

Because the database is initially empty, the POST will need to also create all the needed PluginConfig instances for the individual plugins. Initialization code will need to discover whether those exist before creating new ones. To make it easy to configure a game through a web front-end, we may want to add a method to the InitializationService that creates and saves default PluginConfig instances, giving us something to display and edit.

John

Reply | Threaded
Open this post in threaded view
|

Re: Simulation startup

grampajohn
Administrator
The scheme described in the preceding posts for game initialization is complete and working. Initialization of Gencos,  AccountingService, and TariffMarket are implemented using this scheme.

The process is driven by two methods in CompetitionControlService. The preGame() method sets up the default broker and competition, and calls setDefaults() on all the InitializationService implementations. The configurePlugins() method runs the initialization process for each plugin, and allows them to defer their operations until they see that some other plugin has been initialized.

An advantage of this method is that all the default initialization setups are available for inspection and modification between games. The configurePlugins() method is then called during the game startup sequence. The only remaining BootStrap code simply calls competitionControlService.preGame().

Please let me know if you need help implementing this for your plugins.

John