Calculate age of children so we can remove child payments for 16+

[ld-archer]

The child uplift interventions currently don't have a mechanism for stopping the payment when the child ages out of the eligible range (currently 16 for Scotland).

To know this we need to calculate the ages of children in the household. There are a couple of variables we can use from US to either directly record this or work it out where necessary. I'm ignoring the variables for number of children in household, fertility etc. as we already use them and have a good understanding:

• age_dv in indall dataset
  • For households that have responded to the child or youth surveys about their children, we have good information on the ages of these children. We can just record these ages.
• nch511_dv
  • For other cases where we have children in the household but not in the data, we can calculate their ages from a number of variables where the ages of children in the household have been binned into groups
  • There a many of these variables with lots of overlap between them ([0-2], [3-4], [4-15], [5-11], [6-15], [0-15], [12-15], [3], [5], [8], [10-15], [16-19], [0-13], [5-15])
  • We can work out from the transitions between bins what age a child is exactly, and because we have multiple waves of data to work with we should be able to do a pretty good job of finding them. As the real information we are keen on is the transition from 16-17, we could even just rely on a few transition points (i.e. 5-6 and 15-16).
  • The only issue with this might be children moving between households and therefore appearing/disappearing mid-range, but this should be easy to spot in the case where e.g. 12-15 band is reduced by 1, but 16-19 band does not increase.
  • Last port of call if all else fails is to draw uniformly from within a band, but we can most likely avoid this

For storing this information in csv we have 2 options.

1. The bad: Add a new column for child 1, child 2, child 3 etc. and increment them until the age of 16.
2. The ugly: Store child ages as a delimited string in a single column. Every child has a single age value in this list, and each year we read the string, modify the contents (age by 1 year) and re-stringify and store again.

I'm leaning heavily towards the ugly here, as it avoids the compllication of having to add max(nkids) number of columns and the complications that come with that in the pipeline e.g. replenishment.

[RobertClay]

just to add to this we'll need to write some new module(s)

• either add to fertilitytime step to change the number of children in the household
• create a new cohabitation module with a moving out on_time_step. can add other things like moving out to this.
• have an entire adulthood module.

I think option A makes the most sense to me.

[ld-archer]

Could just be handled in replenishment when we age the rest of the population? Or simply an ageing module to keep things really simple and in their own bucket? Option B would be the ideal when we get to the stage of doing life events but that would also not really be applicable to the children as they're not in the data yet.

[RobertClay]

I like an age module. Would need to remove ageing from repl which is easy. Makes sense to group relevent variables together

[RobertClay]

think age module covers this. close?