59 COVID Demography Lab

In this lab you will extend the demographic COVID model from the tutorial with a new nodal attribute, and use it to change how the network model handles age mixing. It is practice in the full life cycle of a nodal attribute: creating it, keeping it current as the population ages and turns over, and putting it to work in the formation model. The specific learning objectives for this lab are to:

Practice adding and updating a nodal attribute;
Simulate an epidemic model with different forms of age homophily using that attribute.

59.1 Setup

Once you are ready, start out by clearing your R object environment, to make sure that you do not have any objects lingering from the tutorial. This can be accomplished with:

Code

rm(list = ls())

59.2 Lab Steps

Step 1: Add the attribute to the network

Start with the model code and module functions from the tutorial, and add a categorical age attribute, age.grp, that classifies everyone based on being an adult (18+) versus a minor (<18). This first should be added as a nodal attribute on the network with set_vertex_attribute. You can create a single binary, 0/1, attribute based on the vector of ages with ifelse.

Step 2: Keep the attribute current in the modules

Edit the module functions to update this age attribute. There will be changes to the aging module (to recalculate age group over time), and the arrivals (birth) module (to append this new attribute as 0 to all incoming births). Add 1 or 2 summary statistics within the modules to validate this new age group approach.

Step 3: Use the attribute in the network model

Change the network model parameterization to handle age mixing with this categorical attribute (hint: nodematch instead of absdiff), and pick a target statistic that is reasonable. There is no single right answer, but reason from the random-mixing baseline rather than picking a number that feels assortative; Question 3 below walks through what that baseline is.

Step 4: Run and check the model

Run the model with a single simulation to ensure that the simulations are behaving as expected.

59.3 Lab Questions

Questions

age.grp had to be established in three separate places: on the network with set_vertex_attribute before netest, recalculated inside aging(), and appended inside afunc() for new arrivals. Take each in turn and say what it is for. Then check your intuition against the run you actually did: the simulation covers 300 daily steps, which is under a year. Which of the three edits could not possibly have changed anything over that horizon, and what does that tell you about validating attribute machinery on a run shorter than the process it represents?
Suppose you forget the append_attr call for age.grp in the arrivals module, but keep everything else. The model still runs and raises no error, and the attribute stays the right length anyway. Work out why, in terms of what aging() does and when it runs relative to arrivals. Then answer the question that actually matters: for what kind of attribute would this omission not be self-correcting, and what would go wrong in that case?
Ages are drawn uniformly from 0:85, so minors (0 through 17) are 18 of the 86 values, about 0.209 of the population. Under random mixing the expected share of matched partnerships is therefore about $0.209^2 + 0.791^2$, or roughly 0.67. Target statistics are counts rather than shares, so a “target of 0.67” here means 0.67 * edges. Given that: what would a nodematch target of 0.67 * edges actually represent in the model? Where did your own target fall relative to that baseline, and what claim about age mixing does it make? What would a target of 0.96 * edges be asserting about how minors and adults live, and is that defensible for a general population?
Look at the trajectory of prop.minor across the simulation. What value does it start at, and which direction does it move? Three processes could in principle explain the direction: aging, age-0 arrivals, and age-specific departures. Using the counts the model reports (a.flow, total.deaths, covid.deaths) and the fact that departure.disease.mult multiplies mortality 100-fold for infected people, work out which one actually dominates. The obvious answer is not the right one.

59.4 Worked solution

A worked solution is in the course repository as mod13-COVID1-Lab1.R, with its module functions in mod13-COVID1-fx-Lab1.R. Download both into the same working directory. It walks the four steps above and comments the one decision the lab leaves open, which target statistic to pick for age-group mixing. Please work through the lab yourself before you consult it.

