Error with lowmemory in life cycle model with iid shocks

In the model “Life-Cycle Model 11A: Idiosyncratic shocks again, persistent and transitory” there is a bug if the user chooses lowmemory=2

Finite horizon: 80 of 81 
Error using  + 
Arrays have incompatible sizes of 10251 and 51 in dimension 1. In each dimension, the sizes must be equal or one of the arrays must
have size 1.

Error in ValueFnIter_Case1_FHorz_raw (line 263)
                entireRHS_az=ReturnMatrix_az+DiscountFactorParamsVec*entireEV_z;
                                            ^
Error in ValueFnIter_Case1_FHorz (line 890)
                [VKron, PolicyKron]=ValueFnIter_Case1_FHorz_raw(n_d,n_a,n_z, N_j, d_grid, a_grid, z_gridvals_J, pi_z_J, ReturnFn, Parameters, DiscountFactorParamNames, ReturnFnParamNames, vfoptions);
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error in LifeCycleModel11A (line 116)
[V, Policy]=ValueFnIter_Case1_FHorz(n_d,n_a,n_z,N_j, d_grid, a_grid, z_grid, pi_z, ReturnFn, Params, DiscountFactorParamNames, [], vfoptions);
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Related documentation

The error happens because of the line

entireRHS_az=ReturnMatrix_az+DiscountFactorParamsVec*entireEV_z;

The return matrix ReturnMatrix_az should have size [n_d*n_a,1] and entireEV_z likewise, but ReturnMatrix_az is of size [n_d,1] only.
P.S. I don’t need lowmemory=2, but I was looking at the codes to see the algorithm.

Just pushed a fix. Thanks for pointing it out.

I am slowly overhauling the vfoptions.lowmemory settings.
Idea is that if you have:
z & e (markov and iid) then lowmemory=1 loops over e and lowmemory=2 loops over both.
z then lowmemory=1 loops over z
e then lowmemory=1 loops over e

So if you have just z or e, then there is no such thing as lowmemory=2, and if you have no exogenous shocks then there is no lowmemory at all. I feel like this is a more consistent and sensible setting.

Because lowmemory is not much used this overhaul is a very low priority for me so is taking a long time to go through everything.

[This code was in the approach of one of the really old ideas I had many years ago when I thought a loop over a would be a good idea as it lets you solve bigger models. Nowadays I just feel like if you are looping over a then model runtimes are anyway going to be too slow to be useful so there is no point offering it as an option.]

1 Like

Thanks for the answer Robert! Fully agree that this lowmemory options are rarely used. I found this bug just because I was looking under the hood (furthermore, lowmemory=1 does work).