caranha / koudou Goto Github PK

because we don't need to reinvent the wheel.

However, this is low priority right now.

1 time step takes about 1 second (on a regular home computer) and it would be nice if that could be faster somehow. Ideas and explorations in that sense go here.

Add an option / parameter that makes the simulator output "GPS information" (x,y position).

When this option is active, a logfile (CSV format) is created with the position info of every agent. This file should be incremented at regular time intervals (every X seconds, defined by parameter).

• @JasonJiangs reported that the simulator was crashing when running with Earthquake configuration, because the agent did not have the attribute "know_evac"
• @fhtanaka noticed that you need to change parameters/default.py to include the csv file with the evacuation attributes.

Things to do:

• Jason should check that fabio's suggestion work
• Even if fabio's suggestion work, having to change the configuration BOTH in the csv AND in the py seems excessive and confusing. We should simplify the loading of attributes and scenarios somehow. (maybe should spin off in a new issue)

Currently, the Logger module outputs data about the simulation results (totals, changes, etc)

Local prints are being used to output program progress (end of loading stage, steps, etc)

Is this how we want to do this?

Should the logger module handle all text output, and assign them to files / console / null following some parameters (or sane standards?)

Or should we have different modules responsible for data output and simulation status output?

I'm not sure of the best practices. Suggestions welcome.

• Disaster Start Time (Config -- Open/Close of Start time)

  • Disaster End time (Config -- Open/Close of End time)

  • When disaster starts, cancel all actions of all agents (Talk to agent manager)

  • Generate Evacuation Centers (locations in the map)

    • Configuration file
    • Sourced from real data (Tsukuba Center)
    • Capacity

• Add "Evacuation" activity to all agents

  • Optionally, divide between "Evacuation known, and evacuation unknown"

  • "Evacuation known, moves agent to closest evacuation center"

  • Reassign

    • Assign every agent to the closes center even if full
    • When the agent arrives, if the center is full, generate a new
      evacuation activity to the closest center with vacancy

• When targets reach the Evacuation Center,

  • Stay there until end time, and then resume normal operation.
  • Part of the "Evacuation" activity

• Logs

  • Percentage of agents "successfully evacuated" by time.

It would be REALLY nice to have a structure for us to add tests to the software, so that we can make sure that bugs are kept down as the code changes. Adding CI to the tests would be even sweeter.

We don't need full test coverage at the moment, but at least a structure to help new people easily add tests, and a few tests to serve as an example. Things like checking that maps and agents are created correctly could be a good idea.

Changes to facilitate extensibility of select attributes

• Select attributes should not have a "default" value -- rather, just have all other probabilities at 0

• Select attribute shout have weights, not probabilities

• System should be able to handle loading several files of select attributes: Different files could update the same attribute

Evacuation Activity is generated when an agent is told to evacuate.

The agent is checked for the "know where to evacuate" attribute.

• If the agent knows where to evacuate, they will move to the closest evacuation center (generates move action using A* algorithm)

• If the agent does not know where to evacuate, they will move randomly, giving higher weight to following agents in the same location.

Tony is planning to develop a Disease Platform that can represent how different diseases evolve in people depending on socio-economic-bio factors. This means that we could have multiple, different diseases represented as complex state machines (or graph matrixes of disease states).

It would be interesting if koudou was flexible enough to work with these different diseases as plugins. this require two things:

• An easy API for plugging in different disease platforms
• Support for multiple diseases in the simulation engine
• Documentation.

In addition to the above, creating two simple (ficticious) diseases to test the API would be a good way to test and guide the development of the plug-in system.

The idea for the simulator is to include several types of events that have an effect on agent mobility (how agents move around the area). Some examples include: evacuation, voting, entrance examination, protests, entertainment events, sports games, etc.

We would need a documentation / API to allow users to easily define new events or modify existing events.

• Event Definition: Event name, occurrence (time/duration), effect on agent mobility (limitation of mobility in certain streets, requiring agents to move to certain locations, adding extra agents from outside town, etc). (This needs to be worked on more)
• Event Specification: How to define an event in terms of configuration files
• Implementation of the event in the simulation.
• Create some example events.

• visit logs
• activities log

Here is a resource for it:
https://medium.com/@evryinhkyprkbsk/plot-points-and-lines-on-map-with-plotly-mapbox-6af91eb5de62

One main goal of the simulation is to understand how mobility affects several parts of our lives: diseases, events, etc. Mobility here means how people / agents make decisions about where to go, when and how (which method of locomotion, and which path).

To this end, it is useful to have several mobility "drives", which are methods by which agents make decisions about how to move. At the moment, we only have two drives: An A* pathfinder, and a random movement drive (which is used during evacuation, for lost agents). It would be interesting to have more.

In particular, one of the goals of the project is to have mobility drives that are based on human data (learning). While the way to create a mobility drive from human data is not clear yet, it is clear that the simulator needs to support agents having different drives. So mobility drive needs to be a plugin.

There are some problems to solve regarding the building tag data file: config/map/tsukuba-tu-building-data.csv

• First, if the file is not properly formatted (not enough tags? too many tags?) the simulator crashes with no clear error message.
• Second, it is not clear that the behavior when there is not enough tag data is the desired behavior.

Desired behavior of the software:

• Open Street Maps has tags for some (not all?) of the buildings.

• These tags are used to indicate to the agents where they should go for several actions (agents are associated to residential areas, work at work tags appropriate for their jobs, go for leisure and groceries at appropriately tagged spots).

• The simulator should check that the necessary tags exist, and raise warnings for unexpected tags

• Sometimes, tags should be grouped (for example, for job groups)

• Third: How the tags are processed and used should be better documented.