Lifecycle models with marriage and divorce (exogenous)

1

Exogenous transitions between married couples and singles

I read OLG Model 13: Married Couples, Single Males and Single Females and is a very useful example. The toolkit is getting closer and closer to the frontier :slight_smile:

I was wondering whether there is a natural way to extend this setup to allow for exogenous transitions between marital states. In several recent papers, individuals can transition between being married and single over the life cycle, with exogenous marriage and divorce probabilities. Examples include:

  • Borella, De Nardi, Torres Chain, and Yang, “Why do households save and work?”
  • De Nardi, French, Jones, and McGee, “Why do Couples and Singles Save After Retirement? Household Heterogeneity and its Aggregate Implications.”

Here the term exogenous is key because endogenous family formation is a mess :slight_smile:

My understanding is that in the current version of Model 13, married, male, and female are treated as permanent types (I haven’t read the code yet). This is very easy to set up but in the extension I have in mind they would no longer be permanent types: a single male or female may marry, and a married couple may divorce.

I would introduce an age-dependent transition matrix over marital states, for example pi_marital(m_current,m_next,j), with states such as married, single_male, and single_female. The Bellman equation for each current type would then take expectations not only over next-period productivity shocks, but also over next-period marital status. In other words, the continuation value for a single male would include the probability of remaining single and the probability of becoming married, and the continuation value for a married household would include the probability of remaining married and the probability of divorce.

The main complication is that the household problem changes dimension across marital states. Married households have two labor choices and two productivity processes, while singles have one labor choice and one productivity process. Also, divorce and marriage require a mapping of assets and shocks across household types: for example, after divorce one might split assets according to an exogenous rule, while after marriage one might combine the assets of two singles according to some matching rule.

So my question is: is there already a Toolkit-friendly way to allow transitions across what are currently PTypes? More specifically, can the Toolkit handle a situation where the current “permanent type” affects the current return function and state space, but next period’s type is stochastic? Or would this require a new layer, something like a PType transition matrix together with user-specified mapping rules for assets and shocks when moving from one household type to another?

Thanks again for the married-couples/singles example!

P.S. There is a toolkit example based on Borella, De Nardi and Yang (2018) but it is different from what I described above. In Borella et al the issue is that one of household member can die before the other, the married retired couple can transition into a single retired couple.

1 Like
2

Not presently possible. I will try read those two papers you point to and see if some new feature can be implemented to handle such things. Although will be a month before I have time to take a look. Is very much something I would like the toolkit to handle.

2 Likes
3

Actually this one I have already read before
De Nardi, French, Jones, and McGee, “Why do Couples and Singles Save After Retirement? Household Heterogeneity and its Aggregate Implications.”
From memory though there was no marriage, only dying spouse. There is one thing the toolkit cannot do about it and that is the ‘solve problem about what fraction of assets to give away when spouse deceases’. That said, for most applications you could just replace this with loosing half the assets when spouse deceases (and give some ‘warm glow’ for them on assumption they went to someone else). Toolkit can almost do this, would just require setting up ‘inheritanceasset’ to work everywhere, which is on my to-do list at some point later this year.

PS. Is not impossible to do it, you just have ‘married’, ‘year spouse dies’, and ‘single’ as the markov states. And then in the ‘year spouse dies’ you add this ‘give away some of the assets’ decision. Just that it has to be done as a model period, rather than between periods as in the De Nardi, French, Jones, and McGee paper. Problem is this blow up the state-space in a way that is just ridiculously wasteful.

2 Likes
4

Thanks for your answer. From my understanding of how the toolkit works, I would do this:

  • Forget about permanent type. Code ‘marital status’ as a Markov exogenous state z that takes 3 values: ‘married’, ‘single male’, ‘single female’.
  • So if today z=married, tomorrow with probability 1- \delta you will stay married and you will get the continuation value of being married.
  • Instead, with probability \delta, you will get divorced and the continuation value is the sum of next-period’s value functions for singles:

W^{sm}(a'/2, \epsilon^{\prime,m}) + W^{sf}(a'/2, \epsilon^{\prime,f})

Leaving aside the “asset splitting problem” I believe the toolkit can already handle a problem like this. It might be computationally wasteful since when z=sm,sf, you still have to carry the shock of the other single person. But then one could combine (z,\epsilon^m, \epsilon^f) as a joint grid matrix to avoid duplications.

1 Like
5

Divorce is harder because then you need to track both the single male and single female (not an issue for the value fn so much as would require custom agent dist). But in De Nardi, French, Jones, and McGee there is no divorce, only ‘partner dies’, and then as you say this is just a markov tracking married/single male/single female. It is a bit wasteful because as you point out you need to have ‘both labor supply decisions’ even for the single household, but if you think about it the runtime penalty for this is only around x2 or x3 (as the married is otherwise dominates the runtime).

2 Likes