# Using histval in perfect foresight simulation

I am using histval and initval in a perfect foresight simulation of a model starting with certain state variables deviating from the steady state. I am unsure whether I am doing it correctly, and whether there’s an easier way. The model is a bit complicated, so I’ll describe the key issues. There’s a downstream sector that produces consumption and an upstream sector that produces three inputs (labeled z0, z1, and z2) to investment goods. Investment at date t comes from combining z0(t), last period’s z1(t-1), and z2(t-2). (The variables are also distinguished by ‘u’ and ‘d’, hence z0u, z0d, etc.)

The simulation perturbs z2(0) to simulate a sectoral disruption. This has no impact on current investment, which comes from goods already in the pipeline. The direct impact will be on investment at date 2, but there will be intervening responses at date 1. I use histval to set z2(0) below the steady state, but also z2(-1) at the steady state.

The attached code (ModelStrike2.mod) seems to work. I set z2(0) and z2(-1) as above, and all other state variables at their steady states, because I want all the other variables only to be affected starting at t=1. In the initval block I put the steady state model, which from the manual I understand to be the terminal values if histval is used.

I have two questions: (1) Am I using histval correctly for this purpose? (In other words, can I trust the results?) And (2) Is there an easier way to assign the steady state values to the all the state variables in the histval block? What I did was first solve for the steady state, and then enter the numbers
for each state variable, as histval doesn’t seem to allow for equations the way initval does. This means if I change a parameter I have to reenter all the new steady state values in the histval block.

Also, for some versions of this model (specifically the attached ModelStrike4.mod, which has 5 stages instead of 3), the solver fails. I get output
Iter: 1, err. = 1.03475, time = 0.113
Iter: 2, err. = Inf, time = 0.09
Warning: Matrix is singular to working precision.

Even though I can compute the steady state, and if I run the code without the solver (just the setup) it runs just fine. So I’m at a loss as to what the problem is, since the basic setup is the same as in the three-stage case that seems to work.

ModelStrike2.mod (4.4 KB)
ModelStrike4.mod (5.8 KB)

1. You can verify with `model_diagnostics` that all the variables in `histval` are indeed state variables that can be set.
2. You can verify in `oo_.endo_simul` that the first column is set correctly to the initial conditions.
3. You can in principle just manually set that first column in Matlab. That allows you to assign the steady state and change the entries of the starting values.

Thanks for the response, I will try that. To clarify, in the ModelStrike2.mod file, I was trying to make some of control variables predetermined at date 0 (in particular all the variables labeled z{xx}). I wasn’t sure if that was allowed, but the code ran and the output made sense. I then tried the exact same thing in the ModelStrike4.mod file, and got the “matrix singular” error. So the mystery to me is why it worked in the first case but not the second. Also, in the second case the perfect_foresight_setup command seems to work and generates the correct initial values and steady state. The two models are identical except for the number of lags involved.

1. for both models, model_diagnostics reported “MODEL_DIAGNOSTICS: No obvious problems with this mod-file were detected.”
2. In both cases the first column in oo_.endo_simul was set correctly to the initial conditions.

Still, for some reason the ModelStrike4.mod gets the “Matrix is singular” error and fails to solve, while ModelStrike2.mod solves with no problem. The models have the exact same structure and initial value setup except that the one that fails has two more stages of upstream production. I’ve also successfully solved a stochastic simulation with the model. So I’m at a loss as to why the perfect foresight solution breaks down. If you have any other ideas it would be appreciated. Thanks.

Such perfect foresight simulations are rather hard to debug. Sometimes a solution for to the complicated nonlinear problem simply does not exist. At other times, the numerical solver breaks down. It’s not always the model structure. Have you tried smaller shocks/deviations?

Thanks, yes, I tried a smaller deviation and had the same failure. In fact, I even set histval at the steady state values and it still failed. I also tried different solution methods. I’m sure a solution exists, as the stochastic simulation works, but I don’t think I can use that for this particular exercise. I’m going to try the intermediate case with 3 lags and see if that solves. Thanks for your suggestions. I’ll post if I can get a solution.

Just to follow up, I think I’ve managed to figure out a workaround for this, by defining a bunch of auxiliary variables (lags of the perturbed initial state variables), using initval and endval instead of histval. I first tried using histval in the model with three lags instead of four, but it had the same failure to solve. My alternative code solved it with no problem, and seems to be correct. (I first tried the method in the model with two lags, for which histval worked. Mine got very similar–though, interestingly, not numerically identical–results.)

I don’t know if this is of any general interest, if others have had the same issue. But it seems to me there may be a problem with histval when there are multiple lags (or I was doing something incorrectly). I’ve attached the two .mod files. ModelStrike3x is the one with histval that fails; ModelStrike3L is my workaround.
ModelStrike3x.mod (5.3 KB)
ModelStrike3L.mod (6.7 KB)

1 Like

You did not initialize `z2u(-1)` and `z2d(-1)`.
ModelStrike3x.mod (5.3 KB)

You’re right, that seems to work! I assumed that the lags defaulted to the same as the time zero values, so that I didn’t need to include them unless they were different. That’s how it seems to work with initval and endval. Thanks for solving this mystery.

My workaround still has one advantage of being able to just tweak the steady state model for the initial values. With histval, if I understand it correctly, I need to first solve for the steady state and then enter values by hand, which is a headache if I want to try different parameter values. But perhaps there’s a way to automate that.

1. No, the default for `histval` is 0.
2. Yes, there is a way to automate by setting `oo_.endo_simul` directly, but that’s more complicated.