• Abstract
• Acknowledgements
• Contents
• Introduction
• Literature Review
• Methodology
• Results
• Discussion
• Conclusions
• References
• Appendices

Produce the following figures and introduce them into the ODD for stationsim:

• Layout of original stationsim environment
• Layout of new stationsim environment
• Concourse of Grand Central Station

They kind of made sense in the original version when movement was always left to right, but were largely a fudge. Now that there is better collision detection, should we redesign the collision avoidance routine?

• Test that station clock is set up as expected (i.e. location, size, etc.)

• Test that entrance and exit gate locations are correctly set by an agent.

E.g. so that the size of the environment and the ‘normal’ speeds that agents move across it look similar to the real world. (Then when we discuss parameters in the paper we can say that the units are in meters, not something arbitrary).

• Check that gates are where they are supposed to be when we create an instance of the model.

• Test that calculation of distance between agents returns correct values.
• e.g. if Agent 1 is at $(5, 5)$ and Agent 2 is at $(10, 15)$, then the distance returned should be $5\sqrt{5}$.

Include a pointer to the parent model in the stationsim Agent constructor. Then it will no longer be necessary to pass references to the model in Agent functions (e.g. Agent.activate(self, model) becomes Agent.activate(self)

• Does the model use input from external sources such as data files or other models to represent processes that change over time?
• Note that ‘Input data’ does not refer to parameter values or initial values of state variables.

• Who (i.e., what entity) does what, and in what order?
• When are state variables updated?
• How is time modelled, as discrete steps or as a continuum over which both continuous processes and discrete events can occur?
• Except for very simple schedules, one should use pseudo-code to describe the schedule in every detail, so that the model can be re-implemented from this code.
• Ideally, the pseudo-code corresponds fully to the actual code used in the program implementing the ABM.

(Patricia I'm happy to look at this, but would be interested in your thoughts).

When running large numbers of particles, you end up with a few that take ages to complete. E.g. see the screenshot. At the start of the DA window there were 16 python processes all running simultaneously, working their way through a population of 1000 particles. However, after a few hours, most particles have finished but a few remain and take ages. Here you can see that there are only 4 processes remaining. This is because the other 996 particles finished hours ago, but these last four are still going.

I'm not sure why this is happenning. It might be to do with loads of random collisions taking place, but maybe there's a bug. Either way, one way round this might be to keep track of how long the particles are taking to complete and if any take too long, say more 10* the mean runtime of the whole population then we kill the process and discard them...

Following on from a review of the new version of StationSIm, I need to see how my Ensemble Kalman Filter runs with it and fix any compatibility issues.

As with the EnKF code that that it uses, the code for running EnKF experiments and analysis could use some refactoring to make it more readable and concise. This should ultimately culminate in experiments being moved into a notebook similar to those used for other DA methods; utility functions for experiments may be left in an analysis module.

• Unit tests
• Integration tests

After a cursory glance at the EnKF it appears that the code could do with a little refactoring. This is partly be an exercise in reacquainting myself with the code, but also should help with the following:

• help to make it more readable (as an when papers are published that refer to this code, it should be in a state whereby others outside DUST can pick it up),
• ensure that it is compliant with both the original StationSim and the new StationSim_GCS.

At the moment the collisions map produced by stationsim_gcs (e.g. model.get_collision_map()) shows most collisions happenning when agents meet the central barrier. It would be good to distinguish these collisions (which are inevitable) with those that occur when agents collide (which are the interesting ones).

• Test to ensure that upon setup, each agent is allocated an appropriate exit gate.
• Importantly, this exit gate should not be the same as the entrance gate.

• What is the initial state of the model world, i.e., at time t=0 of a simulation run?
• In detail, how many entities of what type are there initially, and what are the exact values of their state variables (or how were they set stochastically)?
• Is initialization always the same, or is it allowed to vary among simulations?
• Are the initial values chosen arbitrarily or based on data?
• References to those data should be provided.

Since I have been away on placement, StationSim has received an overhaul. I should have a look to see what has changed and how it runs.

• What, in detail, are the submodels that represent the processes listed in ‘Process overview and scheduling’?
• What are the model parameters, their dimensions, and reference values?
• How were submodels designed or chosen, and how were they parameterised and then tested?

• Following a chat with Minh last, it is worth reviewing the structure of roadmap.
• Should we leave Testing EnKF Assumptions to end? Perhaps this should be earlier?
• Should there be a section here for a comparison with a basic PF?