I’d like to ask a question about “the toolbox”. when I used the tool “[OccBin: a toolkit for solving dynamic models with occasionally binding constraints easily]”, I don’t know why I need increase nperiods, and how to adjust to the accurate nperiods for my model. Output result warning “Did not converge – increase maxiter_”.How should I deal with the above problems
You have to set
nperiods sufficiently large such that your solution returns back to the reference regime.
The reason is that the OccBin solution approach starts at T (the last period when the alternative regime is binding) and constructs the decision rule by backward iteration.
In general, there is no rule that tells you in advance how many periods you have to specify for
nperiods. It depends on your model at hand.
The warning that you have mentioned (“Did not converge – increase maxiter_”) tells you that the guess and verify approach of finding a solution that fits was not able to reached a solution within the 20 default iterations.
Hence, you have to increase the argument
How should I set up the right maxite. When running the code, although I have increased the maxite to a large value, the output are indicated that “Did not converge – increase maxiter_”.
It depends. Basically, it’s a trial-and-error method.
For the shock
epsilon_f_r a small value of
maxiter (like 10) is sufficient.
For other shocks you have to increase this argument. Solution.zip (20.7 KB)
I have a related question: Is it possible to get different required
nperiods in Windows and Mac OS? I have dynare 5.1 in both machines (Windows with MatlabR2020a and M1mac with Matlab R2021b). For the same code with Occbin, Windows finds the solution without increasing
nperiods but mac tries to increase
nperiods and cannot solve the model.
Can I ask what you think about this issue? Do you think the problem is Matlab version?
This sounds like a bug.
@jpfeifer what do you think?
That should not be the case, but can happen. Different computers and Matlab versions may use different Math Kernel Librarys (MKL). Particularly for pathological cases that may cause differences.
Thank you @Max1 and @jpfeifer for your reply!
I also tried with the same version of Matlab (2020a) on both machines. At least for the code that runs well in both, the piece-wise linear IRFs look little more smooth for Window machine (esp. for the variables related to the occasionally-binding constraint).
Do you think I should try with original Occbin toolbox by Guerrieri and Iacoviello (2015) and see if this is the case there too? Or you think the result is going to be same for my model?
How big are the differences? With numerical results, some small discrepancies are expected. You can try the original toolbox, but it should return the same results.
The difference is not that big but it is just that I am looking for figures that look better.
Maybe this is related: Is there a particular order that Dynare puts equations in
model block together to solve the model? Can that be different by Windows/Mac versions of Dynare? I am asking because I was able to replicate results from Mac with Windows by putting a particular equation in an earlier place in the
model block. It seems like maybe it is important to write equations in an order that clearly defines variables (at least to solve with Occbin).
No, that should not make a difference. How big of a difference are we talking about? Can you provide the two figures?
Sure, here is a version of my model that gives two different figures.
And this is another figure from Mac running the same code with one equation reordered.
The looks worrisome. Could you maybe provide me with the files to investigate the issue?
@jpfeifer Yes, I sent you the files through message a couple of days ago. Would you please take a look when you get a chance?
I had a look and it seems a singularity issue in the baseline regime may be the cause. That would explain the numerical instability on different systems with different equation orderings.
Thanks for your help! I just sent you a new parameter set where the one that causes singularity problem is fixed. Now there is no issue of singularity in the same code. Would this solve the issue? I will also look into it! Thank you again @jpfeifer.
*update: I still get different results from Windows and Mac. Please see figures below.
That looks extremely different. Did the simulation report convergence in both cases?
The problem seems to be the specification
name 'leverage'; bind mult>0; relax mult<0;
mult=0 is none of the regimes. This type of setup makes it hard to figure out in which regime the simulation is. Usually, one includes more of a buffer between the two regime as in Occbin: "increase maxit or check_ahead_periods" with very high maxit and check_ahead_periods - #7 by jpfeifer