I believe that dynare_estimation_1.m contains a bug. I ran across the bug because I wanted to recovered smoothed shocks from a model using the stored mode from estimation. To do this, I used the 'mode_file = ', ‘mode_compute = 0’, and ‘smoother’ options, among others, in the estimation command. However, Dynare never produces the smoothed shocks. The reason is because of a bug in line 124 of dynare_estimation_1.m, which contains the conditional statement that should lead to the code that triggers the smoother. Line 124 reads:
if isequal(options_.mode_compute,0) && isempty(options_.mode_file) && options_.mh_posterior_mode_estimation==0
The problem is that the first two logical expressions are never both true. If mode_compute is zero, then Dynare requires a mode_file (this is documented here: dynare.org/manual/index_24.h … estimation). If there is a mode_file, as required, then the second logical expression in the if statement is false. That means that Matlab never evaluates this expression to be true, which means that under no circumstance can the code that follows be executed.
I am not sure where to submit bug reports, so I figured that maybe the help page was appropriate. Many thanks to the developers for their time in developing the software. If you get a chance to look at this, I would appreciate it.
Hi, thanks for pointing this out. The documentation had not been updated as it should have been. The new entry for mode_comupte = 0 reads:
The mode isn’t computed. When mode_file option is specified, the
mode is simply read from that file. When mode_file option is not
specified, Dynare reports the value of the posterior (likelihood)
evaluated at the initial value of the parameters.
It has been updated in the main branch and will be included in the next release of Dynare.
I don’t think that it is just a bug in the documentation. If you give the arguments mode_compute = 0 and mode_file = filename you cannot get smoothed shocks in some cases because of the faulty conditional statement I referenced earlier. The problematic bug is in the .m file. Currently I have to have a local version of the m file in order to get the smoothed shocks. While I appreciate you updating the documentation, I think that the more serious problem is in the file itself. The code after the line I referenced never can be executed with mode_compute = 0 and a mode_file. This is a problem because you don’t want to have to recompute the mode just to get the smoothed shocks/variables. Even if I start at the mode, that process can take up to an hour on moderately large models. If you could please change the dynare_estimation_1.m file I would appreciate it.
Also, could you please tell me how to submit bug reports other than in the help pages?
Hi, thanks for pointing this out (this is the correct place to report bugs). The full manual entry for mode_compute = 0 now reads:
The mode isn’t computed. When mode_file option is specified, the mode is simply read from that file.
When mode_file option is not specified, Dynare reports the value of the log posterior (log likelihood) evaluated at the initial value of the parameters.
When mode_file option is not specified and there is no estimated_params block, but the smoother option is used, it is a roundabout way to compute the smoothed value of the variables of a model with calibrated parameters.
Thanks for clarifying. I’m glad there is a way to get the smoothed variables from pre-set parameters. It would be nice to be able to use a mode_file for those parameters, but this will work.
By chance could you have a look at the bug in dr1.m that I reported on the board? Bug in dr1.m with loglinear option in estimation
Could you please send us an example demonstratin the problem with computing the smoothed values. I have difficulties reproducing the bug.
- the graphs are missing (this is a bug) but the values are stored in oo_
- there may be a bug if you estimate by maximum likelihood.
In any case, the line with the test that you mention is correct. It is only meant for dealing with mode_compute=0 and no mode_file option.
The code that concerns your case is around line 908.
Thanks for pointing me to line 908. My mod-file is still not producing the smoothed variables or shocks and the reason is that it fails the following test in dynare_estimation_1.m at the conditional statement around line 908:
M_.endo_nbr^2*gend < 1e7
Here, gend is the number of observations in the data and M_.endo_nbr is the number of endogenous variables. The model I am working with is relatively large and includes a 10-year bond rate. This means that there are quite a few auxiliary variables associated with the term structure. With 160 observations (typical US macro series length), I guess the conditional statement above means that I cannot execute the code controlled by line 908 if I have 250 (including auxiliary variables) or more variables in the model. The model I am working with is spread out over about 10 files because of the size, but I produced a simple example (only about 60 lines) that is entirely contained in the attached file and illustrates the point. I guess the issue is the size of the model. Is there a reason to have this cutoff for the size of the number of endogenous variables?
Thanks for your help!
simple.mod (1.11 KB)
The limit is there to avoid useless computation and large storage. Normally, you are interested in the smoothed value only for a few variables. You should just list the name of these variables at the end of the estimation statement, after closing the parentheses for the options.
I completely understand wanting to avoid useless storage, but as in my example above, it doesn’t matter if you list the variables after the estimation command (I listed exactly one). The check is on the total number of endogenous variables, not the number that are listed after the estimation command. So long as the data are sufficiently long or the number of variables sufficiently high, I don’t think the user can have the code executed. Thanks again for your help.
Thanks Ben. I have removed the test on size. The warnings issued when one runs estimation without selected variables should be sufficient. I have also fixed another bug that prevented the correct computation of smoother for selected variables.