Dears,
I search the internet and realized that Dynare could use particle filter when using Bayesian estimation. Is there any example code to show how to call it. I understand that the we need to set “order =2” within the options of estimation. But how about the rest of model?
Best,
House
Dear Johannes,
Many thanks for the link. While I trying to run the linear_model.mod file. It seems that the datafile “linear_model_data” is missing. Is it possible to share this datafile so that the code could be runned.
Besides, dynare 4.4.3 fails to understand “filter_algorithm=sis” when estimation command tries to call it, could you please suggest which version of dynare could be useful?
Best,
House
linear_model_data.mat is generated by first running github.com/DynareTeam/dynare/blob/master/tests/particle/linear_model.mod
[quote=“jpfeifer”]1. You need to use the unstable version.
2. The linear_model_data.mat is generated by first running github.com/DynareTeam/dynare/blob/master/tests/particle/linear_model.mod[/quote]
Thanks for patient reply. The first question is silly.
When I use the unstable version of 20160802 and choose either 0 or 6 for mode-finder, the error message appears:
*Error using print_info (line 110)
Likelihood is not a number (NaN) or a complex number
Error in print_info (line 110)
error(‘Likelihood is not a number (NaN) or a complex number’);
Error in initial_estimation_checks (line 142)
print_info(info, DynareOptions.noprint, DynareOptions)
Error in dynare_estimation_1 (line 159)
oo_ =
initial_estimation_checks(objective_function,xparam1,dataset_,dataset_info,M_,estim_params_,options_,bayestopt_,bounds,oo_);
Error in dynare_estimation (line 105)
dynare_estimation_1(var_list,dname);
Error in linear_model (line 182)
oo_recursive_=dynare_estimation(var_list_);
Error in dynare (line 223)
evalin(‘base’,fname) ; *
Should I try the most updated version of Dynare? Or it’s a bug to fix?
The linear_model.mod
file seems to be very outdated. I will try to look into it.
[quote=“jpfeifer”]The linear_model.mod
file seems to be very outdated. I will try to look into it.[/quote]
Thanks. Please keep me updated.
Dear Johannes,
Thanks for the code. It works.
Yet I try to understand the code structure and hope to hear your comments.
estimated_params;
a1, .50;
a2, .00;
a3, .70;
a4, .40;
b1, .90;
b2, .00;
b3, .80;
c1, .95;
stderr u, .05;
stderr v, .05;
stderr y, 0.01;
stderr z, 0.01;
end;
[code]options_.particle.status = 1;
options_.particle.initialization = 1;
options_.particle.pruning = 0;
options_.particle.number_of_particles = 20000;
particle.resampling.status.systematic = 1;
options_.particle.resampling.neff_threshold = .1;
options_.gstep(1) = 1e-4;
options_.gstep(2) = .1;
options_.mode_check_neighbourhood_size = 0.05;
set_dynare_threads(‘local_state_space_iteration_2’,3);
[/code]
Best,
House
gstep sets the gradient step size for numerical gradients and should usually not be altered.[quote=“jpfeifer”]1. The first part just means we are doing maximum likelihood instead of Bayesian estimation. That can easily be changed.
2. Please have a look at the manual of the unstable version where most of the options should be (implicitly) defined. The gstep sets the gradient step size for numerical gradients and should usually not be altered.[/quote]
[code]estimated_params;
a1, , , , normal_pdf, 0.5, 0.05;
a2, , , , normal_pdf, 0.0, 0.05;
a3, , , ,normal_pdf, 0.7, 0.05;
a4, , , ,normal_pdf, 0.4, 0.05;
b1, , , , normal_pdf, 0.9, 0.05;
b2, , , ,normal_pdf, 0.0, 0.05;
b3, , , ,normal_pdf, 0.8, 0.05;
c1, , , , normal_pdf, 0.95, 0.05;
stderr u, , , , gamma_pdf, 0.05, 0.05;
stderr v, , , , gamma_pdf, 0.05, 0.05;
stderr y, , , ,gamma_pdf, 0.05, 0.05;
stderr z, , , ,gamma_pdf, 0.05, 0.05;
end;[/code]
Running this mode file results in the following error message:
*Error using chol
Matrix must be positive definite.
Error in sequential_importance_particle_filter (line 74)
StateVectorVarianceSquareRoot =
chol(ReducedForm.StateVectorVariance)’;%reduced_rank_cholesky(ReducedForm.StateVectorVariance)’;
Error in non_linear_dsge_likelihood (line 333)
LIK =
feval(DynareOptions.particle.algorithm,ReducedForm,Y,start,DynareOptions.particle,DynareOptions.threads);
Error in cmaes (line 948)
fitness.raw(k) = feval(fitfun, arxvalid(:,k), varargin{:});
Error in dynare_minimize_objective (line 361)
[x, fval, COUNTEVAL, STOPFLAG, OUT, BESTEVER] =
cmaes(func2str(objective_function),start_par_value,H0,cmaesOptions,varargin{:});
Error in dynare_estimation_1 (line 199)
[xparam1, fval, exitflag, hh, options_, Scale, new_rat_hess_info] =
dynare_minimize_objective(objective_function,xparam1,options_.mode_compute,options_,[bounds.lb
bounds.ub],bayestopt_.name,bayestopt_,hh,dataset_,dataset_info,options_,M_,estim_params_,bayestopt_,bounds,oo_);
Error in dynare_estimation (line 105)
dynare_estimation_1(var_list,dname);
Error in linear_model (line 185)
oo_recursive_=dynare_estimation(var_list_);
Error in dynare (line 223)
evalin(‘base’,fname) ; *
I checked the user manual and it says “mode_compute=9” call an evolutionary algorithm for difficult non-linear non-convex optimization and “mode_compute=6” uses a Monte-Carlo based optimization routine. In this case, it seems using “mode_compute=6” is still acceptable. Then I change the estimation options and use mode_compute=6 instead of mode_compute=9. The modified mod file could be called without error message. But the system is ineffective and updated the mode after several hours. Is it proper to modify the code in this way?
What the interface does is setting the respective fields of
As you found out, these are initialized in
Only some of these options are accessible via the estimation interface, because they are not intended for basic users to change. Instead of setting options via the interface, you can always directly set the options before the command if you know the name of these
[quote=“jpfeifer”]1. Yes, using a non-uniform prior is fine and running a different mode-finder is also OK.
2. In the manual to the unstable version you will see the estimation options for the particle filter after
What the interface does is setting the respective fields of
As you found out, these are initialized in
Only some of these options are accessible via the estimation interface, because they are not intended for basic users to change. Instead of setting options via the interface, you can always directly set the options before the command if you know the name of these[/quote]
Dear Johannes,
Sorry for late reply and thanks for your comments.
I try to run the linear model with bayesian estimation. However, my labtop cannot find the mode after days of searching. It seems that running particle filter is extremely time-inefficient and demands lots of computational power.
Best,
House
Yes, indeed the particle filter is computationally expensive. That is why we rely on the Kalman filter for linear models.
Where is this user manual for the unstable version. Specifically for the particle filter syntax?
When downloading and installing the unstable version, you can find the up-to-date manual in the doc-folder. It’s called dynare.pdf
By including mode_check, the mode check plots are created. How can we get the parameter trajectories and parameter densities plots to be created? I am able to create them with other estimation programs, but not this one.
Which estimation command exactly did you use?
I have been playing around with the linear_model.mod program.
See github.com/DynareTeam/dynare/blob/master/tests/particle/linear_model.mod
Are the option-options the new, or the old approaches to programming SMC.
For example,
options_.particle.number_of_particles = 20000;
options_.particle.resampling.status = 'systematic';
options_.particle.resampling.neff_threshold = .1;
can also be programmed within the estimation command:
or more specifically, my question is which approach is preferable?
Also, is there documentation regarding these options?>
[code]
options_.gstep(1) = 1e-4;
options_.gstep(2) = .1;
options_.mode_check_neighbourhood_size = 0.05;
set_dynare_threads(‘local_state_space_iteration_2’,3);[/code]
In general, you can set any Dynare option manually the way you see it above. If you use the preprocessor interface, all it does is translate the commands to statements like the one above. The preprocessor interface is less prone to mistakes and therefore usually more preferable.
The gstep part is size of the gradient step used in numerical solvers.
mode_check_neighbourhood_size is in the manual.
set_dynare_threads is a command to
[quote]set the number of threads used by some MEX files when compiled
with OpenMP support (i.e with --enable-openmp is given to configure) or any
other parallel library.
[/quote]