Implement function for each empowerment metric

[mzimmermann-IDM]

Could have sworn we already had a issue for this but I can't find it so maybe not! We need functions for each of the empowerment metrics. They are all regressions, coefficients are here, except for the two aggregate measures. The functions are dependent on contraceptive use the prior year, that same empowerment metric the prior year, and demographics (age, parity, wealth, edu, urban/rural). They are all updated annually on her birthday. https://github.com/fpsim/fpsim/blob/Kenya_empowerment_DHS/fpsim/locations/kenya/empower_coef.csv

The two aggregate metrics are updated based on other empowerment metrics nd factor loadings that @pausz already implement. They already update every year, right Paula?

[pausz]

Hi @mzimmermann-IDM

On the main branch there's a call to update empowerment states annually on her birthday, though the states are not actually updated because we hadn't defined how to update them yet.

On the methodtime branch, which is ahead of main, we call the update() method of the Empowerment module at every time step -- that can be changed so the update method is called annually on her birthday. However, I thought there could be other events during the simulation that may trigger changes in empowerment? Do we still want to update empowerment only on her birthday?

[pausz]

Just to clarify, when we speak about 'updating empowerment metrics` with the coefficients in the empower_coef.csv file, are we referring to the (empowerment) probabilities, correct? And then based on the new probabilities we determine whether she has or not that empowerment attribute (ie, update the corresponding (empowerment) state)

Internally in fpsim, for each empowerment metric, there are two (2) quantities associated with it:

• (1) a probability (stratified by age, for ages 15-49) that comes from the csv files (from DHS and PMA datasets). The probabilities are stored in a pars dictionary.
• (2) an agent's state that is either 0 or 1, indicating whether she has that empowerment attribute or not.

The method prob2state() in the Empowerment module uses a bernoulli trial and the appropriate probability in pars to determine the value of the associated state for each woman. Part of the confusion may stem from using the same name for the probabilities themselves in pars (eg, pars["paid_employment"]) and the states (eg, ppl.paid_employment). While it simplifies mapping between the two quantities, it can get confusing.

We've had a continuing discussion about whether empowerment states should be strictly boolean (take the value 0 or 1), or if they could be float (represent a real number between 0 and 1). On methodtime, all the non-composite empowerment states are boolean.

• Are there any empowerment states, apart from the composites, that need to be float or some other type?
• During the course of simulation should we be tracking the empowerment probabilities of each metric for each woman?

[pausz]

The two aggregate metrics are updated based on other empowerment metrics nd factor loadings that @pausz already implement.

In empower_coef.csv we have coefficients for the empowerment metrics marked with a (*). This includes coeffs for the composite metrics. Based on the above comment, should we ignore those coefficients for the composite metrics?

Base empowerment metrics

• buy_decision_daily*
• buy_decision_clothes*
• buy_decision_major*
• decision_purchase
• decision_health*
• decide_spending_partner
• decision_wages*
• has_fin_goals*
• has_fin_knowl*
• has_savings*
• paid_employment*
• sexual_autonomy

Composite empowerment metrics

• decision_making*
• financial_autonomy*

[mzimmermann-IDM]

Hi @mzimmermann-IDM

On the main branch there's a call to update empowerment states annually on her birthday, though the states are not actually updated because we hadn't defined how to update them yet.

On the methodtime branch, which is ahead of main, we call the update() method of the Empowerment module at every time step -- that can be changed so the update method is called annually on her birthday. However, I thought there could be other events during the simulation that may trigger changes in empowerment? Do we still want to update empowerment only on her birthday?

The empowerment metrics are all just updated manually, I don't think we have planned any other events that can change them. So yes, I think annually on her birthday will be great.

[mzimmermann-IDM]

Just to clarify, when we speak about 'updating empowerment metrics` with the coefficients in the empower_coef.csv file, are we referring to the (empowerment) probabilities, correct? And then based on the new probabilities we determine whether she has or not that empowerment attribute (ie, update the corresponding (empowerment) state)

Internally in fpsim, for each empowerment metric, there are two (2) quantities associated with it:

• (1) a probability (stratified by age, for ages 15-49) that comes from the csv files (from DHS and PMA datasets). The probabilities are stored in a pars dictionary.
• (2) an agent's state that is either 0 or 1, indicating whether she has that empowerment attribute or not.

The method prob2state() in the Empowerment module uses a bernoulli trial and the appropriate probability in pars to determine the value of the associated state for each woman. Part of the confusion may stem from using the same name for the probabilities themselves in pars (eg, pars["paid_employment"]) and the states (eg, ppl.paid_employment). While it simplifies mapping between the two quantities, it can get confusing.

We've had a continuing discussion about whether empowerment states should be strictly boolean (take the value 0 or 1), or if they could be float (represent a real number between 0 and 1). On methodtime, all the non-composite empowerment states are boolean.

• Are there any empowerment states, apart from the composites, that need to be float or some other type?
• During the course of simulation should we be tracking the empowerment probabilities of each metric for each woman?

Yes, exactly! Update the probabilities, then based on the new probabilities, determine her 0/1. I think all of the empowerment metrics, aside from the composites, can be 0/1 Boolean, not float, so that's good as is. And I don't think we need to track the probabilities, at least not for an outcome. I suppose it might be useful to be able to see them for debugging or troubleshooting purposes, but aside from that they are not an outcome of interest.

[mzimmermann-IDM]

The two aggregate metrics are updated based on other empowerment metrics nd factor loadings that @pausz already implement.

In empower_coef.csv we have coefficients for the empowerment metrics marked with a (*). This includes coeffs for the composite metrics. Based on the above comment, should we ignore those coefficients for the composite metrics?

Base empowerment metrics

• buy_decision_daily*
• buy_decision_clothes*
• buy_decision_major*
• decision_purchase
• decision_health*
• decide_spending_partner
• decision_wages*
• has_fin_goals*
• has_fin_knowl*
• has_savings*
• paid_employment*
• sexual_autonomy

Composite empowerment metrics

• decision_making*
• financial_autonomy*

Thank you for this list! I also realized that we don't need coefficients for the composite metrics, so I updated empower_coef.csv to not include them. I had just updated it on Thursday, so it was probably after you looked at them. Decide_spending_partner is in there though! You should be able to see that one. We decided to not use sexual autonomy, at least for now, so that's fine. What is decision_purchase? We have major and daily purchases already in there, so I'm not sure what that one was. Where did it come from?