Although residuals of all of the equations are zero, Dynare returns "The solution to the static equations is not a steady state of the dynamic model: verify that the equations tagged by [static] and [dynamic] are consistent". Could you please advise on the nature of the error and how can I address it as I have checked the equations several times. I am using Mendoza’s 2002 Occasionally binding Constraint model (Attached) occ.mod (6.5 KB)

on other note, when all endogenous variables (defined under -var- in dynare) are included in the state/transitions equation estimation, then vector y of the observation equation such that y = g(x,sigma) is a vector of the same variables? or it refers to non-static variables only ?

Many thanks indeed. Much appreciated.
With regards the second part I am referring to the state-state representation where the attached memo explains how dynare obtains the state equation however the second policy function y=g(x,sigma) is not covered. My question was y vector contains what variables ? All endogenous TechnicalMemo_State space representation of a model implemented in Dynare_IngvarStrid_170227.pdf (605.5 KB)
?

State space representations with observation equations are typically considered in the context of estimation. The variables in the observation equation are all objects for which you have data.

Regarding the first error I am facing , I suspect the issue might have risen due to the fact that: Lagrange multiplier of the binding constraint mu, does not shows up under relax case but enters the FOC when the constraint is bind.

Given the fact that I did not declare mu as an endogenous var nor give it an initial value under steady state block would have triggered this error ?

After I fixed the bug in the equation you have pointed out, I was able to find the steady state and run some simulations, however, I run into the difficulty of the constraint is never binding.

Although I amended the Occasionally binding constraint to bind when D = -0.1*GDP (where D denotes debt with negative values if borrowing), D surpasses -18 and the constraint did not bind as the figure below shows. (attached the results of the simulation results). Both D and GDP should remain at the levels attained when the shocks was triggered.

Can you check whether your model works in the non-binding regime as expected? I am getting only NaN in OccBin due to the decision rules having numerical overflow.

Yes, it seems to me that under non-binding regime results are reasonable. I have initiated a productivity stock (Attached below) where GDP increased and then gradually reverted to steady state levels (pre shock level).

Also, just a little reminder that in the previous shock (interest rate) which I have raised in my previous inquiry, oo_occbin.simul.regime_history which in my understanding documents whether dynare switched to another regime did not document any switch to binding case.

Warning: Matrix is close to singular or badly scaled. Results may be inaccurate. RCOND = 3.022061e-18.
In dyn_first_order_solver (line 256)
In stochastic_solvers (line 249)
In resol (line 114)
In occbin.solver (line 61)
In occ2.driver (line 678)
In dynare (line 282)

@jpfeifer Btw I am getting the same warning on my side for all exogenous shocks. Does this suggests that the model has bugs in terms of FOC equations or it could be other reasons ?

Many thanks prof. Will go over the FOC. But couldn’t be an issue of numeric computation whereby regularization of a matrix that causing the problem might solve the issue or Dynare does that automatically?

Also are you aware prof of any replication of Mendoza 2002 sudden stop model for reference?

Sorry I am referring to this (attached) version error msgs. As I have amended some FOC which has led to the disappearance of some errors. Namely the error msgs now is:

Error using print_info
The Jacobian contains NaNs. For more information, use options_.debug.

Error in check (line 48)
print_info(info, 0, options);

Error in occ.driver (line 338)
oo_.dr.eigval = check(M_,options_,oo_);

Error in dynare (line 281)
evalin(‘base’,[fname ‘.driver’]);

Is it still the same old numerical error ? If yes then how Can I access the matrices as debuging does not seems useful in locating the ill-conditioned matrices.