dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2020-05-07T17:45:59Zhttps://git.dynare.org/Dynare/dynare/-/issues/1414command options should be made local, and a new syntax should provide persist...2020-05-07T17:45:59ZHoutan Bastanicommand options should be made local, and a new syntax should provide persistent optionsAllow users the possibility to bypass the current situation where an option set in one command is perpetuated into other commands when the user doesn't explicitly pass the option again. e.g. In the following case, the second call to `command` will have options 1, 2, and 3 set even though only 1 and 3 were passed:
```
command(option1, option2);
command(option1, option3);
```
Introduce a new syntax such as
```
command(option1, option2);
command!(option1, option3);
```
which would tell the preprocessor to reset all command-specific options to their defaults before writing output. To do this, every command's options must be local to a substructure of `options_` (i.e. `options_.command.option1`, `options_.command.option2`, etc.)Allow users the possibility to bypass the current situation where an option set in one command is perpetuated into other commands when the user doesn't explicitly pass the option again. e.g. In the following case, the second call to `command` will have options 1, 2, and 3 set even though only 1 and 3 were passed:
```
command(option1, option2);
command(option1, option3);
```
Introduce a new syntax such as
```
command(option1, option2);
command!(option1, option3);
```
which would tell the preprocessor to reset all command-specific options to their defaults before writing output. To do this, every command's options must be local to a substructure of `options_` (i.e. `options_.command.option1`, `options_.command.option2`, etc.)https://git.dynare.org/Dynare/dynare/-/issues/1415rewrite dyn_saveas, dyn_figure to take the options they need as arguments2019-06-19T15:37:44ZHoutan Bastanirewrite dyn_saveas, dyn_figure to take the options they need as argumentsThis is a first step in the long road to completing #1414This is a first step in the long road to completing #14144.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1410Make master mex-files compatible with Matlab R2017a and adjust installer for ...2019-06-19T15:37:44ZJohannes Pfeifer Make master mex-files compatible with Matlab R2017a and adjust installer for WindowsFollowing the discussion in #1225, Matlab R2017a seems to require a change in mex-file compilation.
This also implies that the commit https://github.com/DynareTeam/dynare/commit/4f3b35acbaaa23ad81d5200f68eacbbd9c9b98b6 is not correct, because we need a different set of 64bit mex-files going forward, starting with version `9.2`.Following the discussion in #1225, Matlab R2017a seems to require a change in mex-file compilation.
This also implies that the commit https://github.com/DynareTeam/dynare/commit/4f3b35acbaaa23ad81d5200f68eacbbd9c9b98b6 is not correct, because we need a different set of 64bit mex-files going forward, starting with version `9.2`.https://git.dynare.org/Dynare/dynare/-/issues/1407Keep track of whether smoother results are in logs and adjust smoother2histva...2019-11-26T15:21:02ZJohannes Pfeifer Keep track of whether smoother results are in logs and adjust smoother2histval accordinglySee !1396 See !1396 https://git.dynare.org/Dynare/dynare/-/issues/1406Add interface for #13722019-06-19T15:37:44ZStéphane Adjemianstepan@adjemian.euAdd interface for #1372@houtanb To identify the needed modifications look at #1372 and the new entries in the reference manual.@houtanb To identify the needed modifications look at #1372 and the new entries in the reference manual.4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1403Decide on changing prior in fs2000.mod2019-06-19T15:37:44ZJohannes Pfeifer Decide on changing prior in fs2000.modhttps://github.com/DynareTeam/dynare/commit/b14cf33c8ffe936c3c3ad79846335e918be7fb77 changed the prior for `rho` in the integration tests to not have an asymptote. But this change was not ported to the `fs2000.mod` in the Dynare `examples`-folder. Following the discussion in #1401, we warn users against using such a prior. Therefore, I would propose to change the prior in the `examples`mod-file as well. After all, it is an example, not a replication file.https://github.com/DynareTeam/dynare/commit/b14cf33c8ffe936c3c3ad79846335e918be7fb77 changed the prior for `rho` in the integration tests to not have an asymptote. But this change was not ported to the `fs2000.mod` in the Dynare `examples`-folder. Following the discussion in #1401, we warn users against using such a prior. Therefore, I would propose to change the prior in the `examples`mod-file as well. After all, it is an example, not a replication file.https://git.dynare.org/Dynare/dynare/-/issues/1401Dynare should give warnings when priors are unbounded2019-02-08T08:31:18ZTom HoldenDynare should give warnings when priors are unboundedIt is generally a bad idea to have a prior with unbounded density, as even with reasonably tight identification, such a prior can easily swamp the likelihood. This is particularly problematic when the prior is unbounded at the edges of its support, as then the mode will be driven to the edge, causing further problems with Hessian computation.
At present in Dynare, it is a bit too easy to inadvertently specify such a prior, given the mean and std. dev. specification of the beta distribution. I would suggest that Dynare should give a warning when such are encountered.
For the beta distribution, the prior has bounded support providing alpha>=1 and beta>=1. This means that the variance of the prior must be less or equal to `min(m*(1-m)^2/(1+1-m), (1-m)*m^2/(1+m))`, where `m` is the mean of the distribution.It is generally a bad idea to have a prior with unbounded density, as even with reasonably tight identification, such a prior can easily swamp the likelihood. This is particularly problematic when the prior is unbounded at the edges of its support, as then the mode will be driven to the edge, causing further problems with Hessian computation.
At present in Dynare, it is a bit too easy to inadvertently specify such a prior, given the mean and std. dev. specification of the beta distribution. I would suggest that Dynare should give a warning when such are encountered.
For the beta distribution, the prior has bounded support providing alpha>=1 and beta>=1. This means that the variance of the prior must be less or equal to `min(m*(1-m)^2/(1+1-m), (1-m)*m^2/(1+m))`, where `m` is the mean of the distribution.https://git.dynare.org/Dynare/dynare/-/issues/1398replace equation cross references with those done for json2019-06-19T15:37:44ZHoutan Bastanireplace equation cross references with those done for jsonReplace original version done in 4976b2b3359688e9b1d000bdf05f95d5b6071ac3, f546368252 with those done in 0ccc82300c3046d159554c24027ded09a93b687e
The changes in 0ccc82300c3046d159554c24027ded09a93b687e contain information on lags whereas the original ones don'tReplace original version done in 4976b2b3359688e9b1d000bdf05f95d5b6071ac3, f546368252 with those done in 0ccc82300c3046d159554c24027ded09a93b687e
The changes in 0ccc82300c3046d159554c24027ded09a93b687e contain information on lags whereas the original ones don't4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1400Investigate dseries problems in parallel execution2018-11-08T10:15:22ZJohannes Pfeifer Investigate dseries problems in parallel executionWhen executing the attached file, which runs the ```UseParallel``` feature of ```fmincon```, a crash results because the dseries data is transformed to a structure:
```
Warning: Element(s) of class 'dseries' do not match the current constructor definition. The element(s) have been converted to structures.
> In parallel.internal.pool.deserialize (line 9)
In parallel.internal.pool.deserializeFunction (line 12)
In remoteParallelFunction (line 33)
Warning: Element(s) of class 'dates' do not match the current constructor definition. The element(s) have been converted to structures.
> In parallel.internal.pool.deserialize (line 9)
In parallel.internal.pool.deserializeFunction (line 12)
In remoteParallelFunction (line 33)
```
[SW.zip](https://github.com/DynareTeam/dynare/files/827628/SW.zip)
When executing the attached file, which runs the ```UseParallel``` feature of ```fmincon```, a crash results because the dseries data is transformed to a structure:
```
Warning: Element(s) of class 'dseries' do not match the current constructor definition. The element(s) have been converted to structures.
> In parallel.internal.pool.deserialize (line 9)
In parallel.internal.pool.deserializeFunction (line 12)
In remoteParallelFunction (line 33)
Warning: Element(s) of class 'dates' do not match the current constructor definition. The element(s) have been converted to structures.
> In parallel.internal.pool.deserialize (line 9)
In parallel.internal.pool.deserializeFunction (line 12)
In remoteParallelFunction (line 33)
```
[SW.zip](https://github.com/DynareTeam/dynare/files/827628/SW.zip)
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1397preprocessor: static params derivatives don't use temporary terms2019-06-19T15:37:44ZHoutan Bastanipreprocessor: static params derivatives don't use temporary termssee `kim2_static_params_derivs.m` produced by `identification/kim/kim2.mod`see `kim2_static_params_derivs.m` produced by `identification/kim/kim2.mod`Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1394JSON: incorrect printing of expressions for parameter initializations.2019-06-19T15:37:44ZStéphane Adjemianstepan@adjemian.euJSON: incorrect printing of expressions for parameter initializations.*Created by: albop*
When parameter initializations contains expressions, symbols are replaced by references to `M_.params` instead of symbol name.
For instance, in `example1.mod` if we replace line `rho = 0.95;` by `rho = 0.95+alpha*0.00001;` we currently get:
```
{"statementName": "param_init", "name": "rho", "value": "0.95+M_.params(3)*0.00001"}
```
instead of:
```
{"statementName": "param_init", "name": "rho", "value": "0.95+alpha*0.00001"}
```
It works correctly for variable initializations.*Created by: albop*
When parameter initializations contains expressions, symbols are replaced by references to `M_.params` instead of symbol name.
For instance, in `example1.mod` if we replace line `rho = 0.95;` by `rho = 0.95+alpha*0.00001;` we currently get:
```
{"statementName": "param_init", "name": "rho", "value": "0.95+M_.params(3)*0.00001"}
```
instead of:
```
{"statementName": "param_init", "name": "rho", "value": "0.95+alpha*0.00001"}
```
It works correctly for variable initializations.Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1373Decide on whether evalute_smoother (and others) should set M_.params2019-06-19T15:37:45ZJohannes Pfeifer Decide on whether evalute_smoother (and others) should set M_.paramsThis picks up the discussion in https://github.com/DynareTeam/dynare/pull/1372#issuecomment-271336355
I agree with @MichelJuillard that changing `M_.params` in various functions is a bad idea as it makes it hard to trace what was going on in the mod-file. At the same time, I agree with @rattoma that keeping `M_.params` unchanged when calling `evaluate_smoother` would imply a break with previous versions and therefore mean a loss in backward compatibility. I could live with that, but usually @MichelJuillard prefers to be cautious in the regard. If we want to preserve backward compatibility, we need to make sure that `shock_decomposition` returns `M_` from `evaluate_smoother` to the base workspace, which was broken by https://github.com/DynareTeam/dynare/commit/2f717b5adc5a87f663c5c080f2963d1f65d1933eThis picks up the discussion in https://github.com/DynareTeam/dynare/pull/1372#issuecomment-271336355
I agree with @MichelJuillard that changing `M_.params` in various functions is a bad idea as it makes it hard to trace what was going on in the mod-file. At the same time, I agree with @rattoma that keeping `M_.params` unchanged when calling `evaluate_smoother` would imply a break with previous versions and therefore mean a loss in backward compatibility. I could live with that, but usually @MichelJuillard prefers to be cautious in the regard. If we want to preserve backward compatibility, we need to make sure that `shock_decomposition` returns `M_` from `evaluate_smoother` to the base workspace, which was broken by https://github.com/DynareTeam/dynare/commit/2f717b5adc5a87f663c5c080f2963d1f65d1933ehttps://git.dynare.org/Dynare/dynare/-/issues/1367Investigate issue with disp_dr>subst_auxvar (line 248)2019-06-19T15:37:45ZJohannes Pfeifer Investigate issue with disp_dr>subst_auxvar (line 248)When `M_.aux_vars(i).type = 0` (lead>1), a crash happens. But it is not clear in which case this happens as leads should not be present on the right-hand side of decision rules. See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=12593When `M_.aux_vars(i).type = 0` (lead>1), a crash happens. But it is not clear in which case this happens as leads should not be present on the right-hand side of decision rules. See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=12593https://git.dynare.org/Dynare/dynare/-/issues/1368Verify correctness of manual regarding unfolding of third order matrices2019-06-19T15:37:45ZJohannes Pfeifer Verify correctness of manual regarding unfolding of third order matricesSee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=12557See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=12557https://git.dynare.org/Dynare/dynare/-/issues/1366Decide on how to deal with mistake in manual regarding updated variables2019-06-19T15:37:45ZJohannes Pfeifer Decide on how to deal with mistake in manual regarding updated variablesAccording to the manual, `smoother` triggers the computation of `oo_.UpdatedVariables`. But one actually needs `filtered_vars`. We can either
1. Correct the description in the manual to reflect the code behavior
2. Flag this as a bug as the code deviates from the manual and output `oo_.UpdatedVariables` when only the `smoother` option is specifiedAccording to the manual, `smoother` triggers the computation of `oo_.UpdatedVariables`. But one actually needs `filtered_vars`. We can either
1. Correct the description in the manual to reflect the code behavior
2. Flag this as a bug as the code deviates from the manual and output `oo_.UpdatedVariables` when only the `smoother` option is specifiedhttps://git.dynare.org/Dynare/dynare/-/issues/1356introduce posterior_nograph option2019-06-19T15:37:45ZMarco Rattointroduce posterior_nograph optionI think it would be useful to have an option like:
`options_.posterior_nograph`
with default value at 0 like standard nograph.
This option would allow performing all possible posterior subdraws for irfs, smoothed variables etc, but avoiding to produce thousands of useless graphs that are currently done [for large models at least].
I think it would also be useful to make a distinction w.r.t. `options_.nograph` since the latter would not trigger prior/posterior plots of parameter estimates which would be required in any case.
And by the way, `pm3` and `posterior_irf` do not seem to honor the nograph option: plots are made in any case. So at least we should make sure `nograph` would work properly?
If you agree, I would make the appropriate changes to the matlab `pm3` and `posterior_irf` routines with `posterior_nograph` [the preprocessor could be updated with this extra option, then].
I think it would be useful to have an option like:
`options_.posterior_nograph`
with default value at 0 like standard nograph.
This option would allow performing all possible posterior subdraws for irfs, smoothed variables etc, but avoiding to produce thousands of useless graphs that are currently done [for large models at least].
I think it would also be useful to make a distinction w.r.t. `options_.nograph` since the latter would not trigger prior/posterior plots of parameter estimates which would be required in any case.
And by the way, `pm3` and `posterior_irf` do not seem to honor the nograph option: plots are made in any case. So at least we should make sure `nograph` would work properly?
If you agree, I would make the appropriate changes to the matlab `pm3` and `posterior_irf` routines with `posterior_nograph` [the preprocessor could be updated with this extra option, then].
4.5https://git.dynare.org/Dynare/dynare/-/issues/1349set number of threads per job in parallel execution2019-06-19T15:37:45ZMarco Rattoset number of threads per job in parallel executionGiven the large number of CPU's being made available on desktop pc's, the current node option `singleCompThread` looks rather limited.
I would propose the following changes to the parallel configuration:
- set the default for `singleCompThread` to 0;
- add a node option in dynare.ini `numberOfThreadsPerJob`, which allows to set the number of cpu's assigned to each job. So, for example, for a node with 8 CPU's and `numberOfThreadsPerJob=2`, the parallel engine will split the work into 4 parallel instances, each using 2 cpu's.
would this be possible?Given the large number of CPU's being made available on desktop pc's, the current node option `singleCompThread` looks rather limited.
I would propose the following changes to the parallel configuration:
- set the default for `singleCompThread` to 0;
- add a node option in dynare.ini `numberOfThreadsPerJob`, which allows to set the number of cpu's assigned to each job. So, for example, for a node with 8 CPU's and `numberOfThreadsPerJob=2`, the parallel engine will split the work into 4 parallel instances, each using 2 cpu's.
would this be possible?4.5Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/-/issues/1350Fix shock_decomposition when selected_variables_only is specified2019-06-19T15:37:45ZJohannes Pfeifer Fix shock_decomposition when selected_variables_only is specifiedThe option `selected_variables_only` is currently incompatible with `shock_decomposition ` as can be seen in the mod-file
```
var y ${y}$ (long_name='output')
y_nat ${y^{nat}}$ (long_name='natural output')
y_gap ${\tilde y}$ (long_name='output gap')
pi ${\pi}$ (long_name='inflation')
c ${c}$ (long_name='consumption')
lam ${\lambda}$ (long_name='Lagrange multiplier')
n ${n}$ (long_name='hours worked')
w ${w}$ (long_name='real wage')
r ${r}$ (long_name='nominal interest rate')
mc ${\tau}$ (long_name='Marginal cost')
e ${e}$ (long_name='demand elasticty')
x ${x}$ (long_name='Preference shock')
a ${a}$ (long_name='AR(1) technology shock process')
nu ${\nu}$ (long_name='monetary shock process')
y_fd ${\varepsilon_e}$ (long_name='markup shock')
w_fd ${\varepsilon_e}$ (long_name='markup shock')
r_obs ${\varepsilon_e}$ (long_name='markup shock')
pi_obs ${\varepsilon_e}$ (long_name='markup shock')
;
varexo eps_a ${\varepsilon_a}$ (long_name='technology shock')
eps_nu ${\varepsilon_\nu}$ (long_name='monetary policy shock')
eps_x ${\varepsilon_x}$ (long_name='preference shock')
eps_e ${\varepsilon_e}$ (long_name='markup shock')
;
parameters
alppha ${\alpha}$ (long_name='capital share')
betta ${\beta}$ (long_name='discount factor')
h ${h}$ (long_name='Parameter habit consumption')
phi ${\phi}$ (long_name='unitary Frisch elasticity')
chix ${\chi}$ (long_name='price indexation')
rho_pi ${\phi_{\pi}}$ (long_name='inflation feedback Taylor Rule')
rho_y ${\phi_{y}}$ (long_name='output feedback Taylor Rule')
rho_r ${\phi_{y}}$ (long_name='degree of smoothing Taylor rule')
epsilon ${\epsilon}$ (long_name='steady state demand elasticity')
theta ${\theta}$ (long_name='Calvo parameter')
rho_a ${\rho_{x}}$ (long_name='autocorrelation technology shock')
rho_x ${\rho_{x}}$ (long_name='autocorrelation preference shock')
rho_nu ${\rho_{x}}$ (long_name='autocorrelation monetary shock')
;
%---------------------------------------------------------------
% Parametrization, p. 52
%---------------------------------------------------------------
alppha = 0.3;
betta = 0.99;
h = 0.7;
phi = 1;
chix = 0.6;
rho_pi = 1.5;
rho_y = 0.2;
rho_r = 0.8;
epsilon = 6;
theta = 0.6;
rho_a = 0.8;
rho_x = 0.5;
rho_nu = 0.4;
%---------------------------------------------------------------
% First Order Conditions
%---------------------------------------------------------------
model(linear);
//1. F.O.C. consumption for Households
lam*(1-(h*betta)) = x-((c-(h*c(-1)))*(1/(1-h)))-(h*betta*x(+1))+((c(+1)-(h*c))*((h*betta)/(1-h)));
//2. F.O.C. leisure for Households
phi*n=lam+w;
//3. F.O.C. bonds for Households
0=lam(+1)-lam+r-pi(+1);
//4. Average marginal cost
mc=w+(y*(alppha/(1-alppha)))-(a*(1/(1-alppha)));
//5. First auxiliary variable
pi=((betta/(1+(betta*chix)))*pi(+1))+((chix/(1+(betta*chix)))*pi(-1))+((mc-(e*(1/(epsilon-1))))*(((1-theta*betta)*(1-theta)*(1-alppha))/((1+betta*chix)*(1-alppha+alppha*epsilon)*theta)));
//8. Natural output
alppha*y_nat=a-((1-alppha)*w)+(((1-alppha)/(epsilon-1))*e);
//9. Taylor Rule
r=(r(-1)*rho_r)+((1-rho_r)*((rho_pi*pi)+(rho_y*y_gap)))+nu;
//10. Definition output gap
y_gap = y-y_nat;
//12. Equilibrium
y=c;
//13. Production function
y=(n*(1-alppha))+a;
//14. TFP shock
a=(rho_a*a(-1))+eps_a;
//15. Preference shock
x=(rho_x*x(-1))+eps_x;
//16. Markup shock
e=((1-epsilon)/epsilon)*eps_e;
//17. Monetary shock
nu=(rho_nu*nu(-1))+eps_nu;
//// Observation equations
//18. Output
y_fd = y;
//19. Wage
w_fd = w;
//20. Interes Rate
r_obs=r;
//21. Inflation
pi_obs=pi;
end;
shocks;
var eps_a= 0.02^2 ;
var eps_nu= 0.04^2;
var eps_x= 0.02^2;
var eps_e= 0.2^2;
end;
stoch_simul(order=1,periods=200,irf=0) y_fd w_fd r_obs pi_obs;
datatomfile('observables_gali2_filt_119',char('y_fd','w_fd','r_obs','pi_obs'));
varobs y_fd w_fd r_obs pi_obs;
estimated_params;
alppha, 0.3, 0, 1,beta_pdf, 0.3, 0.05;
h, 0.7, 0, 1,beta_pdf, 0.33, 0.15;
phi, 1, , ,gamma_pdf, 1.17, 0.351;
chix, 0.6, 0, 1, beta_pdf, 0.61, 0.112;
rho_pi, 1.5, 0, 10, normal_pdf, 1.5, 0.2;
rho_y, 0.2, 0, 10, normal_pdf, 0.2, 0.1;
theta, 0.6, 0, 1, beta_pdf, 0.61, 0.112;
rho_a, 0.7, 0, 1, beta_pdf, 0.61, 0.112;
rho_x, 0.5, 0, 1, beta_pdf, 0.61, 0.112;
rho_nu, 0.4, 0, 1, beta_pdf, 0.61, 0.112;
stderr eps_a, inv_gamma_pdf, 0.1, 2;
stderr eps_nu, inv_gamma_pdf, 0.1, 2;
stderr eps_x, inv_gamma_pdf, 0.1, 2;
stderr eps_e, inv_gamma_pdf, 0.1, 2;
end;
estimated_params_init;
alppha, 0.3;
h, 0.7;
phi, 1;
chix, 0.6;
rho_pi, 1.5;
rho_y, 0.2;
theta, 0.6;
rho_a, 0.7;
rho_x, 0.5;
rho_nu, 0.4;
stderr eps_a, 0.02;
stderr eps_nu, 0.04;
stderr eps_x, 0.02;
stderr eps_e, 0.2;
end;
%identification;
estimation(datafile=observables_gali2_filt_119,mh_replic=2000,mh_nblocks=1, mode_compute=4) y_fd w_fd y;
save temp;
// options_.selected_variables_only=0;
shock_decomposition(parameter_set=posterior_mean) y y_fd;
```
The best solution seems to be making the `options_` structure local to `evaluate_smoother` (related to #1197 ) and then set `options_.selected_variables_only=0` in `shock_decomposition.m`The option `selected_variables_only` is currently incompatible with `shock_decomposition ` as can be seen in the mod-file
```
var y ${y}$ (long_name='output')
y_nat ${y^{nat}}$ (long_name='natural output')
y_gap ${\tilde y}$ (long_name='output gap')
pi ${\pi}$ (long_name='inflation')
c ${c}$ (long_name='consumption')
lam ${\lambda}$ (long_name='Lagrange multiplier')
n ${n}$ (long_name='hours worked')
w ${w}$ (long_name='real wage')
r ${r}$ (long_name='nominal interest rate')
mc ${\tau}$ (long_name='Marginal cost')
e ${e}$ (long_name='demand elasticty')
x ${x}$ (long_name='Preference shock')
a ${a}$ (long_name='AR(1) technology shock process')
nu ${\nu}$ (long_name='monetary shock process')
y_fd ${\varepsilon_e}$ (long_name='markup shock')
w_fd ${\varepsilon_e}$ (long_name='markup shock')
r_obs ${\varepsilon_e}$ (long_name='markup shock')
pi_obs ${\varepsilon_e}$ (long_name='markup shock')
;
varexo eps_a ${\varepsilon_a}$ (long_name='technology shock')
eps_nu ${\varepsilon_\nu}$ (long_name='monetary policy shock')
eps_x ${\varepsilon_x}$ (long_name='preference shock')
eps_e ${\varepsilon_e}$ (long_name='markup shock')
;
parameters
alppha ${\alpha}$ (long_name='capital share')
betta ${\beta}$ (long_name='discount factor')
h ${h}$ (long_name='Parameter habit consumption')
phi ${\phi}$ (long_name='unitary Frisch elasticity')
chix ${\chi}$ (long_name='price indexation')
rho_pi ${\phi_{\pi}}$ (long_name='inflation feedback Taylor Rule')
rho_y ${\phi_{y}}$ (long_name='output feedback Taylor Rule')
rho_r ${\phi_{y}}$ (long_name='degree of smoothing Taylor rule')
epsilon ${\epsilon}$ (long_name='steady state demand elasticity')
theta ${\theta}$ (long_name='Calvo parameter')
rho_a ${\rho_{x}}$ (long_name='autocorrelation technology shock')
rho_x ${\rho_{x}}$ (long_name='autocorrelation preference shock')
rho_nu ${\rho_{x}}$ (long_name='autocorrelation monetary shock')
;
%---------------------------------------------------------------
% Parametrization, p. 52
%---------------------------------------------------------------
alppha = 0.3;
betta = 0.99;
h = 0.7;
phi = 1;
chix = 0.6;
rho_pi = 1.5;
rho_y = 0.2;
rho_r = 0.8;
epsilon = 6;
theta = 0.6;
rho_a = 0.8;
rho_x = 0.5;
rho_nu = 0.4;
%---------------------------------------------------------------
% First Order Conditions
%---------------------------------------------------------------
model(linear);
//1. F.O.C. consumption for Households
lam*(1-(h*betta)) = x-((c-(h*c(-1)))*(1/(1-h)))-(h*betta*x(+1))+((c(+1)-(h*c))*((h*betta)/(1-h)));
//2. F.O.C. leisure for Households
phi*n=lam+w;
//3. F.O.C. bonds for Households
0=lam(+1)-lam+r-pi(+1);
//4. Average marginal cost
mc=w+(y*(alppha/(1-alppha)))-(a*(1/(1-alppha)));
//5. First auxiliary variable
pi=((betta/(1+(betta*chix)))*pi(+1))+((chix/(1+(betta*chix)))*pi(-1))+((mc-(e*(1/(epsilon-1))))*(((1-theta*betta)*(1-theta)*(1-alppha))/((1+betta*chix)*(1-alppha+alppha*epsilon)*theta)));
//8. Natural output
alppha*y_nat=a-((1-alppha)*w)+(((1-alppha)/(epsilon-1))*e);
//9. Taylor Rule
r=(r(-1)*rho_r)+((1-rho_r)*((rho_pi*pi)+(rho_y*y_gap)))+nu;
//10. Definition output gap
y_gap = y-y_nat;
//12. Equilibrium
y=c;
//13. Production function
y=(n*(1-alppha))+a;
//14. TFP shock
a=(rho_a*a(-1))+eps_a;
//15. Preference shock
x=(rho_x*x(-1))+eps_x;
//16. Markup shock
e=((1-epsilon)/epsilon)*eps_e;
//17. Monetary shock
nu=(rho_nu*nu(-1))+eps_nu;
//// Observation equations
//18. Output
y_fd = y;
//19. Wage
w_fd = w;
//20. Interes Rate
r_obs=r;
//21. Inflation
pi_obs=pi;
end;
shocks;
var eps_a= 0.02^2 ;
var eps_nu= 0.04^2;
var eps_x= 0.02^2;
var eps_e= 0.2^2;
end;
stoch_simul(order=1,periods=200,irf=0) y_fd w_fd r_obs pi_obs;
datatomfile('observables_gali2_filt_119',char('y_fd','w_fd','r_obs','pi_obs'));
varobs y_fd w_fd r_obs pi_obs;
estimated_params;
alppha, 0.3, 0, 1,beta_pdf, 0.3, 0.05;
h, 0.7, 0, 1,beta_pdf, 0.33, 0.15;
phi, 1, , ,gamma_pdf, 1.17, 0.351;
chix, 0.6, 0, 1, beta_pdf, 0.61, 0.112;
rho_pi, 1.5, 0, 10, normal_pdf, 1.5, 0.2;
rho_y, 0.2, 0, 10, normal_pdf, 0.2, 0.1;
theta, 0.6, 0, 1, beta_pdf, 0.61, 0.112;
rho_a, 0.7, 0, 1, beta_pdf, 0.61, 0.112;
rho_x, 0.5, 0, 1, beta_pdf, 0.61, 0.112;
rho_nu, 0.4, 0, 1, beta_pdf, 0.61, 0.112;
stderr eps_a, inv_gamma_pdf, 0.1, 2;
stderr eps_nu, inv_gamma_pdf, 0.1, 2;
stderr eps_x, inv_gamma_pdf, 0.1, 2;
stderr eps_e, inv_gamma_pdf, 0.1, 2;
end;
estimated_params_init;
alppha, 0.3;
h, 0.7;
phi, 1;
chix, 0.6;
rho_pi, 1.5;
rho_y, 0.2;
theta, 0.6;
rho_a, 0.7;
rho_x, 0.5;
rho_nu, 0.4;
stderr eps_a, 0.02;
stderr eps_nu, 0.04;
stderr eps_x, 0.02;
stderr eps_e, 0.2;
end;
%identification;
estimation(datafile=observables_gali2_filt_119,mh_replic=2000,mh_nblocks=1, mode_compute=4) y_fd w_fd y;
save temp;
// options_.selected_variables_only=0;
shock_decomposition(parameter_set=posterior_mean) y y_fd;
```
The best solution seems to be making the `options_` structure local to `evaluate_smoother` (related to #1197 ) and then set `options_.selected_variables_only=0` in `shock_decomposition.m`https://git.dynare.org/Dynare/dynare/-/issues/1344Investigate whether recent mex-changes broke backward compatibility with olde...2019-06-19T15:37:45ZJohannes Pfeifer Investigate whether recent mex-changes broke backward compatibility with older Matlab versionsGiovanni Lombardo reports a compilation error under Ubuntu with Matlab 2010a:
```
error: unknown type name ‘char16_t’
typedef char16_t mxChar;
```
(see http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=11556).
The post at http://stackoverflow.com/questions/22367516/mex-compile-error-unknown-type-name-char16-t
suggests that one might need to add
`typedef uint16_t char16_t;`
before
`#include "mex.h"`
Giovanni Lombardo reports a compilation error under Ubuntu with Matlab 2010a:
```
error: unknown type name ‘char16_t’
typedef char16_t mxChar;
```
(see http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=11556).
The post at http://stackoverflow.com/questions/22367516/mex-compile-error-unknown-type-name-char16-t
suggests that one might need to add
`typedef uint16_t char16_t;`
before
`#include "mex.h"`
https://git.dynare.org/Dynare/dynare/-/issues/1339bug in missing_DiffuseKalmanSmootherH3_Z.m?2019-06-19T15:37:45ZMichelJuillardbug in missing_DiffuseKalmanSmootherH3_Z.m?@JohannesPfeifer I don't see how line 302
```
Linf = eye(mm) - Kinf(:,i,t)'/Finf(i,t);
```
can be correct. The term before - is a square matrix and the term after, a row vector@JohannesPfeifer I don't see how line 302
```
Linf = eye(mm) - Kinf(:,i,t)'/Finf(i,t);
```
can be correct. The term before - is a square matrix and the term after, a row vector4.5Johannes Pfeifer Johannes Pfeifer