Matrix singular to working precision - production network


I am working on a large dynamic production network model, where I’m analyzing the effect of a permanent demand shock to a given industry and the transition path to the new steady state. This is a perfect foresight exercise because there is nothing stochastic in my model - hence I’m using the perfect foresight solver. I’m attaching the files for a simple version of this model, with artificial data for just two sectors. checkerdyn.m is the matlab file calibrating and running the model, dynprodnetmodel.mod is the dynare code, and initvalues.mat is the mat file with the initial and terminal values of the simulation.

I am getting the “Matrix is singular to working precision” error - more precisely:

Warning: Matrix is singular to working precision.

In sim1>lin_solve (line 189)
In sim1 (line 131)
In perfect_foresight_solver_core (line 103)
In perfect_foresight_solver>homotopy_loop (line 357)
In perfect_foresight_solver (line 153)
In dynprodnetmodel.driver (line 462)
In dynare (line 310)

The initial steady state is trivial, the final steady-state is calculated numerically in a separate procedure, hence why I’m loading it separately. I also checked that the final steady-state is correct by typing in the final steady-state in endval and using the resid command. Does anyone have any idea why this could be happening? I double-checked the equations, they should be correct.

checkerdyn.m (3.5 KB)

dynprodnetmodel.mod (2.7 KB)

initvalues.mat (911 Bytes)

I simplified the model so that there are no unnecessary complications, but it can’t be simplified too much more to be honest - it is still not working. The model itself is based on Vom Lehn and Winberry (2023).

checkerdyn.m (3.8 KB)
dynprodnetmodel.mod (2.9 KB)
initvalues.mat (911 Bytes)

Your model is not Blanchard-Kahn stable. Is that expected?

It indeed seems like the model has an unstable steady state. The reason I suspect that’s the case is that if I set depreciation equal to one, and set the initial guess equal to the initial value in the first period and from then on the final steady-state (which is indeed a non-explosive equilibrium), Dynare announces a solution (which is the initial guess), while if the guess is an epsilon amount different, Dynare fails to find a solution. I’ll go over the equations again to see if there’s anything missing.

I decided to manually log-linearize the model for simplicity, and drop the exact-hat notation. I also corrected a mistake concerning the timing of capital.

Now, the following happens. When I stochastically simulate the model - shock government spending for one of the sectors in the first period - the simulation works, and gives reasonable results. But when I use perfect foresight simulation, doing approximately the same thing (specify a shock equal to one in the first period), Dynare can’t solve the model (and gives the same error as before). I provide the codes, I left the stochastic simulation commands I used uncommented, and the perfect foresight commands are commented out. What is the reason behind this difference?

checkerdyn.m (2.2 KB)
dynprodnetmodel.mod (3.4 KB)

After fixing a bug in the debugging information (sim1.m: fix logic of mod statement in debug information (!2293) · Merge requests · Dynare / dynare · GitLab) I get

sim1:  The Jacobian of the dynamic model is singular
sim1:  there is 1 collinear relationships between the variables and the equations
Collinear variables:
Collinear equations
Equation     6, period     1
Equation    11, period     1

That should explain why the perfect foresight simulation does not work.

Thank you, sorted - the problem was with the parameter values. Out of curiosity, why does the stochastic simulation work if the perfect foresight experiment doesn’t?

It’s a different solution technique. For perfect foresight you need the stacked Jacobian to be non-singular for the Newton-type solver to work. That was not the case in your model.

What tool did you use to get this error message? I’m trying to debug an extension of my model, but model_diagnostics is not finding any issues.

Once you fix the above bug, simply set options_.debug=true; before perfect_foresight_solver and ideally use just periods=1.

1 Like