Integrate OccBin

https://github.com/lucashare/occbin https://www2.bc.edu/matteo-iacoviello/research_files/TOOLKIT_PAPER.pdf

removed milestone

unassigned @MichelJuillard

assigned to @rattoma

See preprocessor@14be6bad

Note that #1697 (closed) may be problematic. See https://github.com/JohannesPfeifer/Occbin_update/commit/1a3c36d36e3f16382957068eb6fee004c7e9a8cc

See also preprocessor@7baeda8b

@sebastien I started to think about full integration of occbin codes into dynare. On the preprocessor side, I think we need to think better on how to trigger the setup of the occbin environment required to run estimations, smoothers and simulations.

One first element would be how to trigger lines that initialize the occbin environment:

    output << "options_ = set_default_occbin_options(options_, M_);" << endl
           << "clear mr_runsim_occbin_fn" << endl
           << "M_ = get_wish_list(M_);" << endl;

that are conditional to flag

if (occbin_option_present)

Currently, the flag is triggered only when occbin_likelihood or occbin_smoother is present in the estimation command. However, this would most probably trigger errors if the associated tags to the equations that feature the switches are not present.

I would think that the occbin environment should be initialized if the preprocessor identifies the equation tags that define the bind/relax regimes etc., independently on whether occbin is used in an estimation command (also because one may want to run just an occbin simulation for example). would it be possible? would this need maybe having occbin as an option to dynare invocation?

A second element would be simulations: would a flag occbin in stoch_simul make sense to trigger occbin stochastic simulations, irfs and GIRFs? A similar flag would apply to the forecast command.

Finally, there are several algorithmic options of the dynare solver that would need an interface, as well.

Fully integrating occbin may imply more work than envisaged also on the preprocessor side, then.

@rattoma We should probably discuss this in more detail.

1. Is there a need for the preprocessor to know whether any feature with OBC has been called, e.g. because some files should only be created in this case (like when an identification-statement is present). Otherwise, we can check whether everything is correctly specified once we enter the respective functions.
2. We already have similar indicators triggered in the mod-file, e.g. options_.particle.status
3. How will Occbin be integrated? Within existing commands like stoch_simul or estimation? Or with separate commands like for method_of_moments? This decision is not trivial as the underlying functions stoch_simul and dynare_estimation_1 do a lot of stuff that may not be straightforward for OBCs (e.g. computing stochastic moments)
4. Regarding IRFs and GIRFs: there are open tickets for factoring existing IRF codes. We may piggyback on that instead of forcing the new codes into an existing setup.
5. Regarding your code above

<< clear mr_runsim_occbin_fn" << endl
<< "M_ = get_wish_list

why is there a need to clear a function? I find get_wish_list to be too non-descript.

@JohannesPfeifer

1. yes, there are a couple of small parsed files to be produced, so better to do it once at the beginning, rather than calling the occbin environment setup at each statement that uses occbin.
2. once environment is set, we indeed use some indicator into options_ to know that e.g. estimation is run with occbin
3. estimation is fully integrated into dynare_estimation_1 (with piecewise Kalman Filter). one can also use the inversion filter, but its integration is less developed (MCMC ok, smoother not). All other features, currently, rely on stand-alone routines for simulation, irfs, forecasts etc.: one could in principle still use stoch_simul and trigger occbin specific routines, or resort to specific statements like occbin_stoch_simul, etc.
4. good idea to piggyback. we may start from a minimal setup that triggers the environment and occbin solver; estimation is integrated and the rest relies on stand-alone functions. the latter can be further integrated along with other open tickets
5. there is surely space to re-name functions

@rattoma Regarding the whole discussion about how to trigger the occbin mode: since having occasionally binding constraints is fundamentally a property of the model itself, my impression is that we should add an occbin option to the model block itself.

When this option is set, the preprocessor would check that at least one equation has the bind/relax stuff. And it would initialize the occbin environment.

Then all computational commands would behave accordingly (estimation, stoch_simul, forecast…). A command that does not support occbin should error out.

Also I wonder if in this setup, the options occbin_likelihood and occbin_smoother would still be necessary.

What do you think?

@sebastien thanks a lot. I principle, one may want to run stuff with or without OBC in the same instance, so an option that allows to run standard linear stuff may be handy

Ok. Note that since most options in Dynare are sticky, this is not going to be straightforward (i.e. if one uses a hypothetical occbin option to stoch_simul, then it applies to all subsequent calls, unless we create a no_occbin option).

I see. then there is the usual dilemma between occbin and occbin=1|0

@sebastien, sorry. Reflecting a bit more, I would tend to agree with your first proposal, because mixing may become a bit of a mess. And, if so, occbin_likelihood and occbin_smoother may indeed become useless

I would not make this issue too complicated. For most users, having an option to model should be fine. It would make sure that everything in the background is there. Power users should still be able to manually set the respective options to turn it on/off. They have been doing this literally for decades now. We are not going to solve the sticky option issue.

@rattoma Sounds good. So I introduce a model(occbin); syntax that triggers the associated setup. And I remove the occbin_likelihood and occbin_smoother options.

For the time being, I'll also make this option incompatible with all commands except estimation (unless you think that stoch_simul support will come soon).

mentioned in commit preprocessor@5150ef81