We have shown that the system can relax to an uncongested state using the present times mutator module, however the relaxation takes many hundreds of iterations. We expect that a more goal-oriented module, which tries to return new activity time schedules that are better than old ones, would allow the system to relax faster. We are working on two versions of such module at different stages of development and capability. Both of them use genetic algorithms (GA) to ``evolve'' activity schedules by mutating or mixing existing schedules. One of these contains a global (for all agents) mental map of the traffic network for estimating travel times between proposed activities, but only adjusts the durations of the activities, leaving patterns and locations alone. Unfortunately this module has some bugs in the mental map that have not been worked out yet, so it generates faulty schedules (31,34). The second GA-based model has no known bugs but is not yet integrated into the framework (10).
In addition, we plan to add a population generation module that would disaggregate demographic data to obtain individual households and individual household members (agents), with certain characteristics, such as a street address, car ownership, or household income (4).
As mentioned in Sec. 3.5, the agent database must be aware of dependencies between modules. At this stage, with only two modules, it is easy to hard-code this dependency. However, once we begin adding more modules, we will need to make this information configurable in some way. In fact, it might be desirable to have different ``module paths'' an agent can carry out, with different execution probabilities. For example, an agent could be given the choice between calling only the activity time choice module, calling only the routing module, or calling both (perhaps even with different choices for the calling order). The combination and probabilities of the available choices could reflect behavioral aspects, such as the low frequency of changing work locations (with a work location choice module) compared to the high frequency of changing shopping locations or durations.
Currently a lot of time is spent writing and reading files to communicate plans between the agent database and the modules/simulation. We are working on including a message-based technology into the framework so that plans can be sent directly between the modules as needed, and plans and events can be sent to and from the simulation while it is running. This change will allow decision-making and simulation to occur simultaneously, meaning this change would allow us to implement within-day replanning.
As mentioned in the previous section, we intend to eliminate the memory size limitation imposed on the agent database by current 32-bit architecture by spreading it over many CPUs. The agent database on each CPU would maintain the plans and scores for a subset of the agents in the simulation and would utilize its own set of modules to update those plans. The different plan-sets would be merged when sent to the simulation.