Occbin: "increase maxit or check_ahead_periods" with very high maxit and check_ahead_periods

Occbin
1

Hello,

I am receiving a persistent error when estimating a medium-scale DSGE model using Occbin. I am asked to increase check_ahead_periods despite already having set this to a comically high number (20000 quarters). I suspect from previous forum posts that this error is linked to the fact I need “periodic_solution” set as well.

Here is the Occbin setup and estimation call:

    model;
        // interest and QE rules
        [name='interest', bind='ELB']
        iSR = 0.001247663;
        [name='interest', relax='ELB']
        iSR = iT - 1e-06*vr_s1*Ups;
    end;

    occbin_constraints;
        name 'ELB'; bind iT - 1e-06*vr_s1*Ups < 0.001247663; relax iT - 1e-06*vr_s1*Ups > 0.001247663;
    end;

    occbin_setup(likelihood_max_kalman_iterations = 100, likelihood_check_ahead_periods = 20000, smoother_maxit = 100, smoother_periods = 20000, likelihood_periodic_solution, smoother_periodic_solution);

    estimation(datafile=data_Hamilton, mode_compute = 6, mh_nblocks = 2, mh_replic = 20000, mode_check, smoother_redux) y iSR;

iSR is the actual interest rate, iT - 1e-06vr_s1Ups is the shadow rate.

Is there any obvious reason why this might be wrong? I haven’t attached my modfile/code as it is split across seven or eight seperate files, but I can do so if necessary. My model does not have any unit roots (as confirmed by eigenvalues and the check command), but does exhibit very high shock persistence (one important shock decays by about 0.9% per period). It is also worth noting that in my observational data, the interest rate is stuck at the ELB for about 50 quarters (reflecting the UK 2008-2019), which I guess is an unusually long time for Occbin to stay in the alternative regime.

Many thanks in advance.

2

@rattoma Do you have an idea? In any case, we would need to see the files. You can try to use the savemacro=filename-command line option to create one mod-file containing all the code pieces.

3

Thanks - here is the combined modfile, steady state files, and the data.

PH_COMB.mod (13.7 KB)
PH_COMB_steadystate.m (3.2 KB)
PH_steadystate_sublevel.m (3.3 KB)
data_Hamilton.csv (8.7 KB)

4

thank you. I will have a look, but it will not be so fast (I am a bit under water).

5

@Jrs28 I cannot run your main file due to pars not being defined.

6

Apologies - I’ve tested the attached set of files, and they should work.

data_Hamilton.csv (8.7 KB)
PH_COMB_steadystate.m (2.2 KB)

PH_COMB.mod (14.0 KB)
cal_s_core.m (313 Bytes)
PH_COMB_steadystate.m (2.2 KB)
PH_steadystate_sublevel.m (3.3 KB)
solve_steady_core.m (361 Bytes)
find_string_index.m (427 Bytes)

7
  1. Part of the problem is a bug that will crash Occbin whenever something goes wrong. See Provide error handling to piece-wise linear Kalman filter (#1854) · Issues · Dynare / dynare · GitLab
  2. The other issue is your specification. You had
occbin_constraints;
    name 'ELB'; bind iT - 1e-06*vr_s1*Ups < 0.001247663; relax iT - 1e-06*vr_s1*Ups > 0.001247663;
end;

So the ZLB exactly binding will fall between the two regimes, creating oscillations.
Using

% load OccBin 
occbin_constraints;
    name 'ELB'; bind iT - 1e-06*vr_s1*Ups <= 0.001247663-1e-8; relax iT - 1e-06*vr_s1*Ups > 0.001247663+1e-8;
end;

occbin_setup(likelihood_max_kalman_iterations = 100, likelihood_check_ahead_periods = 200, smoother_maxit = 100, likelihood_maxit = 100, smoother_periods = 200, simul_check_ahead_periods = 200);

seems to work. It introduces a slight numerical buffer to prevent spurious reversals.

2 Likes
8

Thank you, that’s very helpful - I’ll give that a try and let you know if I run into any further difficulties.

9

One further question - I see from pausing the estimation that Dynare is using the “missing_observations_kalman_filter” despite the fact that my data is complete and not missing any observations. Is this the intended behaviour?

10

Yes, the piecewise-linear Kalman filter is attached to the missing_observations_kalman_filter.

11

With regards to the error handling, there is an additional issue on line 357 of kalman_update_algo_1.m. The subfunction occbin_kalman_update0 evaluates rank(F)<size(F,1), which sometimes fails with NaN and causes a hard error. On my local copy of Dynare, I have added a try/catch circuit exactly as in model_diagnostics.m lines 155-159 which appears (so far) to resolve the issue.

12

Thanks for pointing this out. My proposal is at kalman_update_algo_1.m: introduce error handling (!2032) · Merge requests · Dynare / dynare · GitLab

13

Thank you for the revised file. Unfortunately, there are still a couple of hard errors which get thrown:

  • “Make shocks the right size for the output” (setting etahat) needs to be done before all the returns, not only that first try/catch loop. The reason is that etahat naturally has two columns, and is reduced using etahat = etahat(:,2) at the very end of the function. This reduction is not done if the function returns early.

  • I also sometimes get an error “Error using missing_observations_kalman_filter. Assignment between unlike types is not allowed.”. This seems to be a consequence the way that regimes_ is initialised as [] at the beginning of the function. I have replaced the line regimes=[]; with regimes=[regimes0 regimes0(end)], which seems to have fixed the issue.

14

There is another set of updates pending: Bug fixes for PKF (!2038) · Merge requests · Dynare / dynare · GitLab

1 Like
15

Thanks, I’ll try that now.

17

Dear Mr. Jpfeifer. Thank you very much.The second problem you pointed out also helped my model run successfully. What I want to ask is, is “bind iT - 1e-06vr_s1Ups <= 0.001247663-1e8” written by mistake? is it “bind iT - 1e-06vr_s1Ups <= 0.001247663-1e-8” that is correct?

18

Yes, that was a typo. I amended the reply above.