Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transmission File #27

Open
ptheywood opened this issue Nov 28, 2024 · 0 comments
Open

Transmission File #27

ptheywood opened this issue Nov 28, 2024 · 0 comments

Comments

@ptheywood
Copy link
Member

Alongside Time Series and per-individual outputs, an optional otuput containing data for each transmission event may be of interest for post processing, but come with a performance cost (due to data transfer and disk io).

It should be implemented as an optional via a cli parameter.

A subset of data included in the reference model will be emitted, incluiding:

  • Recipient information (id, age, house, occupancy network)
  • Event information (network of transmission, time)
  • Source information (id, age, house, occupancy network, when the source became infected)

This could then be expanded to include the duration of phases for this infection


Implementation in a flamegpu model is likely to be expensive, due to device to host data transfer and serial host implementation blocking the simulation thread from proceeding (for data correctness)

The naieve implemetnation would be:

  • Agents would require short term memory for additional transmission event information (time, source) which are set during infection (and potentially other state changes)
  • init function which prepares / initialises required host data structures
  • Host layer or step function which iterates agent data on the host for all agents, populating the data structures for output (and if support for very large files is desired, outputs the current data)
  • Exit function which finalises the data and outputs to disk

A more performant implementation would likely need to leverage FLAME GPU agent states and function conditions and use a host layer function rather than a step function. This would cause more data movement within the GPU (high bandwidth) but reduce the amount of data movement from device to host (low bandwidth) and serial iteration of data:

  • Agents would require short term memory for additional transmission event information (time, source) which are set during infection (and potentially other state changes)
  • init function which prepares / initialises required host data structures
  • During infection / infection state change, set an agent variable marking that there is transmission data to record
  • Agent function condition on the agent variable, moving the agent from the default state to a "transmission_output" state
  • Host layer function, which only iterates agents in the "transmission_output" state (in serial, on the host) updataing transmission file information
  • Agent function moving agents back to the default state.

This agent-state based approach may cause a change in behaviour for a given seed compared to without, due to how RNG states in FLAME GPU are coupled with the thread index not the FLAME GPU agent index, and after a state change agents may be in a different order.
An explicit agent sort by agent ID would resolve this, with a performance implication, alternatively this would need resolving in flame gpu (see FLAMEGPU/FLAMEGPU2#417, although a separate more specific issues should probably be created)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant