Modeling Movement Winter Update

Modeling Movement: Visualization of Inhabited Space

During our time at the summer workshop in Venice, we created a simple prototype of an Agent Based Modeling (ABM) system. This prototype sketched out a technical workflow for introducing autonomous agents into our existing 3D model of the Istanbul Toptasi Asylum. We received valuable feedback at and after our presentation in Venice both from the workshop organizers and members of other teams. Since our return from the workshop, we have been defining both a theoretical and technical framework to create a robust series of studies.

Although the ultimate aim is to create an ABM framework, the objective of the modeling at this stage is analyzing whether or not the scripted rules of daily life in the asylum could be implemented given the number and types of admitted patients in the year 1911. We will iterate the process by adjusting the attributes and detailing the rules where they are ambiguous to come up with various scenarios. The ultimate aim is to be able to make arguments about the daily experience of the asylum inhabitants in the absence of textual evidence produced by them, such as letters, diaries.

Modeling Movement Agents

Modeling Movement Agents

The theoretical framework defines the attributes, rules, and timing of the ABM simulations. Agents in the Toptasi Asylum simulation adhere to a strict set of general rules. These rules allow the agents to behave autonomously over a long simulation time using only their initial programmed instructions. Below is a set of attributes and rules applied to the patient population in the asylum:

Toptasi Asylum Patient (Agent) Attributes

Each agent represents an asylum inhabitant that belongs to one type
(In this case: Patient. Others are Medical Officer, Medical Attendant, Administrative Officer, Administrative Attendant)

Each agent belongs to one ward in the asylum
(Classification of the Toptasi Asylum into separate wards based on disease type)

Each agent belongs to one sex that ties into the block and ward that they are admitted (Female/Male)

Each agent is in one state
(Classification of patients based on their recorded diagnosis)

Toptasi Asylum Patient (Agent) Simulation Rules

An agent starts the day, cleans self and makes their bed at 07:00

An agent proceeds to have breakfast in a dining hall at 08:00

An agent needs to be in their ward between 09:00-11:00 for daily medical visits

An agent proceeds to have lunch in a dining hall at 11:00

An agent has time dedicated to a mixture of airing, exercise, socializing, education etc between 12:00-16:00

An agent proceeds to have dinner in a dining hall at 16:00

An agent proceeds to their ward for down time and eventually sleep at 17:00

Toptasi Agent Simulation Model Timing

A single clock increments each minute of simulated time. This clock broadcasts the current time to all agents for their internal itinerary movement. The simulation may run in either real time, where a minute within the simulation equates to a minute outside the simulation, or in a compressed timeline where the simulation clock calculates at a higher rate.

Our ABM platform is built within the Unity3D application as a coordinated set of C# scripts. Agents are prefabricated scripted objects instantiated by our system that use the existing Unity3D codebase to pathfind and navigate within the 3D model. The agents  are generated parametrically by a natural language external text file. This file programmatically creates a cohort of agents, setting a number of common attributes within the cohort. These attributes are used to determine the number of agents, their qualities and states, their designated “home” location, and a number of identifiers employed in agent-to-agent and agent-to-location testing. Additionally, the daily routine of each agent in the cohort is supplied through a set of time:location pairs that trigger agent movement by the master simulation clock. Technically this file format is a JSON file to allow for easy parsing into the Agent Based Modeling system. By generating the agents from an external file, rather than a “hard coded” definition within a script, our system is flexible enough to allow other types of experiments that might operate at a different time span or spatial scale/formation.

Throughout the simulation agents continuously test a number of conditions using iterative and highly accurate raycasting methods: the proximity and visual connection to other agents, exposure to natural light and intervisibility to specific architectural and programmatic features. The outcome of these conditions are stored as data within each Agent and are downloadable into a master external CSV file. The output CSV file makes the agents’ data available for data processing and visualization.