# COVID Demography Lab ```{r setup, include = FALSE} library(knitr) opts_chunk$set(comment = NA) par(mar = c(3, 3, 1, 1), mgp = c(2, 1, 0)) ``` In this lab you will extend the demographic COVID model from the tutorial with a new nodal attribute, and use it to change how the network model handles age mixing. It is practice in the full life cycle of a nodal attribute: creating it, keeping it current as the population ages and turns over, and putting it to work in the formation model. The specific learning objectives for this lab are to: 1. Practice adding and updating a nodal attribute; 2. Simulate an epidemic model with different forms of age homophily using that attribute. ## Setup Once you are ready, start out by clearing your R object environment, to make sure that you do not have any objects lingering from the tutorial. This can be accomplished with: ```{r} rm(list = ls()) ``` ## Lab Steps ::: {.callout-note .instructions} ## Step 1: Add the attribute to the network Start with the model code and module functions from the tutorial, and add a categorical age attribute, `age.grp`, that classifies everyone based on being an adult (18+) versus a minor (<18). This first should be added as a nodal attribute on the network with `set_vertex_attribute`. You can create a single binary, 0/1, attribute based on the vector of ages with `ifelse`. ::: ::: {.callout-note .instructions} ## Step 2: Keep the attribute current in the modules Edit the module functions to update this age attribute. There will be changes to the aging module (to recalculate age group over time), and the arrivals (birth) module (to append this new attribute as 0 to all incoming births). Add 1 or 2 summary statistics within the modules to validate this new age group approach. ::: ::: {.callout-note .instructions} ## Step 3: Use the attribute in the network model Change the network model parameterization to handle age mixing with this categorical attribute (hint: `nodematch` instead of `absdiff`), and pick a target statistic that is reasonable. There is no single right answer, but reason from the random-mixing baseline rather than picking a number that feels assortative; Question 3 below walks through what that baseline is. ::: ::: {.callout-note .instructions} ## Step 4: Run and check the model Run the model with a single simulation to ensure that the simulations are behaving as expected. ::: ## Lab Questions ::: {.callout-note .question} ## Questions 1. `age.grp` had to be established in three separate places: on the network with `set_vertex_attribute` before `netest`, recalculated inside `aging()`, and appended inside `afunc()` for new arrivals. Take each in turn and say what it is for. Then check your intuition against the run you actually did: the simulation covers 300 daily steps, which is under a year. Which of the three edits could not possibly have changed anything over that horizon, and what does that tell you about validating attribute machinery on a run shorter than the process it represents? 2. Suppose you forget the `append_attr` call for `age.grp` in the arrivals module, but keep everything else. The model still runs and raises no error, and the attribute stays the right length anyway. Work out why, in terms of what `aging()` does and when it runs relative to arrivals. Then answer the question that actually matters: for what kind of attribute would this omission *not* be self-correcting, and what would go wrong in that case? 3. Ages are drawn uniformly from `0:85`, so minors (0 through 17) are 18 of the 86 values, about 0.209 of the population. Under random mixing the expected share of matched partnerships is therefore about $0.209^2 + 0.791^2$, or roughly 0.67. Target statistics are counts rather than shares, so a "target of 0.67" here means `0.67 * edges`. Given that: what would a `nodematch` target of `0.67 * edges` actually represent in the model? Where did your own target fall relative to that baseline, and what claim about age mixing does it make? What would a target of `0.96 * edges` be asserting about how minors and adults live, and is that defensible for a general population? 4. Look at the trajectory of `prop.minor` across the simulation. What value does it start at, and which direction does it move? Three processes could in principle explain the direction: aging, age-0 arrivals, and age-specific departures. Using the counts the model reports (`a.flow`, `total.deaths`, `covid.deaths`) and the fact that `departure.disease.mult` multiplies mortality 100-fold for infected people, work out which one actually dominates. The obvious answer is not the right one. ::: ## Worked solution A worked solution is in the course repository as [`mod13-COVID1-Lab1.R`](mod13-COVID1-Lab1.R), with its module functions in [`mod13-COVID1-fx-Lab1.R`](mod13-COVID1-fx-Lab1.R). Download both into the same working directory. It walks the four steps above and comments the one decision the lab leaves open, which target statistic to pick for age-group mixing. Please work through the lab yourself before you consult it.