I would set up a_grid using the minimum value of gamma (here 0.1) that you plan to use.
This grid will mean some points are unused with gamma=0.2, but this is not a problem, just a little bit of a waste.
(so set up a_grid using -(1-0.1)*maxh, and then use this same grid with both gamma values; toolkit is not currently capable of handling that a_grid changes with age/time-period)
Nice! I could try and finish the Chen (2010) replication if I find the time. I think his experiment is to eliminate social security as in the seminal work by Conesa and Krueger (1999)
Hi Robert, I’m currently working on a housing portfolio model with mortgage contracts. There is an additional state variable to count the remaining periods of mortgage. I wonder does TransitionPath_Case1_FHorz.m work for three state variables?
I think that the answer is yes, you can use TransitionPath_Case1_FHorz() with three endogenous states [so length(n_a)=3]. I’ve never tried.
Obviously runtimes might be an issue (might be too slow to be useful), but I guess you will find out 
If it doesn’t run, let me know and I will try fix it.
What you cannot do yet is use divide and conquer (which would make it faster). Not sure if fastOLG will work or not (good odds it runs out of memory anyway; you can always try it).
PS. I’m assuming ‘housing portfolio model’ does not mean using a riskysset, if it does mean using a riskyasset then you cannot currently do this in transition paths.
I used a simple model to test it. The basic model is still from Chen (2010). Besides net deposit a and housing h, I add an ‘idle’ state variable o. It has only one grid value 0, so basically it does nothing. Households just keep choosing 0. The equilibrium prices are r and Tr. I examined the effect of change in alpha.
Here are my codes. The initial and final equilibrium have no problem but the transition path of all aggregate variables somehow become zero.
When it iterates, it has the following output:
ans =
0.0358 0.0887 NaN 0.0886
0.0355 0.0878 NaN 0.0878
0.0352 0.0870 NaN 0.0869
0.0349 0.0862 NaN 0.0861
0.0346 0.0853 NaN 0.0853
0.0343 0.0845 NaN 0.0844
0.0340 0.0837 NaN 0.0836
0.0337 0.0828 NaN 0.0827
0.0334 0.0820 NaN 0.0819
0.0331 0.0812 NaN 0.0811
0.0328 0.0803 NaN 0.0802
0.0325 0.0795 NaN 0.0794
0.0322 0.0787 NaN 0.0786
0.0319 0.0778 NaN 0.0777
0.0316 0.0770 NaN 0.0769
0.0313 0.0761 NaN 0.0761
0.0310 0.0753 NaN 0.0752
0.0307 0.0745 NaN 0.0744
0.0304 0.0736 NaN 0.0736
0.0301 0.0728 NaN 0.0727
0.0298 0.0720 NaN 0.0719
0.0295 0.0711 NaN 0.0711
0.0293 0.0703 NaN 0.0702
0.0290 0.0695 NaN 0.0694
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 NaN 0.0685
0.0287 0.0686 0.0287 0.0686
Number of iterations on transition path: 1
Current distance between old and new price path (in L-Infinity norm): 0.000089
Current distance to convergence: 0.89 (convergence when reaches 1)
Just pushed a fix to what was the problem (it didn’t actually calculate AggVars when length(n_a)=3, and so just returned all zeros).
I don’t promise this means three assets in FHorz transition path works, I’ve never tested it. But what used to be the error is now gone (maybe there is a new one, maybe not).
Thanks Robert. Now it can produce the non-zero AggVars transition path.
I have another question about the price path. In my test example, the price paths converge immediately. is it normal?
Number of iterations on transition path: 1
Current distance between old and new price path (in L-Infinity norm): 0.000042
Current distance to convergence: 0.42 (convergence when reaches 1)
I have another question about the price path. In my test example, the price paths converge immediately. is it normal?
No. It will only happen once the update of the transition path is less than the convergence tolerance.
If you want an easy test of whether your code likely works, try solving the transition path where ‘nothing happens’ (initial and final eqm are the same).
Good suggestion @robertdkirkby. This is also what I always do to check the transition path.
Basically you compute only the initial steady state and then you set the final steady state equal to the initial one. Hence the guess for the interest rate path (and for other GE variables) is a constant sequence with elements equal to r_ss, the interest rate in the initial/final steady state. Then you should converge almost immediately. If not, there is a bug in the code
@robertdkirkby @aledinola Thanks for the suggestion. If I understand correctly, I should also keep alpha constant (my test model is to analyze the change of alpha), and since nothing changes, the transition path of prices (interest rate and transfer) will be horizontal lines?
Yeah, exactly.
Being able to solve the ‘nothing happens’ transition path does not guarantee that your actual transition path will solve correctly, but if you cannot solve ‘nothing happens’ then you cannot solve your actual transition path. Plus the ‘nothing happens’ is very easy to debug because you know exactly what the answer is so you can see exactly what is going wrong.
Of course, the ‘nothing happens’ transition path is not of any actual interest itself, just tends to be a nice way to do a first debugging of code because no matter how complex the model, you can still easily see if it is getting things correct or not. Once you know you your code solves the ‘nothing happens’ transition path, then you can start solving the actual transition path you are interested in.
Hi Robert,
recently I tried to redo the OLG transition path (using OLG Model 6 Stochastic OLG Model as the basic framework to analyze the change of [parameter alpha). I got the following error message:
Error using gpuArray/reshape
Sparse gpuArray matrices are not supported for this function.
Error in AgentDist_FHorz_TPath_SingleStep_IterFast_raw (line 21)
AgentDist_tt=reshape(Gammatranspose*AgentDist_tt,[N_a,(N_j-1)*N_z]);
Error in AgentDistOnTransPath_Case1_FHorz (line 632)
AgentDist=AgentDist_FHorz_TPath_SingleStep_IterFast_raw(AgentDist,Policy_aprimejz,N_a,N_z,N_j,pi_z_J_sim,II1,II2,exceptlastj,exceptfirstj,justfirstj,jequaloneDist);
Error in transition_test (line 218)
AgentDistPath=AgentDistOnTransPath_Case1_FHorz(StationaryDist_init, jequaloneDist, PricePath, ParamPath, PolicyPath, AgeWeightParamNames,n_d,n_a,n_z,N_j,pi_z,T,Params, transpathoptions, simoptions);
I use the following codes to calculate the path. It can generate the figure of the interest rate path, but not the agg variable K. I think they worked before.
T=50;
ParamPath.alpha=0.4* ones(T,1);
PricePath0.r=[linspace(p_eqm_init.r, p_eqm_final.r, floor(T/2))‘; p_eqm_final.r* ones(T-floor(T/2),1)];
PricePath0.AccidentBeq=[linspace(p_eqm_init.AccidentBeq, p_eqm_final.AccidentBeq, floor(T/2))’; p_eqm_final.AccidentBeqones(T-floor(T/2),1)];
TransPathGeneralEqmEqns.capitalmarket = @(r,K,L,alpha,delta,A) r-alpha A* (K^(alpha-1))* (L^(1-alpha));
TransPathGeneralEqmEqns.bequests = @(AccidentalBeqLeft,AccidentBeq,n) AccidentalBeqLeft/(1+n)-AccidentBeq;
vfoptions.divideandconquer=1;
vfoptions.level1n=11;
vfoptions.fastOLG=1;
transpathoptions.weightscheme=1;
transpathoptions.verbose=1;
transpathoptions.GEnewprice=3;
transpathoptions.GEnewprice3.howtoupdate={…
‘capitalmarket’,‘r’,0,0.03;…
‘bequests’,‘AccidentBeq’,1,0.05;…
};
PricePath=TransitionPath_Case1_FHorz(PricePath0, ParamPath, T, V_final, StationaryDist_init, jequaloneDist,n_d, n_a, n_z, N_j, d_grid,a_grid,z_grid, pi_z, ReturnFn, FnsToEvaluate, TransPathGeneralEqmEqns, Params, DiscountFactorParamNames, AgeWeightParamNames, transpathoptions, simoptions, vfoptions);
figure(1)
plot(0:1:T, [p_eqm_init.r,PricePath.r])
title(‘interest rate path for transtion’)
[VPath,PolicyPath]=ValueFnOnTransPath_Case1_FHorz(PricePath, ParamPath, T, V_final, Policy_final, Params, n_d, n_a, n_z, N_j, d_grid, a_grid,z_grid, pi_z, DiscountFactorParamNames, ReturnFn, transpathoptions, vfoptions);
AgentDistPath=AgentDistOnTransPath_Case1_FHorz(StationaryDist_init, jequaloneDist, PricePath, ParamPath, PolicyPath, AgeWeightParamNames,n_d,n_a,n_z,N_j,pi_z,T,Params, transpathoptions, simoptions);
AggVarsPath=EvalFnOnTransPath_AggVars_Case1_FHorz(FnsToEvaluate,AgentDistPath,PolicyPath,PricePath,ParamPath, Params, T, n_d, n_a, n_z, N_j, d_grid, a_grid,z_grid,transpathoptions, simoptions);
figure(2)
plot(0:1:T, [AggVars_init.K.Mean, AggVarsPath.K.Mean])
title(‘path of transtion for capital’)
Error using gpuArray/reshape
Sparse gpuArray matrices are not supported for this function.
Sparse gpuArray reshape was introduced in Matlab around 2025 or so, and you must be running an earlier version, hence the error. [I run R2026 so I never see this error.]
That said, my intention is to do the AgentDist on cpu matrices (runtime penalty is minor, and amount of memory available is typically much larger releasing what can otherwise be a bottleneck). I will clean this up tomorrow sometime (hopefully) so it is done on cpu matrices instead.
I ran a couple of tests. Using the sparse gpu arrays for agent dist, instead of sparse cpu arrays, roughly halves the run times. [Note that agent dist takes only a small fraction of total runtimes, so the overall gain is not large.]
I think I will try and add a new simoptions that lets you choose whether to do the agent dist on the gpu or cpu. Will give people a little bit more power to set what suits them best.
Will mean that it takes me a few days to fix and get this done.
@Shiki, I’ve just pushed a fix so you can use this [added some gather() to the commands so they will execute on cpu]. I will come back later and set up a simoptions to choose between gpu sparse and cpu sparse when I have more time (too busy with teaching right now).
