You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In multi-engine simulations, each engine can represent a city (or village, or region). However, in some cases, large cities like Mumbai need to be split up across engines. This can be done by assigning each ward (or administrative region) of the city to an engine. But the model currently only supports daily commute to work within an engine - which would mean that an agent working in Ward A can only commute to work in Ward A. The travel matrix supports travel every 24 hours, and is primarily meant to model inter-city travel, and not commute. We need a way to implement the routine commute across engines.
Thoughts to implement:
Each agent currently has a home_location and work_location. These locations should be updated to include the engine_id along with the area. These locations can be randomly generated, or read from synthetic population.
The routine function currently returns a Point, which is the new intended location of the agent. This should now return an struct such as MoveIntent which will include the engine_id and point at which the agent intends to move. (The agent may not actually be able to move, depending on factors such as lockdown, or if the desintation is already occupied, which is why I propose we call it an Intent).
The actual process of moving an agent should now be abstracted out (into a move function, or a router object), which can either send a message to the destination engine via kafka, or perform a local move on the HashMap.
For agents using public transport, we can randomly choose to use the public transport area of the source engine or the destination engine.
If we want to simulate two or more large cities simultaneously (e.g. Pune and Mumbai, dividied into wards), we need to keep in mind that a typical commute will be within the engines of a city and not across cities. This is important during the setup phase, and we may have to maintain a "commute group" within the configuration, which is a cluster of commutable engines.
The text was updated successfully, but these errors were encountered:
Background:
In multi-engine simulations, each engine can represent a city (or village, or region). However, in some cases, large cities like Mumbai need to be split up across engines. This can be done by assigning each ward (or administrative region) of the city to an engine. But the model currently only supports daily commute to work within an engine - which would mean that an agent working in Ward A can only commute to work in Ward A. The travel matrix supports travel every 24 hours, and is primarily meant to model inter-city travel, and not commute. We need a way to implement the routine commute across engines.
Thoughts to implement:
Each agent currently has a home_location and work_location. These locations should be updated to include the engine_id along with the area. These locations can be randomly generated, or read from synthetic population.
The routine function currently returns a Point, which is the new intended location of the agent. This should now return an struct such as
MoveIntent
which will include the engine_id and point at which the agent intends to move. (The agent may not actually be able to move, depending on factors such as lockdown, or if the desintation is already occupied, which is why I propose we call it an Intent).The actual process of moving an agent should now be abstracted out (into a move function, or a router object), which can either send a message to the destination engine via kafka, or perform a local move on the HashMap.
For agents using public transport, we can randomly choose to use the public transport area of the source engine or the destination engine.
If we want to simulate two or more large cities simultaneously (e.g. Pune and Mumbai, dividied into wards), we need to keep in mind that a typical commute will be within the engines of a city and not across cities. This is important during the setup phase, and we may have to maintain a "commute group" within the configuration, which is a cluster of commutable engines.
The text was updated successfully, but these errors were encountered: