• MonashU
• ECC3855ComputationalEconomics
• OverTheShoulderProject

Intro

Here is a place for the project being built by Simon and Steph as an example of putting together a research project.

.. Of course, it is not meant to be a 'benchmark', rather, it will hopefully provide you with a model of someone thinking through the issues and problems and ideas around a complex system / agent-based modelling piece of research.

The Idea

So after a bit of thinking, we are planning to model the 'vertical transport system' (a.k.a. the lifts!) in the Robert Menzies Building.

Why is this interesting

• The Menzies is undergoing a restructure/redevelopment and one of the key problems that has been identified for renewal is the vertical transport
• However, there are significant constraints -- putting in new lifts is costly, there are already building constraints due to the present layout, and money doesn't grow on trees (not to mention any disruption to the RM makes for significant teaching disruption)
• Furthermore, of the options available such as:
  1. Adding a new lift
  2. Restricting floor access by lifts
  3. Changing the levels on which teaching occurs
  4. Adding more stairs
  5. Change of culture ('use the stairs if its under 3' (levels) etc.)
  6. . it isn't obvious which will actually handle with the peak-loads and give significant improvement

What would we like in a model

1. Some kind of realistic movement of people in lifts
2. Ability for students to have different target floors (classrooms)
3. Peak load times well simulated (e.g. high demands for short periods)

4. A little of the preferences for lifts > escalators > stairs (e.g. effort costs)

5. Some idiosyncratic behaviour -- e.g. the person who gets in at 1 and goes to 3 .. !

The Approach/Blog

.. A NetLogo agent-model of course

Thu 23 Oct 2008

... one month on

New Version of the Model!

• Version 1.4

• Version 1.3

• Version 1.2

Updates

1. Major over-haul of the lift and student contingent behaviours

   • I realised that there is actually a lot of contingent (e.g. 'if/else') behaviour that both the lifts and the students undertake to go about their business .. and so, as with some of your projects -- I have undertaken a split between state changes and actions in each state (see code)

   • This approach worked wonders, after some fairly complicated figuring out, the agents now do what they should do when they should do it

2. Incorporation of requests

   • This was something lacking in the previous model -- dealing with buttons pressed at different floors. I have now incorporated this natively into the updating for a lift's stop algorithm -- the lifts dynamically update their 'next-stop' variable, based on the passenger listing's needs, and the needs of users at floors above and below
   • Crucially, we need a further variable than just 'state' for the lift -- we also need its 'direction' -- that is, if you notice, a lift only stops at intermediate floors where the user has pressed a button that is consistent with the lift's direction -- i.e. if the lift is going up to 9 from 2, and someone presses 'down' on 7, we don't stop for them.

Wish list

1. Now we have a robust lift mechanism, and student's behaving rationally, what we need is students to get frustrated and do other things

2. They need to walk up the stairs sometimes (why? when? do they do this)

3. They need to be able to use the escalators (I have this in the setup of the Menzies code (unused at present);
4. I would also like students to have multiple target floors (e.g. a class in 4, followed by a class in 8)
5. Should we include users who don't just spend an hour somewhere, but have much more erratic movements (e.g. staff)?

6. More informative metrics

   • Total wait time
   • Total travel time (perhaps divided by floors travelled -- to get a 'time per floor' measure to compare different methods of vertical transport)

Thu 25 Sep 2008

First attempt at a lift algorithm on paper

• Needs to incorporate 'requests' .. that is, when a user presses a button on a floor that the lift isn't on at the moment -- the lift needs to know about that to open and close at floors for people that aren't currently registered on its floor-list

• Also, need to regenerate target-floor on the fly, since this could change at any time based on the people in the lift (we've done it before), and that so long as a new floor is between the current level and the final-floor, then we have to visit it on the way

Tue 23 Sep 2008

Initiated the process

• Found building the model very complicated
• Not only the lift algorithm (still not worked out), but just dealing with space-time is proving challenging .. restrictions on movement of students to floors (i.e. they can't fly!, or act like ghosts going through the floors)
• First stab:

  • Version 0.1

Comments:

1. Need to modularise the code more (it is confusing at the moment)
2. Can't get by any further without a written down state-diagram (with transitions) for both students and lifts
3. Need to modularise (functionalise) more of the reporter actions to make these do their job gracefully and with generality

Realism issues:

1. Lifts don't come back down
2. Problems with lift algorithm
3. Students don't attend class and come back to the lift
4. Why does it appear that some students 'float' upwards after a lift leaves?!
5. Don't have alternate use of stairs (or escalators) yet