This paper came out in EER today, I downloaded it and built the main model. Codes on github. Life-cycle model solves in about 3min on my desktop, so GE takes a few hours. If you have access to a high-end server GPU it will be fast enough that you could do the full replication over a weekend (requires solving the general eqm problem maybe 60 times, on a grid for two UI parameters).
Some minor differences from original:
they have a closed-form solution for search effort, âsâ, but toolkit cannot exploit it so I use 11 points
they use a discrete grid on labor effort ânâ, I use 11 points but donât know how many they use
they have n_a=50, I use 150
Main purpose of this was just for me to test for myself what is possible with Claude + VFI Toolkit.
Note: VFI Toolkit can solve this model because it is âsearch laborâ (exogenous job-finding probability), but cannot yet solve âsearch and matchingâ (endogenous job-finding probability).
You mean that the model in partial equilibrium takes 3 minutes but in general equilibrium takes so long? I didnât realize the state space is particularly large.
I realize now that there are really many periods in the lifecycle, perhaps because the calibration is monthly/quarterly. So the state space is indeed larger than usual, and the age dimension cannot be parallelized.
Q: Is the run time you report based on grid interpolation? Maybe one could speed things up by using pure discretization to find (get close to) the general equilibrium.
Good point. I wonder if there is a âcleverâ way to let the toolkit skip the shocks in retirement, without writing 300 additional functions I mean.
In some of my codes I use nz_help dependent on age. The logic:
If j<Jr
nz_help = n_z (does all points)
Else
nz_help = 1
End
Then nz_help is passed to the value function routine. Value function and policies are still defined on the full grid [n_a,n_z,J].
The problem in writing a general toolkit routine is that not all z shocks are equal: health shocks or medical expenses shocks, for example, are present during the whole life-cycle, while productivity shocks only during working age. It looks complicated. Maybe Fable 5 can help (when Trump decides to restore access to it).
Another inefficiency in solving this model with the toolkit, which is unrelated to the one above: what about search effort if the agent is already employed? I think in the model there is no on the job search, so when employed the optimal search effort is trivially zero, but the toolkit still loops over all possible values for search effort. Is it possible to design the grid for search effort so that it is the full grid when the semiz=unemployed but only one point when semiz=employed?
The easy trick that the toolkit can already do is that none of the UI policies in the loop impact retirement at all. So you can just solve once, then keep the period Jr (first retirement period) value fn, and then set vfoptions.V_Jplus1=V(:,Jr) and N_j=Jr-1 and use that in the loop.
[V_Jplus1 is not well tested, so would be worth running once to check it does give same answer under same policies]
This essentially removes retirement completely from the problem (after you solve it once), and so would slash runtimes about 1/3 (as roughly 1/3 of periods are retirement).
Note that this is better than anything you can do with n_z differing by age. But it is not a trick that works in most models.
[I think this is correct, I did not look closely at exactly if there is no impact on retirement when changing UI policies in the loop, because I didnât attempt to code that loop.]
The reason is that the closed-form solution for search effort depends on the value functions in the next-period, right? So the cost of search effort occurs today while the benefit is encoded in the value of being employed tomorrow relative to unemployment.
Technically, the toolkit can use a closed-form solution for a decision variable as long as it can be written inside the current reward in f_ReturnFn, and obviously f_ReturnFn does not allow value functions as input arguments.