dynare issueshttps://git.dynare.org/Dynare/dynare/issues2019-07-05T12:16:40Zhttps://git.dynare.org/Dynare/dynare/issues/1626Dynare++ Program killed by itself2019-07-05T12:16:40ZStéphane Adjemianstepan@adjemian.euDynare++ Program killed by itself*Created by: awindbells*
I am solving a large model. The model is solved successfully on Mac up to 5th order approximation. When I try solve the model on Windows, or Linux server, it solves 3rd order in seconds, the program is "killed" by the system or by the program at 4th order after a few seconds of running. The cpu utilization is below 40% when killed, and memory usage is minimal. There is no other error message, except "killed" at the end. There is no issue solving a small model up to 5th on windows or linux. I would appreciate any explanations, remedies, or suggestions. Thanks.
*Created by: awindbells*
I am solving a large model. The model is solved successfully on Mac up to 5th order approximation. When I try solve the model on Windows, or Linux server, it solves 3rd order in seconds, the program is "killed" by the system or by the program at 4th order after a few seconds of running. The cpu utilization is below 40% when killed, and memory usage is minimal. There is no other error message, except "killed" at the end. There is no issue solving a small model up to 5th on windows or linux. I would appreciate any explanations, remedies, or suggestions. Thanks.
Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1614Identification display bug2018-09-10T12:35:46ZStéphane Adjemianstepan@adjemian.euIdentification display bug*Created by: wmutschl*
Hi @rattoma , I just noticed a bug in the identification toolbox when only checking for unidentified parameters without any other parameters, as Dynare prints that all parameters are identified even though the figures etc do not suggest so. This is probably just a small bug in the display function.
To replicate the bug (I use Dynare unstable from June, 3 and Matlab R2017b):
1) Open kim2.mod in the test files for identification
2) Change
>estimated_params;
alph ,uniform_pdf,0.6,0.04,0.5,0.7;
//betae ,uniform_pdf,0.99,0.004,0.98,1;
//delta ,uniform_pdf,0.0125,0.001,0.01,0.015;
phi ,uniform_pdf,0.5,0.2,0,10;
theta ,uniform_pdf,0.3,0.1,0,10;
dumpy ,uniform_pdf,0.5,0.2,0,10;
end;
to
> estimated_params;
//alph ,uniform_pdf,0.6,0.04,0.5,0.7;
//betae ,uniform_pdf,0.99,0.004,0.98,1;
//delta ,uniform_pdf,0.0125,0.001,0.01,0.015;
phi ,uniform_pdf,0.5,0.2,0,10;
theta ,uniform_pdf,0.3,0.1,0,10;
//dumpy ,uniform_pdf,0.5,0.2,0,10;
end;
That is, only include colinear parameters.
3) Run "dynare kim2" and the output is
>==== Identification analysis ====
Testing prior mean
Evaluating simulated moment uncertainty ... please wait
Doing 100 replicas of length 300 periods.
Simulated moment uncertainty ... done!
All parameters are identified in the model (rank of H).
All parameters are identified by J moments (rank of J)
Press ENTER to print advanced diagnostics
Collinearity patterns with 1 parameter(s)
Parameter [ Expl. params ] cosn
phi [ theta ] 1.0000000
theta [ phi ] 1.0000000
Press ENTER to plot advanced diagnostics
==== Identification analysis completed ====
which is contradicting. If one includes e.g. dumpy or alpha (or both or any other parameter) in the estimated_params section, dynare correctly displays you that [phi;theta] are colinear and not identified.*Created by: wmutschl*
Hi @rattoma , I just noticed a bug in the identification toolbox when only checking for unidentified parameters without any other parameters, as Dynare prints that all parameters are identified even though the figures etc do not suggest so. This is probably just a small bug in the display function.
To replicate the bug (I use Dynare unstable from June, 3 and Matlab R2017b):
1) Open kim2.mod in the test files for identification
2) Change
>estimated_params;
alph ,uniform_pdf,0.6,0.04,0.5,0.7;
//betae ,uniform_pdf,0.99,0.004,0.98,1;
//delta ,uniform_pdf,0.0125,0.001,0.01,0.015;
phi ,uniform_pdf,0.5,0.2,0,10;
theta ,uniform_pdf,0.3,0.1,0,10;
dumpy ,uniform_pdf,0.5,0.2,0,10;
end;
to
> estimated_params;
//alph ,uniform_pdf,0.6,0.04,0.5,0.7;
//betae ,uniform_pdf,0.99,0.004,0.98,1;
//delta ,uniform_pdf,0.0125,0.001,0.01,0.015;
phi ,uniform_pdf,0.5,0.2,0,10;
theta ,uniform_pdf,0.3,0.1,0,10;
//dumpy ,uniform_pdf,0.5,0.2,0,10;
end;
That is, only include colinear parameters.
3) Run "dynare kim2" and the output is
>==== Identification analysis ====
Testing prior mean
Evaluating simulated moment uncertainty ... please wait
Doing 100 replicas of length 300 periods.
Simulated moment uncertainty ... done!
All parameters are identified in the model (rank of H).
All parameters are identified by J moments (rank of J)
Press ENTER to print advanced diagnostics
Collinearity patterns with 1 parameter(s)
Parameter [ Expl. params ] cosn
phi [ theta ] 1.0000000
theta [ phi ] 1.0000000
Press ENTER to plot advanced diagnostics
==== Identification analysis completed ====
which is contradicting. If one includes e.g. dumpy or alpha (or both or any other parameter) in the estimated_params section, dynare correctly displays you that [phi;theta] are colinear and not identified.https://git.dynare.org/Dynare/dynare/issues/1625Discuss implementing a steady_state_relation-block2019-12-03T14:19:24ZJohannes Pfeifer Discuss implementing a steady_state_relation-blockSteady state finding in large economic models is hard. Currently, the user needs to manually implement a full steady state or reduce the problem and then call a solver. See e.g. https://forum.dynare.org/t/how-to-solve-steady-state-in-large-scale-dsge-models/12185/2
I wonder if it would be useful and feasible to introduce something like a `steady_state_relation`-block that allows specifying analytical steady state relations that Dynare could use in the `_static`-file to substitute out some variable and thus reduce the size of the problem (essentially introducing a model-local variable for the static model). An example would be
```
steady_state_relation;
u=1;
R=1/beta;
Pi=1;
i_nom=R*Pi;
I=delta*K;
end;
```
Combined with `initval` this would make finding a steady state much easier.Steady state finding in large economic models is hard. Currently, the user needs to manually implement a full steady state or reduce the problem and then call a solver. See e.g. https://forum.dynare.org/t/how-to-solve-steady-state-in-large-scale-dsge-models/12185/2
I wonder if it would be useful and feasible to introduce something like a `steady_state_relation`-block that allows specifying analytical steady state relations that Dynare could use in the `_static`-file to substitute out some variable and thus reduce the size of the problem (essentially introducing a model-local variable for the static model). An example would be
```
steady_state_relation;
u=1;
R=1/beta;
Pi=1;
i_nom=R*Pi;
I=delta*K;
end;
```
Combined with `initval` this would make finding a steady state much easier.https://git.dynare.org/Dynare/dynare/issues/1612Build failed in Arch Linux2018-09-10T12:35:46ZStéphane Adjemianstepan@adjemian.euBuild failed in Arch Linux*Created by: angelosalton*
Tried to build from 4.5.4 sources (against Octave 4.4.0), with the following error:
```
In file included from ../../../../contrib/ms-sbvar/utilities_dw/include/dw_std.h:23,
from ../../../../contrib/ms-sbvar/switch_dw/switching/dw_switch.c:25:
../../../sources/ms-sbvar/modify_for_mex.h:39:12: fatal error: octave/config.h: File or folder not found
# include <octave/config.h>
^~~~~~~~~~~~~~~~~
compilation terminated.
```
I'm pretty sure all necessary dependencies are met. I wonder if a header file for Octave is missing.
*Created by: angelosalton*
Tried to build from 4.5.4 sources (against Octave 4.4.0), with the following error:
```
In file included from ../../../../contrib/ms-sbvar/utilities_dw/include/dw_std.h:23,
from ../../../../contrib/ms-sbvar/switch_dw/switching/dw_switch.c:25:
../../../sources/ms-sbvar/modify_for_mex.h:39:12: fatal error: octave/config.h: File or folder not found
# include <octave/config.h>
^~~~~~~~~~~~~~~~~
compilation terminated.
```
I'm pretty sure all necessary dependencies are met. I wonder if a header file for Octave is missing.
Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1622Fix posterior_sampler_initialization>set_proposal_density_to_previous_value2019-09-07T05:27:10ZJohannes Pfeifer Fix posterior_sampler_initialization>set_proposal_density_to_previous_valueIn case of the `record`-structure not containing the required fields, the output argument of the private function at the bottom of the file are not set, crashing Matlab.In case of the `record`-structure not containing the required fields, the output argument of the private function at the bottom of the file are not set, crashing Matlab.https://git.dynare.org/Dynare/dynare/issues/1611Make dynare_sensitivity compatible with recursive estimation or provide infor...2018-11-08T09:59:51ZJohannes Pfeifer Make dynare_sensitivity compatible with recursive estimation or provide informative errorSee https://forum.dynare.org/t/calculating-rmses/11903 See https://forum.dynare.org/t/calculating-rmses/11903 https://git.dynare.org/Dynare/dynare/issues/1604dynare.org down (just http and https)2018-09-10T12:35:46ZStéphane Adjemianstepan@adjemian.eudynare.org down (just http and https)*Created by: tpapp*
```sh
$ nslookup dynare.org
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: dynare.org
Address: 92.243.14.31
$ ping dynare.org
PING dynare.org (92.243.14.31) 56(84) bytes of data.
64 bytes from kirikou.cepremap.org (92.243.14.31): icmp_seq=1 ttl=48 time=46.9 ms
64 bytes from kirikou.cepremap.org (92.243.14.31): icmp_seq=2 ttl=48 time=46.6 ms
64 bytes from kirikou.cepremap.org (92.243.14.31): icmp_seq=3 ttl=48 time=45.5 ms
^C
--- dynare.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 45.578/46.415/46.991/0.655 ms
$ wget dynare.org
--2018-04-11 12:57:51-- http://dynare.org/
Resolving dynare.org (dynare.org)... 92.243.14.31
Connecting to dynare.org (dynare.org)|92.243.14.31|:80... failed: Connection refused.
$ wget https://dynare.org
--2018-04-11 12:58:22-- https://dynare.org/
Resolving dynare.org (dynare.org)... 92.243.14.31
Connecting to dynare.org (dynare.org)|92.243.14.31|:443... failed: Connection refused.
```*Created by: tpapp*
```sh
$ nslookup dynare.org
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: dynare.org
Address: 92.243.14.31
$ ping dynare.org
PING dynare.org (92.243.14.31) 56(84) bytes of data.
64 bytes from kirikou.cepremap.org (92.243.14.31): icmp_seq=1 ttl=48 time=46.9 ms
64 bytes from kirikou.cepremap.org (92.243.14.31): icmp_seq=2 ttl=48 time=46.6 ms
64 bytes from kirikou.cepremap.org (92.243.14.31): icmp_seq=3 ttl=48 time=45.5 ms
^C
--- dynare.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 45.578/46.415/46.991/0.655 ms
$ wget dynare.org
--2018-04-11 12:57:51-- http://dynare.org/
Resolving dynare.org (dynare.org)... 92.243.14.31
Connecting to dynare.org (dynare.org)|92.243.14.31|:80... failed: Connection refused.
$ wget https://dynare.org
--2018-04-11 12:58:22-- https://dynare.org/
Resolving dynare.org (dynare.org)... 92.243.14.31
Connecting to dynare.org (dynare.org)|92.243.14.31|:443... failed: Connection refused.
```https://git.dynare.org/Dynare/dynare/issues/1610Make estimated_params_init robust to wrongly specified parameters2018-10-25T10:37:22ZJohannes Pfeifer Make estimated_params_init robust to wrongly specified parametersThe file
```
/*
* This file replicates the estimation of the cash in advance model (termed M1
* in the paper) described in Frank Schorfheide (2000): "Loss function-based
* evaluation of DSGE models", Journal of Applied Econometrics, 15(6), 645-670.
*
* The data are in file "fsdat_simul.m", and have been artificially generated.
* They are therefore different from the original dataset used by Schorfheide.
*
* The prior distribution follows the one originally specified in Schorfheide's
* paper, except for parameter rho. In the paper, the elicited beta prior for rho
* implies an asymptote and corresponding prior mode at 0. It is generally
* recommended to avoid this extreme type of prior. Some optimizers, for instance
* mode_compute=12 (Mathworks' particleswarm algorithm) may find a posterior mode
* with rho equal to zero. We lowered the value of the prior standard deviation
* (changing .223 to .100) to remove the asymptote.
*
* The equations are taken from J. Nason and T. Cogley (1994): "Testing the
* implications of long-run neutrality for monetary business cycle models",
* Journal of Applied Econometrics, 9, S37-S70.
* Note that there is an initial minus sign missing in equation (A1), p. S63.
*
* This implementation was originally written by Michel Juillard. Please note that the
* following copyright notice only applies to this Dynare implementation of the
* model.
*/
/*
* Copyright (C) 2004-2017 Dynare Team
*
* This file is part of Dynare.
*
* Dynare is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* Dynare is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with Dynare. If not, see <http://www.gnu.org/licenses/>.
*/
var m P c e W R k d n l gy_obs gp_obs y dA;
varexo e_a e_m;
parameters alp bet gam mst rho psi del;
alp = 0.33;
bet = 0.99;
gam = 0.003;
mst = 1.011;
rho = 0.7;
psi = 0.787;
del = 0.02;
model;
dA = exp(gam+e_a);
log(m) = (1-rho)*log(mst) + rho*log(m(-1))+e_m;
-P/(c(+1)*P(+1)*m)+bet*P(+1)*(alp*exp(-alp*(gam+log(e(+1))))*k^(alp-1)*n(+1)^(1-alp)+(1-del)*exp(-(gam+log(e(+1)))))/(c(+2)*P(+2)*m(+1))=0;
W = l/n;
-(psi/(1-psi))*(c*P/(1-n))+l/n = 0;
R = P*(1-alp)*exp(-alp*(gam+e_a))*k(-1)^alp*n^(-alp)/W;
1/(c*P)-bet*P*(1-alp)*exp(-alp*(gam+e_a))*k(-1)^alp*n^(1-alp)/(m*l*c(+1)*P(+1)) = 0;
c+k = exp(-alp*(gam+e_a))*k(-1)^alp*n^(1-alp)+(1-del)*exp(-(gam+e_a))*k(-1);
P*c = m;
m-1+d = l;
e = exp(e_a);
y = k(-1)^alp*n^(1-alp)*exp(-alp*(gam+e_a));
gy_obs = dA*y/y(-1);
gp_obs = (P/P(-1))*m(-1)/dA;
end;
shocks;
var e_a; stderr 0.014;
var e_m; stderr 0.005;
end;
steady_state_model;
dA = exp(gam);
gst = 1/dA;
m = mst;
khst = ( (1-gst*bet*(1-del)) / (alp*gst^alp*bet) )^(1/(alp-1));
xist = ( ((khst*gst)^alp - (1-gst*(1-del))*khst)/mst )^(-1);
nust = psi*mst^2/( (1-alp)*(1-psi)*bet*gst^alp*khst^alp );
n = xist/(nust+xist);
P = xist + nust;
k = khst*n;
l = psi*mst*n/( (1-psi)*(1-n) );
c = mst/P;
d = l - mst + 1;
y = k^alp*n^(1-alp)*gst^alp;
R = mst/bet;
W = l/n;
ist = y-c;
q = 1 - d;
e = 1;
gp_obs = m/dA;
gy_obs = dA;
end;
steady;
check;
estimated_params;
alp, beta_pdf, 0.356, 0.02;
bet, beta_pdf, 0.993, 0.002;
gam, normal_pdf, 0.0085, 0.003;
mst, normal_pdf, 1.0002, 0.007;
rho, beta_pdf, 0.129, 0.100;
psi, beta_pdf, 0.65, 0.05;
% del, beta_pdf, 0.01, 0.005;
% stderr e_a, inv_gamma_pdf, 0.035449, inf;
stderr e_m, inv_gamma_pdf, 0.008862, inf;
end;
estimated_params_init;
del,0.02;
stderr e_a, 0.01;
corr e_a,e_m, 0.5;
end;
varobs gp_obs gy_obs;
estimation(order=1, datafile=fsdat_simul, nobs=192, loglinear, mh_replic=2000, mh_nblocks=2, mh_jscale=0.8);
```
crashes with a cryptic message, because a correlation is initialized that is not estimated. For structural parameters, there is no error. We should make the behavior informative and consistentThe file
```
/*
* This file replicates the estimation of the cash in advance model (termed M1
* in the paper) described in Frank Schorfheide (2000): "Loss function-based
* evaluation of DSGE models", Journal of Applied Econometrics, 15(6), 645-670.
*
* The data are in file "fsdat_simul.m", and have been artificially generated.
* They are therefore different from the original dataset used by Schorfheide.
*
* The prior distribution follows the one originally specified in Schorfheide's
* paper, except for parameter rho. In the paper, the elicited beta prior for rho
* implies an asymptote and corresponding prior mode at 0. It is generally
* recommended to avoid this extreme type of prior. Some optimizers, for instance
* mode_compute=12 (Mathworks' particleswarm algorithm) may find a posterior mode
* with rho equal to zero. We lowered the value of the prior standard deviation
* (changing .223 to .100) to remove the asymptote.
*
* The equations are taken from J. Nason and T. Cogley (1994): "Testing the
* implications of long-run neutrality for monetary business cycle models",
* Journal of Applied Econometrics, 9, S37-S70.
* Note that there is an initial minus sign missing in equation (A1), p. S63.
*
* This implementation was originally written by Michel Juillard. Please note that the
* following copyright notice only applies to this Dynare implementation of the
* model.
*/
/*
* Copyright (C) 2004-2017 Dynare Team
*
* This file is part of Dynare.
*
* Dynare is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* Dynare is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with Dynare. If not, see <http://www.gnu.org/licenses/>.
*/
var m P c e W R k d n l gy_obs gp_obs y dA;
varexo e_a e_m;
parameters alp bet gam mst rho psi del;
alp = 0.33;
bet = 0.99;
gam = 0.003;
mst = 1.011;
rho = 0.7;
psi = 0.787;
del = 0.02;
model;
dA = exp(gam+e_a);
log(m) = (1-rho)*log(mst) + rho*log(m(-1))+e_m;
-P/(c(+1)*P(+1)*m)+bet*P(+1)*(alp*exp(-alp*(gam+log(e(+1))))*k^(alp-1)*n(+1)^(1-alp)+(1-del)*exp(-(gam+log(e(+1)))))/(c(+2)*P(+2)*m(+1))=0;
W = l/n;
-(psi/(1-psi))*(c*P/(1-n))+l/n = 0;
R = P*(1-alp)*exp(-alp*(gam+e_a))*k(-1)^alp*n^(-alp)/W;
1/(c*P)-bet*P*(1-alp)*exp(-alp*(gam+e_a))*k(-1)^alp*n^(1-alp)/(m*l*c(+1)*P(+1)) = 0;
c+k = exp(-alp*(gam+e_a))*k(-1)^alp*n^(1-alp)+(1-del)*exp(-(gam+e_a))*k(-1);
P*c = m;
m-1+d = l;
e = exp(e_a);
y = k(-1)^alp*n^(1-alp)*exp(-alp*(gam+e_a));
gy_obs = dA*y/y(-1);
gp_obs = (P/P(-1))*m(-1)/dA;
end;
shocks;
var e_a; stderr 0.014;
var e_m; stderr 0.005;
end;
steady_state_model;
dA = exp(gam);
gst = 1/dA;
m = mst;
khst = ( (1-gst*bet*(1-del)) / (alp*gst^alp*bet) )^(1/(alp-1));
xist = ( ((khst*gst)^alp - (1-gst*(1-del))*khst)/mst )^(-1);
nust = psi*mst^2/( (1-alp)*(1-psi)*bet*gst^alp*khst^alp );
n = xist/(nust+xist);
P = xist + nust;
k = khst*n;
l = psi*mst*n/( (1-psi)*(1-n) );
c = mst/P;
d = l - mst + 1;
y = k^alp*n^(1-alp)*gst^alp;
R = mst/bet;
W = l/n;
ist = y-c;
q = 1 - d;
e = 1;
gp_obs = m/dA;
gy_obs = dA;
end;
steady;
check;
estimated_params;
alp, beta_pdf, 0.356, 0.02;
bet, beta_pdf, 0.993, 0.002;
gam, normal_pdf, 0.0085, 0.003;
mst, normal_pdf, 1.0002, 0.007;
rho, beta_pdf, 0.129, 0.100;
psi, beta_pdf, 0.65, 0.05;
% del, beta_pdf, 0.01, 0.005;
% stderr e_a, inv_gamma_pdf, 0.035449, inf;
stderr e_m, inv_gamma_pdf, 0.008862, inf;
end;
estimated_params_init;
del,0.02;
stderr e_a, 0.01;
corr e_a,e_m, 0.5;
end;
varobs gp_obs gy_obs;
estimation(order=1, datafile=fsdat_simul, nobs=192, loglinear, mh_replic=2000, mh_nblocks=2, mh_jscale=0.8);
```
crashes with a cryptic message, because a correlation is initialized that is not estimated. For structural parameters, there is no error. We should make the behavior informative and consistent4.6Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/issues/1599octave option requires -std-c++142018-09-10T12:35:46ZStéphane Adjemianstepan@adjemian.euoctave option requires -std-c++14*Created by: yurivict*
dynare fails to build without -std-c++14 now after octave update.
Found in the FreeBSD port.
*Created by: yurivict*
dynare fails to build without -std-c++14 now after octave update.
Found in the FreeBSD port.
Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1606Fix bug or document behavior of mcp2019-04-26T18:17:04ZJohannes Pfeifer Fix bug or document behavior of mcpSee https://forum.dynare.org/t/perfect-foresight-simulation-failed/11638/5See https://forum.dynare.org/t/perfect-foresight-simulation-failed/11638/5Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1621Apparent bug with empty strings in 4.6-unstable-474556e0ca6a3b24638d69c883ce2...2018-09-10T12:35:46ZTom HoldenApparent bug with empty strings in 4.6-unstable-474556e0ca6a3b24638d69c883ce255886268adfI was trying to test this build: https://dynare.adjemian.eu/dynare-4.6-unstable-474556e-win.exe
as instructed in this issue thread: https://github.com/DynareTeam/dynare/issues/1490
The example I found the aforementioned issue on previously included some empty strings. In this Dynare Unstable, these seem to result in an incorrect pre-processor error.
Saving the following three lines is a MOD file generates a pre-processor error in this version:
@#define StringArray = ""
parameters p;
p = 1;
However, if you put something inside the double quotes, it runs fine. It also runs fine on Dynare 4.5.5 even with the empty string.
I was trying to test this build: https://dynare.adjemian.eu/dynare-4.6-unstable-474556e-win.exe
as instructed in this issue thread: https://github.com/DynareTeam/dynare/issues/1490
The example I found the aforementioned issue on previously included some empty strings. In this Dynare Unstable, these seem to result in an incorrect pre-processor error.
Saving the following three lines is a MOD file generates a pre-processor error in this version:
@#define StringArray = ""
parameters p;
p = 1;
However, if you put something inside the double quotes, it runs fine. It also runs fine on Dynare 4.5.5 even with the empty string.
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1605Better document behavior of steady_state operator2018-09-10T12:35:46ZJohannes Pfeifer Better document behavior of steady_state operatorSee https://forum.dynare.org/t/steady-state-command-in-perfect-foresight-simulations/11632/3See https://forum.dynare.org/t/steady-state-command-in-perfect-foresight-simulations/11632/3https://git.dynare.org/Dynare/dynare/issues/1603Investigate whether var_exo_det works correctly with stoch_simul2019-11-26T16:28:38ZJohannes Pfeifer Investigate whether var_exo_det works correctly with stoch_simulSee https://forum.dynare.org/t/varexo-det-to-simulate-random-shocks-during-a-predetermined-period/11637
It seems there is at least one call to `make_ex_` missingSee https://forum.dynare.org/t/varexo-det-to-simulate-random-shocks-during-a-predetermined-period/11637
It seems there is at least one call to `make_ex_` missing4.7https://git.dynare.org/Dynare/dynare/issues/1616Fix perfect_foresight_solver with lags and leads on exogenous variables2018-09-10T12:35:46ZJohannes Pfeifer Fix perfect_foresight_solver with lags and leads on exogenous variablesThe following modification of our test-file where the shock is now `EfficiencyInnovation(-2)` instead of contemporaneous does not work, despite us already being at the solution with `histval`:
```
var Capital, Output, Labour, Consumption, Efficiency, efficiency, ExpectedTerm;
varexo EfficiencyInnovation;
parameters beta, theta, tau, alpha, psi, delta, rho, effstar, sigma2;
beta = 0.9900;
theta = 0.3570;
tau = 2.0000;
alpha = 0.4500;
psi = -0.1000;
delta = 0.0200;
rho = 0.8000;
effstar = 1.0000;
sigma2 = 0;
model;
// Eq. nÂ°1:
efficiency = rho*efficiency(-1) + EfficiencyInnovation(-2);
// Eq. nÂ°2:
Efficiency = effstar*exp(efficiency);
// Eq. nÂ°3:
Output = Efficiency*(alpha*(Capital(-1)^psi)+(1-alpha)*(Labour^psi))^(1/psi);
// Eq. nÂ°4:
Capital = Output-Consumption + (1-delta)*Capital(-1);
// Eq. nÂ°5:
((1-theta)/theta)*(Consumption/(1-Labour)) - (1-alpha)*(Output/Labour)^(1-psi);
// Eq. nÂ°6:
(((Consumption^theta)*((1-Labour)^(1-theta)))^(1-tau))/Consumption = ExpectedTerm(1);
// Eq. nÂ°7:
ExpectedTerm = beta*((((Consumption^theta)*((1-Labour)^(1-theta)))^(1-tau))/Consumption)*(alpha*((Output/Capital(-1))^(1-psi))+(1-delta));
end;
steady_state_model;
efficiency = EfficiencyInnovation/(1-rho);
Efficiency = effstar*exp(efficiency);
Output_per_unit_of_Capital=((1/beta-1+delta)/alpha)^(1/(1-psi));
Consumption_per_unit_of_Capital=Output_per_unit_of_Capital-delta;
Labour_per_unit_of_Capital=(((Output_per_unit_of_Capital/Efficiency)^psi-alpha)/(1-alpha))^(1/psi);
Output_per_unit_of_Labour=Output_per_unit_of_Capital/Labour_per_unit_of_Capital;
Consumption_per_unit_of_Labour=Consumption_per_unit_of_Capital/Labour_per_unit_of_Capital;
% Compute steady state share of capital.
ShareOfCapital=alpha/(alpha+(1-alpha)*Labour_per_unit_of_Capital^psi);
% Compute steady state of the endogenous variables.
Labour=1/(1+Consumption_per_unit_of_Labour/((1-alpha)*theta/(1-theta)*Output_per_unit_of_Labour^(1-psi)));
Consumption=Consumption_per_unit_of_Labour*Labour;
Capital=Labour/Labour_per_unit_of_Capital;
Output=Output_per_unit_of_Capital*Capital;
ExpectedTerm=beta*((((Consumption^theta)*((1-Labour)^(1-theta)))^(1-tau))/Consumption)
*(alpha*((Output/Capital)^(1-psi))+1-delta);
end;
steady;
ik = varlist_indices('Capital',M_.endo_names);
CapitalSS = oo_.steady_state(ik);
histval;
Capital(0) = CapitalSS;
end;
perfect_foresight_setup(periods=200);
perfect_foresight_solver(stack_solve_algo=7,solve_algo=1);
if ~oo_.deterministic_simulation.status
error('Perfect foresight simulation failed')
end
rplot Consumption;
rplot Capital;
D = load('rbc_det_results');
if norm(D.oo_.endo_simul - oo_.endo_simul) > 1e-30;
disp(norm(D.oo_.endo_simul - oo_.endo_simul));
error('rbc_det_stack_solve_algo_7 failed');
end;
options_.dynatol.f=1e-10;
@#define J = [0,1,2,3,4,9,10]
@#for solve_algo_iter in J
perfect_foresight_setup(periods=200);
perfect_foresight_solver(stack_solve_algo=7,solve_algo=@{solve_algo_iter});
if ~oo_.deterministic_simulation.status
error('Perfect foresight simulation failed')
end
rplot Consumption;
rplot Capital;
D = load('rbc_det_results');
if isoctave && options_.solve_algo==0
%%acount for somehow weaker convergence criterion in Octave's fsolve
tol_crit=1e-4;
else
tol_crit=1e-8;
end
if norm(D.oo_.endo_simul - oo_.endo_simul) > tol_crit;
disp(norm(D.oo_.endo_simul - oo_.endo_simul));
error(sprintf('rbc_det_stack_solve_algo_7 failed with solve_algo=%u',options_.solve_algo));
end;
@#endfor
```
This is related to https://github.com/DynareTeam/dynare/commit/8913791ff0972f8a56d6c5d0d325d1cb6fda7189#commitcomment-29281838
We should add the above file with
```
histval;
Capital(0) = CapitalSS/2;
end;
```
to the testsuite. A similar case with a leaded exogenous variable should also be added.The following modification of our test-file where the shock is now `EfficiencyInnovation(-2)` instead of contemporaneous does not work, despite us already being at the solution with `histval`:
```
var Capital, Output, Labour, Consumption, Efficiency, efficiency, ExpectedTerm;
varexo EfficiencyInnovation;
parameters beta, theta, tau, alpha, psi, delta, rho, effstar, sigma2;
beta = 0.9900;
theta = 0.3570;
tau = 2.0000;
alpha = 0.4500;
psi = -0.1000;
delta = 0.0200;
rho = 0.8000;
effstar = 1.0000;
sigma2 = 0;
model;
// Eq. nÂ°1:
efficiency = rho*efficiency(-1) + EfficiencyInnovation(-2);
// Eq. nÂ°2:
Efficiency = effstar*exp(efficiency);
// Eq. nÂ°3:
Output = Efficiency*(alpha*(Capital(-1)^psi)+(1-alpha)*(Labour^psi))^(1/psi);
// Eq. nÂ°4:
Capital = Output-Consumption + (1-delta)*Capital(-1);
// Eq. nÂ°5:
((1-theta)/theta)*(Consumption/(1-Labour)) - (1-alpha)*(Output/Labour)^(1-psi);
// Eq. nÂ°6:
(((Consumption^theta)*((1-Labour)^(1-theta)))^(1-tau))/Consumption = ExpectedTerm(1);
// Eq. nÂ°7:
ExpectedTerm = beta*((((Consumption^theta)*((1-Labour)^(1-theta)))^(1-tau))/Consumption)*(alpha*((Output/Capital(-1))^(1-psi))+(1-delta));
end;
steady_state_model;
efficiency = EfficiencyInnovation/(1-rho);
Efficiency = effstar*exp(efficiency);
Output_per_unit_of_Capital=((1/beta-1+delta)/alpha)^(1/(1-psi));
Consumption_per_unit_of_Capital=Output_per_unit_of_Capital-delta;
Labour_per_unit_of_Capital=(((Output_per_unit_of_Capital/Efficiency)^psi-alpha)/(1-alpha))^(1/psi);
Output_per_unit_of_Labour=Output_per_unit_of_Capital/Labour_per_unit_of_Capital;
Consumption_per_unit_of_Labour=Consumption_per_unit_of_Capital/Labour_per_unit_of_Capital;
% Compute steady state share of capital.
ShareOfCapital=alpha/(alpha+(1-alpha)*Labour_per_unit_of_Capital^psi);
% Compute steady state of the endogenous variables.
Labour=1/(1+Consumption_per_unit_of_Labour/((1-alpha)*theta/(1-theta)*Output_per_unit_of_Labour^(1-psi)));
Consumption=Consumption_per_unit_of_Labour*Labour;
Capital=Labour/Labour_per_unit_of_Capital;
Output=Output_per_unit_of_Capital*Capital;
ExpectedTerm=beta*((((Consumption^theta)*((1-Labour)^(1-theta)))^(1-tau))/Consumption)
*(alpha*((Output/Capital)^(1-psi))+1-delta);
end;
steady;
ik = varlist_indices('Capital',M_.endo_names);
CapitalSS = oo_.steady_state(ik);
histval;
Capital(0) = CapitalSS;
end;
perfect_foresight_setup(periods=200);
perfect_foresight_solver(stack_solve_algo=7,solve_algo=1);
if ~oo_.deterministic_simulation.status
error('Perfect foresight simulation failed')
end
rplot Consumption;
rplot Capital;
D = load('rbc_det_results');
if norm(D.oo_.endo_simul - oo_.endo_simul) > 1e-30;
disp(norm(D.oo_.endo_simul - oo_.endo_simul));
error('rbc_det_stack_solve_algo_7 failed');
end;
options_.dynatol.f=1e-10;
@#define J = [0,1,2,3,4,9,10]
@#for solve_algo_iter in J
perfect_foresight_setup(periods=200);
perfect_foresight_solver(stack_solve_algo=7,solve_algo=@{solve_algo_iter});
if ~oo_.deterministic_simulation.status
error('Perfect foresight simulation failed')
end
rplot Consumption;
rplot Capital;
D = load('rbc_det_results');
if isoctave && options_.solve_algo==0
%%acount for somehow weaker convergence criterion in Octave's fsolve
tol_crit=1e-4;
else
tol_crit=1e-8;
end
if norm(D.oo_.endo_simul - oo_.endo_simul) > tol_crit;
disp(norm(D.oo_.endo_simul - oo_.endo_simul));
error(sprintf('rbc_det_stack_solve_algo_7 failed with solve_algo=%u',options_.solve_algo));
end;
@#endfor
```
This is related to https://github.com/DynareTeam/dynare/commit/8913791ff0972f8a56d6c5d0d325d1cb6fda7189#commitcomment-29281838
We should add the above file with
```
histval;
Capital(0) = CapitalSS/2;
end;
```
to the testsuite. A similar case with a leaded exogenous variable should also be added.https://git.dynare.org/Dynare/dynare/issues/1600look at preprocessor `output` option2018-10-02T14:54:31ZHoutan Bastanilook at preprocessor `output` optionWhat is `dynamic` used for?
Look at printing in `DynareMain2.cc`. Why do we switch on `output_mode` ?What is `dynamic` used for?
Look at printing in `DynareMain2.cc`. Why do we switch on `output_mode` ?Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1609Fix bug in mjdgges.mex2018-09-10T12:35:46ZJohannes Pfeifer Fix bug in mjdgges.mexSee email from 04/22/18.
```[err, ss, tt, w, sdim, dr.eigval, info1] = mjdgges(E, D, DynareOptions.qz_criterium, DynareOptions.qz_zero_threshold);```
returns ```sdim=6.``` However, manually computing `sdim` based on the returned `dr.eigval` via
```
sum(abs(dr.eigval) < DynareOptions.qz_criterium)
```
returns 8.
See email from 04/22/18.
```[err, ss, tt, w, sdim, dr.eigval, info1] = mjdgges(E, D, DynareOptions.qz_criterium, DynareOptions.qz_zero_threshold);```
returns ```sdim=6.``` However, manually computing `sdim` based on the returned `dr.eigval` via
```
sum(abs(dr.eigval) < DynareOptions.qz_criterium)
```
returns 8.
https://git.dynare.org/Dynare/dynare/issues/1597Accept UTF-8 in .mod file2018-09-10T12:35:46ZHoutan BastaniAccept UTF-8 in .mod fileHoutan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1608Fix forecast at order=2 with linear model and varexo_det2018-09-10T12:35:46ZJohannes Pfeifer Fix forecast at order=2 with linear model and varexo_detThe mod-file
```
var y, pi, i, g, u, k;
varexo e_g e_u e_k;
varexo_det gov;
parameters lambda, pi_target, y_target, phi_pi, phi, rho, rhoout, rhopi, rhoint, sigma1, sigma2, sigma3;
lambda = 0.3;
pi_target = 0;
y_target = 0;
phi_pi = 1.5;
phi = 1;
rho = 0.99;
T = 50;
rhoout = 0.8;
rhopi = 0.5;
rhoint = 0;
sigma1 = 1;
sigma2 = 1;
sigma3 = 1;
model(linear);
y=y(+1)-phi*(i-pi(+1))+gov+g;
pi=lambda*y+rho*pi(+1)+u;
i=phi_pi*(pi-pi_target)+k;
g=rhoout*g(-1)+e_g;
u=rhopi*u(-1)+e_u;
k=rhoint*k(-1)+e_k;
end;
steady;
check;
shocks;
var e_g;
stderr sigma1;
var e_u;
stderr sigma2;
var e_k;
stderr sigma3;
var gov;
periods 1:9;
values 0.2;
end;
stoch_simul(irf=0);
forecast;
```
crashes, because `forecast` relies on the original `options_.order` and the precomputed decision rules. But given the linear model, `stoch_simul` used `order=1`. Thus, the default does not work anymore.The mod-file
```
var y, pi, i, g, u, k;
varexo e_g e_u e_k;
varexo_det gov;
parameters lambda, pi_target, y_target, phi_pi, phi, rho, rhoout, rhopi, rhoint, sigma1, sigma2, sigma3;
lambda = 0.3;
pi_target = 0;
y_target = 0;
phi_pi = 1.5;
phi = 1;
rho = 0.99;
T = 50;
rhoout = 0.8;
rhopi = 0.5;
rhoint = 0;
sigma1 = 1;
sigma2 = 1;
sigma3 = 1;
model(linear);
y=y(+1)-phi*(i-pi(+1))+gov+g;
pi=lambda*y+rho*pi(+1)+u;
i=phi_pi*(pi-pi_target)+k;
g=rhoout*g(-1)+e_g;
u=rhopi*u(-1)+e_u;
k=rhoint*k(-1)+e_k;
end;
steady;
check;
shocks;
var e_g;
stderr sigma1;
var e_u;
stderr sigma2;
var e_k;
stderr sigma3;
var gov;
periods 1:9;
values 0.2;
end;
stoch_simul(irf=0);
forecast;
```
crashes, because `forecast` relies on the original `options_.order` and the precomputed decision rules. But given the linear model, `stoch_simul` used `order=1`. Thus, the default does not work anymore.Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1596add maximum lag info by variable2019-09-25T08:27:04ZHoutan Bastaniadd maximum lag info by variable```
M_.maximum_endo_lag_by_var = [ ... ];
M_.maximum_exo_lag_by_var = [ ... ];
```
Where the vectors are the length of `M_.orig_endo_nbr````
M_.maximum_endo_lag_by_var = [ ... ];
M_.maximum_exo_lag_by_var = [ ... ];
```
Where the vectors are the length of `M_.orig_endo_nbr`Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1607Fix prior sampler2018-09-10T12:35:46ZJohannes Pfeifer Fix prior sampler`prior simulate` in `cli/prior.m` calls
```
results = prior_sampler(0, Model, BayesOptions, options_, oo_, EstimatedParams);
```
where the 0 indicates that no decision rules need to be saved. The problem is that this flag `drsave` is then used to call `resol` with
```
work = ~drsave;
[dr,INFO,M_,options_,oo_] = resol(work,M_,options_,oo_);
```
so that `resol` only computes eigenvalue, but not BK conditions etc. As a result, the reported simulations will never fail the BK conditions. See https://forum.dynare.org/t/determinacy-prior-simulate-puzzle/11681
`prior simulate` in `cli/prior.m` calls
```
results = prior_sampler(0, Model, BayesOptions, options_, oo_, EstimatedParams);
```
where the 0 indicates that no decision rules need to be saved. The problem is that this flag `drsave` is then used to call `resol` with
```
work = ~drsave;
[dr,INFO,M_,options_,oo_] = resol(work,M_,options_,oo_);
```
so that `resol` only computes eigenvalue, but not BK conditions etc. As a result, the reported simulations will never fail the BK conditions. See https://forum.dynare.org/t/determinacy-prior-simulate-puzzle/11681
https://git.dynare.org/Dynare/dynare/issues/1602Fix predetermined_variables command with model-local variables2018-11-12T16:16:12ZJohannes Pfeifer Fix predetermined_variables command with model-local variablesThe mod-file
```
@#define predet=1
var K q;
@#if predet
predetermined_variables K;
@#endif
parameters
a b delta r alpha dt
K_inf q_inf;
a=1;
b=1;
delta = 0.023;
alpha = 0.33;
r = 0.01;
dt=1;
q_inf = 1+(1+a)*b*delta^a;
K_inf = (((r+delta)*q_inf-a*b*delta^(a+1))/alpha)^(1/(alpha-1));
@#if predet==0
// Model block without predetermined_variables statement
model;
# I = K(-1)*((q-1)/((1+a)*b))^(1/a);
# w = alpha*K(-1)^(alpha-1)+a*b*(I/K(-1))^(a+1);
K = K(-1) + (I-delta*K(-1))*dt;
q(+1) = q + (r+delta)*q*dt - w*dt;
end;
@#else
// Model block with predetermined_variables statement
model;
# I = K*((q-1)/((1+a)*b))^(1/a);
# w = alpha*K^(alpha-1)+a*b*(I/K)^(a+1);
K(+1) = K + (I-delta*K)*dt;
q(+1) = q + (r+delta)*q*dt - w*dt;
end;
@#endif
steady_state_model;
K = K_inf;
q = q_inf;
end;
initval;
K = 20;
q = q_inf;
end;
endval;
K = K_inf;
q = q_inf1;
end;
check;
simul(periods=100, tolx=1e-12, tolf=1e-12, no_homotopy);
# I = K*((q-1)/((1+a)*b))^(1/a);
# w = alpha*K^(alpha-1)+a*b*(I/K)^(a+1);
K(+1) = K + (I-delta*K)*dt;
rplot K;
rplot q;
```
yields wrong results. The relevant parts of the dynamic file corresponding to
```
# I = K*((q-1)/((1+a)*b))^(1/a);
K(+1) = K + (I-delta*K)*dt;
```
are
```
I__ = y(2)*((y(3)-1)/((1+params(1))*params(2)))^(1/params(1));
lhs =y(2);
rhs =y(1)+params(6)*(I__-params(3)*y(1));
```
Here, `y(1)` stores `K` and `y(2)` stores `K(+1)`. As can be seen, in the created model-local variable, the capital stock is not shifted backwards, despite the `predetermined_variables` statement.
Upon fixing this, we should turn the file into a unit test.The mod-file
```
@#define predet=1
var K q;
@#if predet
predetermined_variables K;
@#endif
parameters
a b delta r alpha dt
K_inf q_inf;
a=1;
b=1;
delta = 0.023;
alpha = 0.33;
r = 0.01;
dt=1;
q_inf = 1+(1+a)*b*delta^a;
K_inf = (((r+delta)*q_inf-a*b*delta^(a+1))/alpha)^(1/(alpha-1));
@#if predet==0
// Model block without predetermined_variables statement
model;
# I = K(-1)*((q-1)/((1+a)*b))^(1/a);
# w = alpha*K(-1)^(alpha-1)+a*b*(I/K(-1))^(a+1);
K = K(-1) + (I-delta*K(-1))*dt;
q(+1) = q + (r+delta)*q*dt - w*dt;
end;
@#else
// Model block with predetermined_variables statement
model;
# I = K*((q-1)/((1+a)*b))^(1/a);
# w = alpha*K^(alpha-1)+a*b*(I/K)^(a+1);
K(+1) = K + (I-delta*K)*dt;
q(+1) = q + (r+delta)*q*dt - w*dt;
end;
@#endif
steady_state_model;
K = K_inf;
q = q_inf;
end;
initval;
K = 20;
q = q_inf;
end;
endval;
K = K_inf;
q = q_inf1;
end;
check;
simul(periods=100, tolx=1e-12, tolf=1e-12, no_homotopy);
# I = K*((q-1)/((1+a)*b))^(1/a);
# w = alpha*K^(alpha-1)+a*b*(I/K)^(a+1);
K(+1) = K + (I-delta*K)*dt;
rplot K;
rplot q;
```
yields wrong results. The relevant parts of the dynamic file corresponding to
```
# I = K*((q-1)/((1+a)*b))^(1/a);
K(+1) = K + (I-delta*K)*dt;
```
are
```
I__ = y(2)*((y(3)-1)/((1+params(1))*params(2)))^(1/params(1));
lhs =y(2);
rhs =y(1)+params(6)*(I__-params(3)*y(1));
```
Here, `y(1)` stores `K` and `y(2)` stores `K(+1)`. As can be seen, in the created model-local variable, the capital stock is not shifted backwards, despite the `predetermined_variables` statement.
Upon fixing this, we should turn the file into a unit test.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1593Add truncated priors2018-11-08T10:09:48ZJohannes Pfeifer Add truncated priorsFollowing the discussions in #1591 and #750, we currently do not have a way to introduce a proper truncated prior. But this is an often requested feature thta e.g. @rattoma would like to have. Waiting for the new estimation interface (e.g. #824 and #846) seems to long to wait.
My specific proposal would be to add a new token `truncated_norm_pdf` that uses the third and fourth hyperparameter (which is usually reserved for generalized (beta) distributions) to specify the truncation. I consider this a natural interpretation of these hyperparameters for the normal distribution.
@stepan-a What do you think?
@rattoma Woud that satisfy your immediate needs? Or do you need a truncated distribution other than the normal?Following the discussions in #1591 and #750, we currently do not have a way to introduce a proper truncated prior. But this is an often requested feature thta e.g. @rattoma would like to have. Waiting for the new estimation interface (e.g. #824 and #846) seems to long to wait.
My specific proposal would be to add a new token `truncated_norm_pdf` that uses the third and fourth hyperparameter (which is usually reserved for generalized (beta) distributions) to specify the truncation. I consider this a natural interpretation of these hyperparameters for the normal distribution.
@stepan-a What do you think?
@rattoma Woud that satisfy your immediate needs? Or do you need a truncated distribution other than the normal?Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/issues/1601dates: uninformative error message2018-09-10T12:35:46ZMichelJuillarddates: uninformative error messageIn ``dates`` if the date format is not recognized the error message is "You should first read the manual". This isn't helpful. Furthermore, inside Dynare, if this problem occurs in the datafile, there is no reference to the ``dates`` module. In ``dates`` if the date format is not recognized the error message is "You should first read the manual". This isn't helpful. Furthermore, inside Dynare, if this problem occurs in the datafile, there is no reference to the ``dates`` module. https://git.dynare.org/Dynare/dynare/issues/1584Update and potentially fix installation information for mac2018-11-08T11:54:18ZJohannes Pfeifer Update and potentially fix installation information for macSee https://forum.dynare.org/t/installing-dynare-no-longer-available-on-homebrew/11259See https://forum.dynare.org/t/installing-dynare-no-longer-available-on-homebrew/11259Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1567Silent crash when calculating steady state variables of basic economic model2018-09-10T12:35:46ZStéphane Adjemianstepan@adjemian.euSilent crash when calculating steady state variables of basic economic model*Created by: wtpfede*
Hi all,
I'm using Dynarec to reimplement a basic Ramsey model from Ohanian and Cole (1999)
The code is as follows:
```
varexo e; %e are tfp shocks
var y, c, n, k, x, z, i;
parameters theta, beta, rho, delta, gamma, biga;
theta=0.33;
beta=.96;
delta = 0.10;
rho=0.9;
gamma = 0.019;
biga = 0.78;
model;
(1/c) = beta*(1/c(+1))*( 1- delta+ z(+1)*(x(+1)*n(+1))^(1-theta)* theta*(k(+1))^(theta-1)) ;
biga/(1-n)=(1/c)*((1-theta)*z*(k^theta)*(x*n)^(-theta)*x) ;
z=(1-rho)+rho*z(-1)+e ;
i=z*y-c;
k(+1)=i+(1-delta)*k ;
y=(k^theta)*(x*n)^(1-theta) ;
x=(1+gamma)*x(-1) ;
end;
initval;
y = 0.184068;
c = 0.127782;
n = 1/3;
k = 0.0562866;
x = 1;
z = 0.1;
i = 0.0562866;
end;
check;
steady;
```
Unfortunately, Dynarec crashes silently.
All of the parameters and the equations have been double checked by our team, and the numerical values come straight from the original paper.
We are on Octave 4.2.1 and Dynare 4.5.3.
If anyone has any pointers or could confirm this as a bug, this would be extremely helpful.
*Created by: wtpfede*
Hi all,
I'm using Dynarec to reimplement a basic Ramsey model from Ohanian and Cole (1999)
The code is as follows:
```
varexo e; %e are tfp shocks
var y, c, n, k, x, z, i;
parameters theta, beta, rho, delta, gamma, biga;
theta=0.33;
beta=.96;
delta = 0.10;
rho=0.9;
gamma = 0.019;
biga = 0.78;
model;
(1/c) = beta*(1/c(+1))*( 1- delta+ z(+1)*(x(+1)*n(+1))^(1-theta)* theta*(k(+1))^(theta-1)) ;
biga/(1-n)=(1/c)*((1-theta)*z*(k^theta)*(x*n)^(-theta)*x) ;
z=(1-rho)+rho*z(-1)+e ;
i=z*y-c;
k(+1)=i+(1-delta)*k ;
y=(k^theta)*(x*n)^(1-theta) ;
x=(1+gamma)*x(-1) ;
end;
initval;
y = 0.184068;
c = 0.127782;
n = 1/3;
k = 0.0562866;
x = 1;
z = 0.1;
i = 0.0562866;
end;
check;
steady;
```
Unfortunately, Dynarec crashes silently.
All of the parameters and the equations have been double checked by our team, and the numerical values come straight from the original paper.
We are on Octave 4.2.1 and Dynare 4.5.3.
If anyone has any pointers or could confirm this as a bug, this would be extremely helpful.
https://git.dynare.org/Dynare/dynare/issues/1586Document initial_condition_decomposition and make it an official feature2019-12-09T14:54:10ZJohannes Pfeifer Document initial_condition_decomposition and make it an official featureStill missing from https://github.com/DynareTeam/dynare/pull/1421Still missing from https://github.com/DynareTeam/dynare/pull/14214.6https://git.dynare.org/Dynare/dynare/issues/1579Make fast realtime decomposition use the proper nobs2019-12-03T13:56:27ZJohannes Pfeifer Make fast realtime decomposition use the proper nobsSee https://github.com/DynareTeam/dynare/pull/1563#issuecomment-357180435
See https://github.com/DynareTeam/dynare/pull/1563#issuecomment-357180435
4.6https://git.dynare.org/Dynare/dynare/issues/1598Add a routine for setting automajically the value of mh_jscale...2018-09-10T12:35:46ZStéphane Adjemianstepan@adjemian.euAdd a routine for setting automajically the value of mh_jscale...so that the acceptance ratio is close to an arbitrary target.
This already done with `mode_compute=6`, but we need to port to other optimization routines.
so that the acceptance ratio is close to an arbitrary target.
This already done with `mode_compute=6`, but we need to port to other optimization routines.
4.6Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/issues/1576Provide steady state file example for Ramsey2018-11-08T10:12:38ZJohannes Pfeifer Provide steady state file example for RamseyThe final loop should most probably be
```
NumberOfEndogenousVariables = M_.endo_nbr; % Number of endogenous variables.
ys = zeros(NumberOfEndogenousVariables,1); % Initialization of ys (steady state).
for i = M_.ramsey_eq_nbr+1:NumberOfEndogenousVariables % Loop...
varname = deblank(M_.endo_names(i-M_.ramsey_eq_nbr,:)); % Get the name of endogenous variable i.
eval(['ys(' int2str(i) ') = ' varname ';']); % Get the steady state value of this variable.
end % End of the loop.
```The final loop should most probably be
```
NumberOfEndogenousVariables = M_.endo_nbr; % Number of endogenous variables.
ys = zeros(NumberOfEndogenousVariables,1); % Initialization of ys (steady state).
for i = M_.ramsey_eq_nbr+1:NumberOfEndogenousVariables % Loop...
varname = deblank(M_.endo_names(i-M_.ramsey_eq_nbr,:)); % Get the name of endogenous variable i.
eval(['ys(' int2str(i) ') = ' varname ';']); % Get the steady state value of this variable.
end % End of the loop.
```https://git.dynare.org/Dynare/dynare/issues/1587nested @#ifndef and @#ifdef don't work2018-09-10T12:35:46ZHoutan Bastaninested @#ifndef and @#ifdef don't workEmail from @JohannesPfeifer:
If I use
```
@#define risk_sharing = 0
@#if risk_sharing == 0
@#ifndef endogenous_discount_factor
@#define endogenous_discount_factor = 1
@#endif
@#endif
```
In a mod-file, I get an error
```
@#if/@#ifdef/@#ifndef not matched by an @#endif or file does not end with a new line (unexpected end of file)
```Email from @JohannesPfeifer:
If I use
```
@#define risk_sharing = 0
@#if risk_sharing == 0
@#ifndef endogenous_discount_factor
@#define endogenous_discount_factor = 1
@#endif
@#endif
```
In a mod-file, I get an error
```
@#if/@#ifdef/@#ifndef not matched by an @#endif or file does not end with a new line (unexpected end of file)
```4.5.4Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1573Allow mode_compute to be a vector2018-11-08T10:14:12ZJohannes Pfeifer Allow mode_compute to be a vectorAllow `mode_compute` to be a vector and the sequentially execute the mode-finders specified. See e.g. https://forum.dynare.org/t/simulated-annealing-block/11052 for why this may be useful.Allow `mode_compute` to be a vector and the sequentially execute the mode-finders specified. See e.g. https://forum.dynare.org/t/simulated-annealing-block/11052 for why this may be useful.https://git.dynare.org/Dynare/dynare/issues/1588Update Readme for Windows2018-09-10T12:35:46ZJohannes Pfeifer Update Readme for WindowsThe readme has a line linking to a recommended Octave version (https://github.com/DynareTeam/dynare/blob/48b5839414b96c69c0ea0a0da4b129b0195d7dfe/windows/README.txt#L64), which should be 4.2.1, but http://www.dynare.org/download/octave/windows only has downloads for 3.8.1The readme has a line linking to a recommended Octave version (https://github.com/DynareTeam/dynare/blob/48b5839414b96c69c0ea0a0da4b129b0195d7dfe/windows/README.txt#L64), which should be 4.2.1, but http://www.dynare.org/download/octave/windows only has downloads for 3.8.1https://git.dynare.org/Dynare/dynare/issues/1575Fix WriteShockDecomp2Excel.m2019-09-24T11:16:39ZJohannes Pfeifer Fix WriteShockDecomp2Excel.mSee https://forum.dynare.org/t/bug-in-write-xls-option-of-shock-decomposition-after-estimation/11097
On MAC, we rely on `xlwrite` from https://fr.mathworks.com/matlabcentral/fileexchange/38591-xlwrite--generate-xls-x--files-without-excel-on-mac-linux-win without checking whether Excel is installed. If we want to keep this, we need to clearly spell out that users need to install that file. @rattoma What do you think?See https://forum.dynare.org/t/bug-in-write-xls-option-of-shock-decomposition-after-estimation/11097
On MAC, we rely on `xlwrite` from https://fr.mathworks.com/matlabcentral/fileexchange/38591-xlwrite--generate-xls-x--files-without-excel-on-mac-linux-win without checking whether Excel is installed. If we want to keep this, we need to clearly spell out that users need to install that file. @rattoma What do you think?4.6https://git.dynare.org/Dynare/dynare/issues/1544dataset_ is a dseries and no longer a structure2018-09-10T12:35:46ZStéphane Adjemianstepan@adjemian.eudataset_ is a dseries and no longer a structure*Created by: thomasbrand*
The last commits about `dseries` (between October 10th and October 14th) modified the type of the `dataset_` output in `results.mat`. It was previously a matlab structure, and now it is a `dseries`. The consequence is important (for me) because now I need Dynare to read the `dataset_` output.
Was it on purpose or do you think you will go back to a structure ?
Thank you.*Created by: thomasbrand*
The last commits about `dseries` (between October 10th and October 14th) modified the type of the `dataset_` output in `results.mat`. It was previously a matlab structure, and now it is a `dseries`. The consequence is important (for me) because now I need Dynare to read the `dataset_` output.
Was it on purpose or do you think you will go back to a structure ?
Thank you.Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/issues/1565initial condition decomposition2019-11-29T16:06:44ZMarco Rattoinitial condition decompositionit would be useful to add interface for the following options:
```
nodisplay
graph_format
fig_name
```
Moreover, the preprocessor should give a lhs arg oo_ when translating the command, i.e.:
`oo_ = initial_condition_decomposition(M_,oo_,options_,var_list_,bayestopt_,estim_params_);`
so not really new options, but just allow those in the pre-processor. many thanks!it would be useful to add interface for the following options:
```
nodisplay
graph_format
fig_name
```
Moreover, the preprocessor should give a lhs arg oo_ when translating the command, i.e.:
`oo_ = initial_condition_decomposition(M_,oo_,options_,var_list_,bayestopt_,estim_params_);`
so not really new options, but just allow those in the pre-processor. many thanks!4.6https://git.dynare.org/Dynare/dynare/issues/1578macro-processor: allow for nested variables2018-09-10T12:35:46ZJohannes Pfeifer macro-processor: allow for nested variables1. Related to https://forum.dynare.org/t/total-number-of-periods-given-by-variable/11200/3
We should allow
```
@#define J=10
@#define K=1:@{J}
```
but currently the lexer gives an error when encountering the `@{J}` in the second line.
2. Related to this, according to the manual, we have at the command line
```-DMACRO_VARIABLE=MACRO_EXPRESSION```
But we do not really macro expressions as
`dynare macro.mod -D=[1,2]`
fails.
3. I tried to get around this by using
```
n_countries=2;
fid=fopen('n_countries_def.txt','w+');
fprintf(fid,'@#for co in 1:%u\n',n_countries)
fclose(fid)
```
to write a text file creating the first statement and then using
```
@#include "n_countries_def.txt"
var C_@{co};
@#endfor
```
But this is also not allowed:
```
ERROR in macro-processor: n_countries_def.txt:1.15: @#for loop not matched by an @#endfor or file does not end with a new line (unexpected end of file)
```
because apparently the macro processor checks for completeness of the macro in each included file instead of the whole created file.
1. Related to https://forum.dynare.org/t/total-number-of-periods-given-by-variable/11200/3
We should allow
```
@#define J=10
@#define K=1:@{J}
```
but currently the lexer gives an error when encountering the `@{J}` in the second line.
2. Related to this, according to the manual, we have at the command line
```-DMACRO_VARIABLE=MACRO_EXPRESSION```
But we do not really macro expressions as
`dynare macro.mod -D=[1,2]`
fails.
3. I tried to get around this by using
```
n_countries=2;
fid=fopen('n_countries_def.txt','w+');
fprintf(fid,'@#for co in 1:%u\n',n_countries)
fclose(fid)
```
to write a text file creating the first statement and then using
```
@#include "n_countries_def.txt"
var C_@{co};
@#endfor
```
But this is also not allowed:
```
ERROR in macro-processor: n_countries_def.txt:1.15: @#for loop not matched by an @#endfor or file does not end with a new line (unexpected end of file)
```
because apparently the macro processor checks for completeness of the macro in each included file instead of the whole created file.
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1570Fix steady_state_model-block check with instruments2018-09-10T12:35:47ZJohannes Pfeifer Fix steady_state_model-block check with instrumentsI have a model with
```
steady_state_model;
Q=1/R;
end;
planner_objective Welfare;
ramsey_model(instruments=(R),planner_discount=betta);
```
This is a proper conditional steady state file, where the instrument is taken as given. But it results in
```
ERROR: in the 'steady_state_model' block, variable 'R' is undefined in the declaration of variable 'Q'
```
because the preprocessor check does not account for the conditionality.
I have a model with
```
steady_state_model;
Q=1/R;
end;
planner_objective Welfare;
ramsey_model(instruments=(R),planner_discount=betta);
```
This is a proper conditional steady state file, where the instrument is taken as given. But it results in
```
ERROR: in the 'steady_state_model' block, variable 'R' is undefined in the declaration of variable 'Q'
```
because the preprocessor check does not account for the conditionality.
https://git.dynare.org/Dynare/dynare/issues/1564echo list of macro-variables2018-09-10T12:35:47ZMarco Rattoecho list of macro-variableswould it be possible to set a command that prints the value of all macro-variables defined at a given point in the code? I am starting to have lots of macro flags and would be good to have this to trace back which kind of options have been selected for a given experiment.would it be possible to set a command that prints the value of all macro-variables defined at a given point in the code? I am starting to have lots of macro flags and would be good to have this to trace back which kind of options have been selected for a given experiment.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1558Allow diffuse_filter as option for dynare_sensitivity2018-09-10T12:35:47ZJohannes Pfeifer Allow diffuse_filter as option for dynare_sensitivityhttps://git.dynare.org/Dynare/dynare/issues/1556Allow running mode-finding on random draws from prior distribution to check f...2018-11-08T10:13:54ZJohannes Pfeifer Allow running mode-finding on random draws from prior distribution to check for local modeshttps://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/1173Support estimation under optimal policy2019-12-20T11:00:31ZJohannes Pfeifer Support estimation under optimal policySee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=8071
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=8071
4.7Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/issues/846Provide inverse gamma prior with indeterminate moments2018-11-08T10:32:21ZJohannes Pfeifer Provide inverse gamma prior with indeterminate momentsWe currently only allow specifying inverse gamma priors with finite/unique mean and variance. But Leeper/Walker/Yang (2010) in an influential paper use an inverse gamma prior with s=1 and nu=4 (parametrization as at http://en.wikipedia.org/wiki/Inverse-gamma_distribution), which implies non-existing first and second moments. I would suggest to provide a new prior `inv_gamma_parametrized` that takes the values provided in the mean and standard deviation fields of the `estimated_params`-block directly as the parameters of the distribution, thereby avoiding the impossible transformation from mean and variances.
I would implement this when doing #520
We currently only allow specifying inverse gamma priors with finite/unique mean and variance. But Leeper/Walker/Yang (2010) in an influential paper use an inverse gamma prior with s=1 and nu=4 (parametrization as at http://en.wikipedia.org/wiki/Inverse-gamma_distribution), which implies non-existing first and second moments. I would suggest to provide a new prior `inv_gamma_parametrized` that takes the values provided in the mean and standard deviation fields of the `estimated_params`-block directly as the parameters of the distribution, thereby avoiding the impossible transformation from mean and variances.
I would implement this when doing #520
https://git.dynare.org/Dynare/dynare/issues/1543Rename distributed PDFs in doc folder2019-02-21T16:03:54ZJohannes Pfeifer Rename distributed PDFs in doc folderThe names should be more expressive. For example, `dynare.pdf` should be `Adjemian_et_al_2011_Dynare_Manual_4.pdf` or similar.The names should be more expressive. For example, `dynare.pdf` should be `Adjemian_et_al_2011_Dynare_Manual_4.pdf` or similar.Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1389Check detrending engine2019-11-14T17:38:13ZJohannes Pfeifer Check detrending engineThe mod-file
```
//-----------------------------------------------------------------------//
//---------------------- Declaring parameters ---------------------------//
//-----------------------------------------------------------------------//
parameters delta //depreciation
sigma //intertemporal elasticity
beta //discount factor
alpha //production function parameter
mu //utility parameter
theta //Calvo parameter
epsilon //elasticity
chi //indexation parameter (unused for now)
;
alpha = 0.667;
delta = 0.1;
sigma = 0.25;
beta = 0.96;
mu = 0.2;
theta = 0.5;
epsilon = 15;
chi = 0;
//-----------------------------------------------------------------------//
//----------------------- Declaring variables ---------------------------//
//-----------------------------------------------------------------------//
varexo omega //probability of remaining a worker in the next period
gamma //probability of dieing (once retired)
n //populational growth
x //rate of technological change
M_d //exogenous money supply
;
var lambda //asset distribution in the economy
pi //}these define the marginal propensity of consumption
eps //}by both retirees and workers (I'm using Gertler's notation)
OMEGA //higher case omega
R //gross interest rate
PSI //auxiliar variable
mc //marginal cost
Pi //inflation
Df //nominal dividends
Pf //nominal firm share price
price_disp //price dispersion index
;
//declaring nonstationary variables
trend_var(growth_factor= (1+x)*(1+n)/(1+n)) X; //technological progress
trend_var(growth_factor= (1+x)*(1+n)/(1+x)) N; //population
var(deflator = X*N)
Y //product
C //consumption
K //financial capital
H //non-financial capital
A //assets
;
var(deflator = X) W; //real wage
var(deflator = 1/(X*N)) P PStar; //price level and optimal price set
var(deflator = (X*N)^(1-epsilon)) g1; //auxiliary Calvo variable
var(deflator = (X*N)^(2-epsilon)) g2; //auxiliary Calvo variable
predetermined_variables K; //timing convention
//-----------------------------------------------------------------------//
//------------------------------- Model ---------------------------------//
//-----------------------------------------------------------------------//
model;
// Consumer side
//1
K(+1) = Y - C + (1 - delta)* K;
//2
(lambda - (1 - omega(+1)))*A = omega(+1)*(1-eps*pi)*lambda(-1)*R*A(-1);
//3
pi = 1 - PSI(+1) * (R(+1) * OMEGA(+1))^(sigma - 1) * beta^sigma * pi/pi(+1);
//4
eps * pi = 1 - PSI(+1) * ((R(+1))^(sigma-1)*beta^sigma*gamma(+1))*(eps*pi)/(eps(+1)*pi(+1));
//5
OMEGA = omega + (1-omega)*eps^(1/(1-sigma));
//6
H = N * W + H(+1)/((1+n(+1))*(1+x(+1))*R(+1)*OMEGA(+1)/omega(+1));
//7
C * (1 + mu^sigma * (R(+1)*Pi(+1)/(R(+1)*Pi(+1)-1))^(sigma-1)) = pi * ((1 + (eps/gamma-1) * lambda(-1)) * R * A(-1) + H(-1));
//8
A = K + 1/R * M_d(+1)/P + Pf/P;
//9
PSI = (1 + ((R*Pi-1)/(R*Pi))^(sigma-1) * mu^sigma)^(-1) / (1 + (((R(+1)*Pi(+1))-1)/(R(+1)*Pi(+1)))^(sigma-1) * mu^sigma)^(-1);
// Firm side
//10
Y = (X * N)^alpha * (K)^(1-alpha)/price_disp;
//11
W = alpha * Y / N * mc;
//12
R = (1 - alpha) * Y / K * mc + 1 - delta;
//13
mc = (1/(1-alpha))^(1-alpha)*(1/alpha)^alpha*(W/X)^(1-alpha)*(R-(1-delta))^alpha;
// Calvo pricing
//14
PStar = epsilon/(epsilon-1) * g1/g2;
//15
g1 = P^epsilon * Y * mc + theta*beta * g1(+1);
//16
g2 = P^(epsilon-1) * Y + theta*beta * g2(+1);
//17
P = (theta * P(-1)^(1-epsilon) + (1-theta) * PStar^(1-epsilon))^(1/(1-epsilon));
//18
price_disp = theta*(PStar/P)^(-epsilon)*(P/P(-1))^(epsilon) + (1-theta)*(P/P(-1))^(epsilon)*price_disp(-1);
//19
Pi = P/P(-1);
// Dividends and share prices
Df = P * Y *(1-mc);
Pf(+1) + Df(+1) = R(+1) * Pf;
end;
//-----------------------------------------------------------------------//
//--------------------------- Initial Values ----------------------------//
//-----------------------------------------------------------------------//
initval;
M_d = 1; P =1;
x = 0.01;
n = 0.01;
omega = 0.97;
gamma = 0.9;
lambda =0.3878;
pi =0.2394;
eps =1.2832;
OMEGA =1.0124;
R =1.3968;
PSI =0.9988;
mc =0.9064;
Y =0.7407;
C =0.6857;
K =0.459;
H =1.4279;
A =1.365;
P =0.972;
PStar =0.9364;
W =0.448;
Pi =0.98;
Df =0.0681;
Pf =0.1732;
price_disp=1.0336;
g1 =0.601;
g2 =0.6877;
end;
model_diagnostics;
steady;
endval;
gamma = 0.94;
end;
steady;
simul(periods=300);
```
from http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=14206 does not run with
```
ERROR: the second-order cross partial of equation 14 w.r.t. trend variable X and endogenous variable PStar is not null.
```
but the relevant equation
```
PStar = epsilon/(epsilon-1) * g1/g2;
```
should have the trends specified (as far as I can see). `g1/g2=((X*N)^(1-epsilon))/((X*N)^(2-epsilon)=(XN)^(-1)`, which is the trend for `PStar`.The mod-file
```
//-----------------------------------------------------------------------//
//---------------------- Declaring parameters ---------------------------//
//-----------------------------------------------------------------------//
parameters delta //depreciation
sigma //intertemporal elasticity
beta //discount factor
alpha //production function parameter
mu //utility parameter
theta //Calvo parameter
epsilon //elasticity
chi //indexation parameter (unused for now)
;
alpha = 0.667;
delta = 0.1;
sigma = 0.25;
beta = 0.96;
mu = 0.2;
theta = 0.5;
epsilon = 15;
chi = 0;
//-----------------------------------------------------------------------//
//----------------------- Declaring variables ---------------------------//
//-----------------------------------------------------------------------//
varexo omega //probability of remaining a worker in the next period
gamma //probability of dieing (once retired)
n //populational growth
x //rate of technological change
M_d //exogenous money supply
;
var lambda //asset distribution in the economy
pi //}these define the marginal propensity of consumption
eps //}by both retirees and workers (I'm using Gertler's notation)
OMEGA //higher case omega
R //gross interest rate
PSI //auxiliar variable
mc //marginal cost
Pi //inflation
Df //nominal dividends
Pf //nominal firm share price
price_disp //price dispersion index
;
//declaring nonstationary variables
trend_var(growth_factor= (1+x)*(1+n)/(1+n)) X; //technological progress
trend_var(growth_factor= (1+x)*(1+n)/(1+x)) N; //population
var(deflator = X*N)
Y //product
C //consumption
K //financial capital
H //non-financial capital
A //assets
;
var(deflator = X) W; //real wage
var(deflator = 1/(X*N)) P PStar; //price level and optimal price set
var(deflator = (X*N)^(1-epsilon)) g1; //auxiliary Calvo variable
var(deflator = (X*N)^(2-epsilon)) g2; //auxiliary Calvo variable
predetermined_variables K; //timing convention
//-----------------------------------------------------------------------//
//------------------------------- Model ---------------------------------//
//-----------------------------------------------------------------------//
model;
// Consumer side
//1
K(+1) = Y - C + (1 - delta)* K;
//2
(lambda - (1 - omega(+1)))*A = omega(+1)*(1-eps*pi)*lambda(-1)*R*A(-1);
//3
pi = 1 - PSI(+1) * (R(+1) * OMEGA(+1))^(sigma - 1) * beta^sigma * pi/pi(+1);
//4
eps * pi = 1 - PSI(+1) * ((R(+1))^(sigma-1)*beta^sigma*gamma(+1))*(eps*pi)/(eps(+1)*pi(+1));
//5
OMEGA = omega + (1-omega)*eps^(1/(1-sigma));
//6
H = N * W + H(+1)/((1+n(+1))*(1+x(+1))*R(+1)*OMEGA(+1)/omega(+1));
//7
C * (1 + mu^sigma * (R(+1)*Pi(+1)/(R(+1)*Pi(+1)-1))^(sigma-1)) = pi * ((1 + (eps/gamma-1) * lambda(-1)) * R * A(-1) + H(-1));
//8
A = K + 1/R * M_d(+1)/P + Pf/P;
//9
PSI = (1 + ((R*Pi-1)/(R*Pi))^(sigma-1) * mu^sigma)^(-1) / (1 + (((R(+1)*Pi(+1))-1)/(R(+1)*Pi(+1)))^(sigma-1) * mu^sigma)^(-1);
// Firm side
//10
Y = (X * N)^alpha * (K)^(1-alpha)/price_disp;
//11
W = alpha * Y / N * mc;
//12
R = (1 - alpha) * Y / K * mc + 1 - delta;
//13
mc = (1/(1-alpha))^(1-alpha)*(1/alpha)^alpha*(W/X)^(1-alpha)*(R-(1-delta))^alpha;
// Calvo pricing
//14
PStar = epsilon/(epsilon-1) * g1/g2;
//15
g1 = P^epsilon * Y * mc + theta*beta * g1(+1);
//16
g2 = P^(epsilon-1) * Y + theta*beta * g2(+1);
//17
P = (theta * P(-1)^(1-epsilon) + (1-theta) * PStar^(1-epsilon))^(1/(1-epsilon));
//18
price_disp = theta*(PStar/P)^(-epsilon)*(P/P(-1))^(epsilon) + (1-theta)*(P/P(-1))^(epsilon)*price_disp(-1);
//19
Pi = P/P(-1);
// Dividends and share prices
Df = P * Y *(1-mc);
Pf(+1) + Df(+1) = R(+1) * Pf;
end;
//-----------------------------------------------------------------------//
//--------------------------- Initial Values ----------------------------//
//-----------------------------------------------------------------------//
initval;
M_d = 1; P =1;
x = 0.01;
n = 0.01;
omega = 0.97;
gamma = 0.9;
lambda =0.3878;
pi =0.2394;
eps =1.2832;
OMEGA =1.0124;
R =1.3968;
PSI =0.9988;
mc =0.9064;
Y =0.7407;
C =0.6857;
K =0.459;
H =1.4279;
A =1.365;
P =0.972;
PStar =0.9364;
W =0.448;
Pi =0.98;
Df =0.0681;
Pf =0.1732;
price_disp=1.0336;
g1 =0.601;
g2 =0.6877;
end;
model_diagnostics;
steady;
endval;
gamma = 0.94;
end;
steady;
simul(periods=300);
```
from http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=14206 does not run with
```
ERROR: the second-order cross partial of equation 14 w.r.t. trend variable X and endogenous variable PStar is not null.
```
but the relevant equation
```
PStar = epsilon/(epsilon-1) * g1/g2;
```
should have the trends specified (as far as I can see). `g1/g2=((X*N)^(1-epsilon))/((X*N)^(2-epsilon)=(XN)^(-1)`, which is the trend for `PStar`.4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1170Non-bayesian estimation should use quasi-Maximum likelihood standard errors2019-11-21T08:36:42ZTom HoldenNon-bayesian estimation should use quasi-Maximum likelihood standard errorsAt present, with non-Bayesian estimation, Dynare computes standard errors using the Hessian of the likelihood. This is only valid if it is assumed that the shocks in the "true" model are normally distributed. And, in that case, it is an inefficient way of computing the standard errors, as it will be equal to the Fisher information matrix, which only requires the calculation of the derivative of the score vector.
It would make more sense to default to computing quasi-Maximum likelihood "sandwich" covariances, with the option to use the Fisher information matrix if the user wants quicker results.
At present, with non-Bayesian estimation, Dynare computes standard errors using the Hessian of the likelihood. This is only valid if it is assumed that the shocks in the "true" model are normally distributed. And, in that case, it is an inefficient way of computing the standard errors, as it will be equal to the Fisher information matrix, which only requires the calculation of the derivative of the score vector.
It would make more sense to default to computing quasi-Maximum likelihood "sandwich" covariances, with the option to use the Fisher information matrix if the user wants quicker results.
Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/835Behavior of STEADY_STATE() in perfect foresight models with anticipated perma...2019-11-21T08:36:41ZStéphane Adjemianstepan@adjemian.euBehavior of STEADY_STATE() in perfect foresight models with anticipated permanent shocks.In the current state, `STEADY_STATE(X)` return the terminal steady state of variable X in the dynamic model (`oo_.steady_state(i)`). Is this correct in the periods preceding the permanent shock? What if we have more than one permanent shock (at different periods)? @FerhatMihoubi raised this issue yesterday in a discussion. There is a mechanism in the bytecode routines to handle this case by considering different steady state between each (expected) permanent shock (actually this part of the code is not working). For me it is far from obvious that the steady state should change (unless the permanent shocks are unexpected, but there is noisy interface for this kind of scenario in Dynare).
In the current state, `STEADY_STATE(X)` return the terminal steady state of variable X in the dynamic model (`oo_.steady_state(i)`). Is this correct in the periods preceding the permanent shock? What if we have more than one permanent shock (at different periods)? @FerhatMihoubi raised this issue yesterday in a discussion. There is a mechanism in the bytecode routines to handle this case by considering different steady state between each (expected) permanent shock (actually this part of the code is not working). For me it is far from obvious that the steady state should change (unless the permanent shocks are unexpected, but there is noisy interface for this kind of scenario in Dynare).
https://git.dynare.org/Dynare/dynare/issues/1540create reports for dynare commands2019-08-26T10:08:28ZHoutan Bastanicreate reports for dynare commandsCreate standardized reporting output for dynare commands using the reporting submodule, replacing latex code throughout the dynare codebaseCreate standardized reporting output for dynare commands using the reporting submodule, replacing latex code throughout the dynare codebaseHoutan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1162Handling of trends2019-11-21T08:36:41ZMichelJuillardHandling of trendsCurrently trends are taken into account only if users indicate them for observed variables. However, in random walk with drift, a deterministic trend appears endogenously for variables that are not necessarily observed.
Let consider the following model where only Y is observed:
```
A_t = A_{t-1} + g + e_t
Y_t = A_t + eta_t
```
Both A_t and Y_t contain a deterministic linear trend with a slope of g. The current practice of only specifying the trend of Y is not satisfactory anymore.
When using the smoother, we need to recognize these trends and include them in SmoothedVariables and friends
Currently trends are taken into account only if users indicate them for observed variables. However, in random walk with drift, a deterministic trend appears endogenously for variables that are not necessarily observed.
Let consider the following model where only Y is observed:
```
A_t = A_{t-1} + g + e_t
Y_t = A_t + eta_t
```
Both A_t and Y_t contain a deterministic linear trend with a slope of g. The current practice of only specifying the trend of Y is not satisfactory anymore.
When using the smoother, we need to recognize these trends and include them in SmoothedVariables and friends
https://git.dynare.org/Dynare/dynare/issues/1539create a reporting tutorial website2019-08-26T10:08:36ZHoutan Bastanicreate a reporting tutorial websiteGoing from simple examples to more complex examples to make the code more approachable
Going from simple examples to more complex examples to make the code more approachable
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1359Add interface to load datafile in Matlab's table-format2019-12-03T14:45:18ZJohannes Pfeifer Add interface to load datafile in Matlab's table-formatIn `R2013b`. Matlab introduced a datatype `table` (https://de.mathworks.com/help/matlab/ref/table.html). We should support reading datasets saved in this format. In `R2013b`. Matlab introduced a datatype `table` (https://de.mathworks.com/help/matlab/ref/table.html). We should support reading datasets saved in this format. 4.6Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/issues/1114create contributions.md describing how to contribute to dynare2019-11-26T16:30:56ZHoutan Bastanicreate contributions.md describing how to contribute to dynareStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/issues/832Use dseries objects in Dynare2019-11-21T08:36:45ZStéphane Adjemianstepan@adjemian.euUse dseries objects in DynareIn the current state, `dseries` objects can be used in matlab scripts and in Dynare's mod file to create and manipulate datasets. The next step is to integrate more deeply the `dseries` class and Dynare. Whenever possible the output of Dynare will be `dseries` objects (IRFs, forecasts, ...) and also we will allow the use of `dseries` objects as inputs to Dynare's command (`data`, content of `initval`, data for conditional forecasts, ...).
- [ ] Document the `data` command (new data interface).
- [ ] Save results as `dseries` objects.
- [x] Polish and document the from-to-do syntax.
- [ ] Add the possibility to pass `dseries`to `initial``and``histval``commands.
In the current state, `dseries` objects can be used in matlab scripts and in Dynare's mod file to create and manipulate datasets. The next step is to integrate more deeply the `dseries` class and Dynare. Whenever possible the output of Dynare will be `dseries` objects (IRFs, forecasts, ...) and also we will allow the use of `dseries` objects as inputs to Dynare's command (`data`, content of `initval`, data for conditional forecasts, ...).
- [ ] Document the `data` command (new data interface).
- [ ] Save results as `dseries` objects.
- [x] Polish and document the from-to-do syntax.
- [ ] Add the possibility to pass `dseries`to `initial``and``histval``commands.
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/issues/1537Stop processing with error if nonlinearities exist in endog/exog for linear m...2019-09-10T13:48:13ZHoutan BastaniStop processing with error if nonlinearities exist in endog/exog for linear modelFollowing the conversation in #1404, stop preprocessing with an error if a model is marked as linear but nonlinearities exist in the endogenous or exogenous variables.Following the conversation in #1404, stop preprocessing with an error if a model is marked as linear but nonlinearities exist in the endogenous or exogenous variables.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1338risky steady state: no interface, test suite2019-11-21T08:25:49ZHoutan Bastanirisky steady state: no interface, test suiteThere are several issues with risky steady state:
1. It has no interface. Why? Is this something we want to keep (hidden) in Dynare?
1. It the .mod files that use it are not in the test suite. Why?
There are several issues with risky steady state:
1. It has no interface. Why? Is this something we want to keep (hidden) in Dynare?
1. It the .mod files that use it are not in the test suite. Why?
4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1112homogeneize treatment of leads/lags on exogenous between deterministic and st...2019-11-21T08:52:36ZHoutan Bastanihomogeneize treatment of leads/lags on exogenous between deterministic and stochastic modesAuxiliary variables are treated differently depending on the commands passed in the `.mod` file. As it stands now, if the following conditions hold
```
mod_file_struct.stoch_simul_present
mod_file_struct.estimation_present
mod_file_struct.osr_present
mod_file_struct.ramsey_policy_present
mod_file_struct.discretionary_policy_present
mod_file_struct.calib_smoother_present
```
we substitute endo and exo leads and lags. Otherwise, we only substitute endo leads and lags. This different treatment is undesirable for Julia output, where we will only use the preprocessor to process a model, without having the associated commands. In other words, we want the preprocessor model output to be same, regardless of the commands that are included outside of the `model` block.
As this change requires changes in the matlab code as well, the work will be done on the `aux_func` branch.
Auxiliary variables are treated differently depending on the commands passed in the `.mod` file. As it stands now, if the following conditions hold
```
mod_file_struct.stoch_simul_present
mod_file_struct.estimation_present
mod_file_struct.osr_present
mod_file_struct.ramsey_policy_present
mod_file_struct.discretionary_policy_present
mod_file_struct.calib_smoother_present
```
we substitute endo and exo leads and lags. Otherwise, we only substitute endo leads and lags. This different treatment is undesirable for Julia output, where we will only use the preprocessor to process a model, without having the associated commands. In other words, we want the preprocessor model output to be same, regardless of the commands that are included outside of the `model` block.
As this change requires changes in the matlab code as well, the work will be done on the `aux_func` branch.
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/831Improve homotopy2019-11-21T08:36:42ZStéphane Adjemianstepan@adjemian.euImprove homotopy- [X] Display more informations about the progress of the algorithm.
- [X] Do not display warnings.
- [X] Set verbosity to 0 when entering in the homotopy.
- [X] Fix homotopy with `block` and `bytecode` options.
- [ ] Fix display of informations with `bytecode options`.
- [X] Display more informations about the progress of the algorithm.
- [X] Do not display warnings.
- [X] Set verbosity to 0 when entering in the homotopy.
- [X] Fix homotopy with `block` and `bytecode` options.
- [ ] Fix display of informations with `bytecode options`.
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/issues/1534Add documentation for SMM/GMM/IRF options2019-11-21T08:36:44ZJohannes Pfeifer Add documentation for SMM/GMM/IRF optionsRelevant commits are https://github.com/DynareTeam/dynare/commit/254a73a4065a4b476296391dd22672637f82fc72 and https://github.com/DynareTeam/dynare/commit/d52f13114d10fbe5fd4d263d5d0b9d7cfda787f6Relevant commits are https://github.com/DynareTeam/dynare/commit/254a73a4065a4b476296391dd22672637f82fc72 and https://github.com/DynareTeam/dynare/commit/d52f13114d10fbe5fd4d263d5d0b9d7cfda787f6Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/1315check to see if we need all Windows compiler macros in preprocessor2018-10-02T14:53:27ZHoutan Bastanicheck to see if we need all Windows compiler macros in preprocessorThis page
http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system
Seems to say all we need is `_WIN32` as it's defined on all Windows systems. This would make `__CYGWIN32__` and `__MINGW32__` redundant. Check to see this is the case
This page
http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system
Seems to say all we need is `_WIN32` as it's defined on all Windows systems. This would make `__CYGWIN32__` and `__MINGW32__` redundant. Check to see this is the case
4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1093Discuss changing options_.hp_ngrid2020-01-15T14:32:56ZJohannes Pfeifer Discuss changing options_.hp_ngridThe option `options_.hp_ngrid` is now badly named after introducing a `bandpass_filter` option. It actually governs the number of points used in the inverse Fourier transform for any filter (see #1011).
I would suggest creating a new option `ifft_points` in the options structure and the preprocessor. For backward compatibility we should keep `hp_ngrid` in the preprocesor, but have it now map into `options_.ifft_points`
The option `options_.hp_ngrid` is now badly named after introducing a `bandpass_filter` option. It actually governs the number of points used in the inverse Fourier transform for any filter (see #1011).
I would suggest creating a new option `ifft_points` in the options structure and the preprocessor. For backward compatibility we should keep `hp_ngrid` in the preprocesor, but have it now map into `options_.ifft_points`
4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/829Rewrite local_state_space_iteration_2 routine2019-11-21T08:55:15ZStéphane Adjemianstepan@adjemian.euRewrite local_state_space_iteration_2 routineSeparate the measurement and state equations. See discussions in [particles](https://github.com/DynareTeam/particles/issues) repository.
Separate the measurement and state equations. See discussions in [particles](https://github.com/DynareTeam/particles/issues) repository.
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/issues/1532Factorize IRF code into function generate_irfs(M_,options_,oo_)2018-11-08T10:14:41ZJohannes Pfeifer Factorize IRF code into function generate_irfs(M_,options_,oo_)Take the fragmented codes from `stoch_simul` and `PosteriorIRFcore1` and put them into one function that is used in those other commands, but can also be called as a standalone. Related to #1531. Take the fragmented codes from `stoch_simul` and `PosteriorIRFcore1` and put them into one function that is used in those other commands, but can also be called as a standalone. Related to #1531. https://git.dynare.org/Dynare/dynare/issues/1308Factorize print_info and interpret_resol_info2019-12-09T17:11:26ZStéphane Adjemianstepan@adjemian.euFactorize print_info and interpret_resol_infoSee discussion [here](https://github.com/DynareTeam/dynare/commit/83bc67f0c03bcd79cbbe4c903d7e5f5d4bc11e88#commitcomment-19332156).
See discussion [here](https://github.com/DynareTeam/dynare/commit/83bc67f0c03bcd79cbbe4c903d7e5f5d4bc11e88#commitcomment-19332156).
4.6Dóra KocsisDóra Kocsishttps://git.dynare.org/Dynare/dynare/issues/1078Make lyapunov_symm compatible with sparse matrices2019-11-21T08:36:41ZJohannes Pfeifer Make lyapunov_symm compatible with sparse matricesAs discussed in #988 it would make sense to have `lyapunov_symm` able to work with sparse matrices (at least for the baseline option)
As discussed in #988 it would make sense to have `lyapunov_symm` able to work with sparse matrices (at least for the baseline option)
https://git.dynare.org/Dynare/dynare/issues/827Feature request: Implement the algorithm of Ajevskis (2014) for perturbation ...2019-11-21T08:36:41ZTom HoldenFeature request: Implement the algorithm of Ajevskis (2014) for perturbation around a deterministic pathViktors Ajevskis has a [great new paper](https://ideas.repec.org/p/ltv/wpaper/201401.html) showing how the Lombardo pruning method may be extended to support perturbation around a deterministic path. This seems like a feature that would be a huge benefit to virtually all Dynare users, since it makes it possible to e.g.:
- Solve non-stationary DSGE models, such as those featuring structural change.
- Evaluate the welfare consequences of a permanent change in policy, without sacrificing accuracy along the transition path.
- Obtain increased accuracy for large impulse response exercises.
- Unify the stochastic and non-stochastic simulation engines in Dynare.
It would be great if this could be added to the bottom of your very long to do list!
https://ideas.repec.org/p/ltv/wpaper/201401.html
Viktors Ajevskis has a [great new paper](https://ideas.repec.org/p/ltv/wpaper/201401.html) showing how the Lombardo pruning method may be extended to support perturbation around a deterministic path. This seems like a feature that would be a huge benefit to virtually all Dynare users, since it makes it possible to e.g.:
- Solve non-stationary DSGE models, such as those featuring structural change.
- Evaluate the welfare consequences of a permanent change in policy, without sacrificing accuracy along the transition path.
- Obtain increased accuracy for large impulse response exercises.
- Unify the stochastic and non-stochastic simulation engines in Dynare.
It would be great if this could be added to the bottom of your very long to do list!
https://ideas.repec.org/p/ltv/wpaper/201401.html
https://git.dynare.org/Dynare/dynare/issues/1524Enable method argument of gamrnd.m2018-12-15T16:11:55ZJohannes Pfeifer Enable method argument of gamrnd.mCurrently, we provide an error.Currently, we provide an error.Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/issues/1304Octave out of memory issues2018-11-09T14:50:08ZJohannes Pfeifer Octave out of memory issuesWhen running `observation_trends_and_prefiltering/MCMC/Trend_loglinear_no_prefilter_MC.mod` in `Octave 4.0.3` I get
```
error: out of memory or dimension too large for Octave's index type
error: called from
pm3 at line 82 column 13
prior_posterior_statistics at line 297 column 5
dynare_estimation_1 at line 462 column 13
dynare_estimation at line 105 column 5
Trend_loglinear_no_prefilter_MC at line 194 column 14
dynare at line 223 column 1
```
Given that Octave (at least on Windows) does not fully support `64 bit`, solving this could be challenging to impossible.
When running `observation_trends_and_prefiltering/MCMC/Trend_loglinear_no_prefilter_MC.mod` in `Octave 4.0.3` I get
```
error: out of memory or dimension too large for Octave's index type
error: called from
pm3 at line 82 column 13
prior_posterior_statistics at line 297 column 5
dynare_estimation_1 at line 462 column 13
dynare_estimation at line 105 column 5
Trend_loglinear_no_prefilter_MC at line 194 column 14
dynare at line 223 column 1
```
Given that Octave (at least on Windows) does not fully support `64 bit`, solving this could be challenging to impossible.
4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1060Add capabilities for pseudo out of sample forecasting2019-11-21T08:36:44ZJohannes Pfeifer Add capabilities for pseudo out of sample forecastingAllow estimating model parameters on one part of the data and then, holding the estimated parameters fixed, forecast observations after the end of the sample used for estimation. See discussion on mailing list from September 14, 2015
Allow estimating model parameters on one part of the data and then, holding the estimated parameters fixed, forecast observations after the end of the sample used for estimation. See discussion on mailing list from September 14, 2015
https://git.dynare.org/Dynare/dynare/issues/825Fix using steady state operator on exogenous variables2019-11-27T16:33:42ZJohannes Pfeifer Fix using steady state operator on exogenous variablesThe mod-file
```
var c, h, pi, w, R, r_e, y, gdp, gdp_hat, k, g, w_tilde, w_eq, w_min;
varexo d, z, eta;
parameters beta, sigma, gamma, theta, ni, tau_w, phi_p, phi_y, rho, alpha;
beta = 0.997;
sigma = 1;
gamma = 458.4;
theta = 6.1;
tau_w = 0.2;
ni = 0.28;
phi_p = 1.5;
phi_y = 0.125;
rho = 0.3;
alpha = 0.064;
model;
w_tilde=rho/(1+pi)*w(-1)+(1-rho)*w_eq;
w_eq =(1-alpha)*steady_state(z)*steady_state(h)^(-alpha);
w_min =w(-1)/(1+pi);
//mrs=c^sigma*h^ni/(1-tau_w);
gdp_hat =log(gdp)-log(steady_state(gdp));
r_e=1/(beta*d(+1))-1;
//FOC labor
c^sigma*h^ni=max(w_tilde,w_min)*(1-tau_w);
//Euler equation 1
1=beta*d(+1)*(1+R)/(1+pi(+1))*(c/c(+1))^sigma;
//Euler equation 2
0=(1/(1-alpha))*max(w_tilde,w_min)/z*h^alpha-1-gamma/theta*pi*(1+pi)+beta*d(+1)*(c/c(+1))^sigma * y(+1)/y*gamma/theta*pi(+1)*(1+pi(+1));
// Taylor rule with ZLB
R=max(0,r_e+phi_p*pi+phi_y*gdp_hat);
//output
y=z*h^(1-alpha);
//aggregate resource constraint
c=(1-k-eta)*y;
// resource cost of price adjustment
k=(gamma/2)*(pi^2);
//government purchases
g=eta*y;
// GDP
gdp=(1-k)*y;
//utility
//u=(c^(1-sigma))/(1-sigma)-(h^(1+ni))/(1+ni);
end;
initval;
z=1;
d=1;
pi=0;
k=(gamma/2)*(pi^2);
r_e=1/(beta*d)-1;
h=1;
y=z*h^(1-alpha);
g=eta*y;
c=(1-k-eta)*y;
//w=z;
//w=(1-alpha)/(h^alpha);
gdp=(1-k)*y;
R=r_e;
eta=0.2;
end;
steady;
check;
```
uses `steady_state(z)` where `z` is an exogenous variable. In the `_dynamic` file, the preprocessor translates this to `oo_.exo_steady_state(2)` which does not exist in the `_dynamic` file, leading to a crash. We should either disallow using the steady state operator on exogenous variables or simply enforce that the steady state of exogenous variables is 0. I would prefer the first one as the second would only be viable for stochastic simulations.
The mod-file
```
var c, h, pi, w, R, r_e, y, gdp, gdp_hat, k, g, w_tilde, w_eq, w_min;
varexo d, z, eta;
parameters beta, sigma, gamma, theta, ni, tau_w, phi_p, phi_y, rho, alpha;
beta = 0.997;
sigma = 1;
gamma = 458.4;
theta = 6.1;
tau_w = 0.2;
ni = 0.28;
phi_p = 1.5;
phi_y = 0.125;
rho = 0.3;
alpha = 0.064;
model;
w_tilde=rho/(1+pi)*w(-1)+(1-rho)*w_eq;
w_eq =(1-alpha)*steady_state(z)*steady_state(h)^(-alpha);
w_min =w(-1)/(1+pi);
//mrs=c^sigma*h^ni/(1-tau_w);
gdp_hat =log(gdp)-log(steady_state(gdp));
r_e=1/(beta*d(+1))-1;
//FOC labor
c^sigma*h^ni=max(w_tilde,w_min)*(1-tau_w);
//Euler equation 1
1=beta*d(+1)*(1+R)/(1+pi(+1))*(c/c(+1))^sigma;
//Euler equation 2
0=(1/(1-alpha))*max(w_tilde,w_min)/z*h^alpha-1-gamma/theta*pi*(1+pi)+beta*d(+1)*(c/c(+1))^sigma * y(+1)/y*gamma/theta*pi(+1)*(1+pi(+1));
// Taylor rule with ZLB
R=max(0,r_e+phi_p*pi+phi_y*gdp_hat);
//output
y=z*h^(1-alpha);
//aggregate resource constraint
c=(1-k-eta)*y;
// resource cost of price adjustment
k=(gamma/2)*(pi^2);
//government purchases
g=eta*y;
// GDP
gdp=(1-k)*y;
//utility
//u=(c^(1-sigma))/(1-sigma)-(h^(1+ni))/(1+ni);
end;
initval;
z=1;
d=1;
pi=0;
k=(gamma/2)*(pi^2);
r_e=1/(beta*d)-1;
h=1;
y=z*h^(1-alpha);
g=eta*y;
c=(1-k-eta)*y;
//w=z;
//w=(1-alpha)/(h^alpha);
gdp=(1-k)*y;
R=r_e;
eta=0.2;
end;
steady;
check;
```
uses `steady_state(z)` where `z` is an exogenous variable. In the `_dynamic` file, the preprocessor translates this to `oo_.exo_steady_state(2)` which does not exist in the `_dynamic` file, leading to a crash. We should either disallow using the steady state operator on exogenous variables or simply enforce that the steady state of exogenous variables is 0. I would prefer the first one as the second would only be viable for stochastic simulations.
4.6MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/1521create class for storing/writing metropolis draws2019-12-20T16:31:36ZHoutan Bastanicreate class for storing/writing metropolis drawsIn the `while` loop of `matlab/posterior_sampler_core.m` we have an example of how draws are stored and written when a certain number of draws have been stored in memory.
Need to create a Matlab class that stores:
- a vector
- a matrix
- a structure (`dr`)
And that writes itself to disk when a certain number of vector/matrix/structures have been written and clears itself so that more draws can be stored.
This class can then be used to standardize the various ways we do this throughout the Matlab codebase.In the `while` loop of `matlab/posterior_sampler_core.m` we have an example of how draws are stored and written when a certain number of draws have been stored in memory.
Need to create a Matlab class that stores:
- a vector
- a matrix
- a structure (`dr`)
And that writes itself to disk when a certain number of vector/matrix/structures have been written and clears itself so that more draws can be stored.
This class can then be used to standardize the various ways we do this throughout the Matlab codebase.4.7https://git.dynare.org/Dynare/dynare/issues/1282MS-SBVAR: Potentially allow for linear restrictions across A0 and Aplus2018-09-11T15:00:44ZJohannes Pfeifer MS-SBVAR: Potentially allow for linear restrictions across A0 and AplusAfter a user inquiry at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=9594, @dwaggoner replied with the following. The question is now whether we want to implement this?
The underlying C code can handle linear restrictions across `A0` and `Aplus` as long as they are not cross-equation. Also the restrictions must be linear, not affine, i.e. no non-zero constant. It seems like this is what the person is asking for. Also, this cannot be used with the Sims-Zha specification as that requires `Aplus` to be unrestricted.
Each column (equation) of `A0` and Aplus can be restricted to be of the form
```
a_j = U[j]*b_j
aplus_j = V[j]*g_j + W[j]*a_j
```
Here `b_j` and `g_j` are the "free parameters", with `a_j` and `aplus_j` are the columns of `A0` and `Aplus`. The cross `A0` - `Aplus` restrictions require `W[j]` to be non-zero.
The work will be going from the dynare file to producing `U[j]`, `V[j]`, and `W[j]`. You already produce `U[j]` and `V[j]`, so producing `W[j]` should not be to much more work.
After a user inquiry at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=9594, @dwaggoner replied with the following. The question is now whether we want to implement this?
The underlying C code can handle linear restrictions across `A0` and `Aplus` as long as they are not cross-equation. Also the restrictions must be linear, not affine, i.e. no non-zero constant. It seems like this is what the person is asking for. Also, this cannot be used with the Sims-Zha specification as that requires `Aplus` to be unrestricted.
Each column (equation) of `A0` and Aplus can be restricted to be of the form
```
a_j = U[j]*b_j
aplus_j = V[j]*g_j + W[j]*a_j
```
Here `b_j` and `g_j` are the "free parameters", with `a_j` and `aplus_j` are the columns of `A0` and `Aplus`. The cross `A0` - `Aplus` restrictions require `W[j]` to be non-zero.
The work will be going from the dynare file to producing `U[j]`, `V[j]`, and `W[j]`. You already produce `U[j]` and `V[j]`, so producing `W[j]` should not be to much more work.
https://git.dynare.org/Dynare/dynare/issues/1056Document the data command2018-09-11T15:00:44ZStéphane Adjemianstepan@adjemian.euDocument the data commandStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/issues/1519check repeated variables in symbol_list for stoch_simul2019-09-10T09:13:59ZHoutan Bastanicheck repeated variables in symbol_list for stoch_simuldo this during `transformPass`, issue warning and remove second symbol when encountered.do this during `transformPass`, issue warning and remove second symbol when encountered.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1055Deprecate first_obs and last_obs in data command2018-09-11T15:00:44ZStéphane Adjemianstepan@adjemian.euDeprecate first_obs and last_obs in data commandReplaced by `first_date` and `last_date`, to avoid confusion with the options in the `estimation` command.
Replaced by `first_date` and `last_date`, to avoid confusion with the options in the `estimation` command.
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/issues/824Add an interface for joint priors.2019-11-21T08:36:43ZStéphane Adjemianstepan@adjemian.euAdd an interface for joint priors.Only available for the new estimation syntax. Something like:
``` example
[alpha, beta].prior(shape=gaussian, mean=Vector, variance=Matrix, ...)
```
This interface is needed for Dirichlet priors over probabilities.
Only available for the new estimation syntax. Something like:
``` example
[alpha, beta].prior(shape=gaussian, mean=Vector, variance=Matrix, ...)
```
This interface is needed for Dirichlet priors over probabilities.
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1514Add Importance Ratio as diagnostic for checking accuracy of normal approximat...2019-12-20T16:31:49ZJohannes Pfeifer Add Importance Ratio as diagnostic for checking accuracy of normal approximation to posteriorSee e.g. Slide 32 of http://apps.eui.eu/Personal/Canova/Teachingmaterial/bayes_dsge_eui2012.pdfSee e.g. Slide 32 of http://apps.eui.eu/Personal/Canova/Teachingmaterial/bayes_dsge_eui2012.pdf4.7https://git.dynare.org/Dynare/dynare/issues/1252do we need to remove dynamic exception specifications?2019-08-14T12:13:30ZMichelJuillarddo we need to remove dynamic exception specifications?dynamic exceptions specification is now deprecated in C++
In mexFunction, when an unknown exception occurs, Matlab or Octave may crash
Maybe we should remove them from the mexFunction code. I don't see very well their contribution.
dynamic exceptions specification is now deprecated in C++
In mexFunction, when an unknown exception occurs, Matlab or Octave may crash
Maybe we should remove them from the mexFunction code. I don't see very well their contribution.
https://git.dynare.org/Dynare/dynare/issues/1044Clear up option mh_posterior_mode_estimation2018-09-11T15:00:44ZJohannes Pfeifer Clear up option mh_posterior_mode_estimationSee the question at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7235
Does anyone know what it does?
Looking at the codes in `dynare_estimation_1.m` this option seems to skip mode computation and directly runs the MCMC, using the prior mode as the starting point and the prior variances for computing the inverse Hessian for the MCMC. In case of the mode not existing, the prior mean is used.
But already before doing so, it sets
```
oo_.posterior.optimization.mode = xparam1;
oo_.posterior.optimization.Variance = [];
```
That is, the mode saved is based on the starting values given for MCMC and no variance is saved. This looks like a a bug as the MCMC starts with values that are only set after this assignment.
Finally, this option runs the MCMC and calls `CutSample.m` before returning. What is the point of just estimating the MCMC starting at the prior mode and providing no output?
We should either document the option and add a preprocessor command or get rid of it.
See the question at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7235
Does anyone know what it does?
Looking at the codes in `dynare_estimation_1.m` this option seems to skip mode computation and directly runs the MCMC, using the prior mode as the starting point and the prior variances for computing the inverse Hessian for the MCMC. In case of the mode not existing, the prior mean is used.
But already before doing so, it sets
```
oo_.posterior.optimization.mode = xparam1;
oo_.posterior.optimization.Variance = [];
```
That is, the mode saved is based on the starting values given for MCMC and no variance is saved. This looks like a a bug as the MCMC starts with values that are only set after this assignment.
Finally, this option runs the MCMC and calls `CutSample.m` before returning. What is the point of just estimating the MCMC starting at the prior mode and providing no output?
We should either document the option and add a preprocessor command or get rid of it.
https://git.dynare.org/Dynare/dynare/issues/819Support DSGE-VAR forecasts2018-09-11T15:00:44ZJohannes Pfeifer Support DSGE-VAR forecastsCurrently, forecasts are based on the DSGE model and not the DSGE-VAR
Currently, forecasts are based on the DSGE model and not the DSGE-VAR
https://git.dynare.org/Dynare/dynare/issues/1513Allow selecting proper training sample for endogenous_prior2019-12-20T16:32:01ZJohannes Pfeifer Allow selecting proper training sample for endogenous_priorCurrently, we simply use `Y=data';`, but it is straightforward to include different dataCurrently, we simply use `Y=data';`, but it is straightforward to include different data4.7https://git.dynare.org/Dynare/dynare/issues/1250Investigate mex-file issues2018-11-09T14:09:56ZJohannes Pfeifer Investigate mex-file issuesThe mod-file
```
theta=[0.999076 5.75 0.76025 0.567383 0.001281 0.0197260625 0.996577 0.00034 0.001028 0.02 0.846875 0.000345]';
%theta= [0.998826 2.250000 1.729 1.629883 0.001281 0.0184760625 0.991577 0.000340 0.001028 0.024966 0.973750 0.000970]';
var c d h ik k l q rf uc vk yy nk dchat dc m da ddem;
varexo ea ed;
parameters ALFA BETTA DELTA GAM PSI NBAR TAU NU MUA SIGA MUD SIGD;
set_param_value('BETTA',theta(1));
set_param_value('GAM',theta(2));
set_param_value('PSI',theta(3));
set_param_value('TAU',theta(4));
set_param_value('MUA',theta(5));
set_param_value('SIGA',theta(6));
set_param_value('MUD',theta(9));
set_param_value('SIGD',theta(10));
DELTA = 0.008333333333333; % Depreciation
ALFA = 0.345000000000000; % Capital share
NBAR = 0.22; % 0.180000000000000; % Steady state NUmber of hours worked;
NU = 0.256884124396632; % 0.204786351767522; % Share of consumption;
model;
#a0 = (exp(MUA) + DELTA - 1)^(1/TAU); % Adjustment cost coefficient
#b0 = (1/(1-TAU))*(exp(MUA) + DELTA - 1); % Adjustment cost coefficient
#THETA = (1-GAM)/(1-(1/PSI));
0 = - da + MUA + SIGA*ea;
0 = - ddem + MUD + SIGD*ed;
0 = - exp(yy) + exp(c)+exp(ik);
0 = - exp(yy) + exp(k*ALFA)*exp((da+h)*(1-ALFA));
0 = - exp(vk) + exp((uc(+1)+dchat(+1))*(1-GAM));
0 = - exp(uc*(1-1/PSI)) + (1-BETTA) + exp(ddem(+1))*BETTA*exp(vk*(1/THETA));
0 = - exp(m) + (exp(ddem) * BETTA * exp(dc*(-1)) * exp(dchat)^(1-1/PSI) * exp((uc+dchat)*(1/PSI-GAM))/exp(vk(-1)*(1-1/THETA)));
0 = - 1 + exp(rf + m(+1));
0 = - (1-ALFA)*exp(yy-h) + (1/NU-1)*exp(c-l);
0 = - 1 + exp(h)+exp(l);
0 = - dchat + NU*(c-c(-1)) + (1-NU)*(l-l(-1)) + NU*da(-1); // used for ease of notation
0 = - dc + c-c(-1) + da(-1);
0 = - exp(k+da(-1)) + (1-DELTA + exp(nk(-1)))*exp(k(-1));
0 = - exp(nk) + b0 + (a0/(1-(1/TAU)))*(exp((ik-k)*(1-(1/TAU))));
0 = - exp(q) + 1/(a0*(exp((ik-k)*(-1/TAU))));
0 = - exp(d) + ALFA*exp(yy-k) + (exp(nk) - DELTA)*exp(q) - exp(ik-k);
0 = - 1 + ((exp(q(+1))+exp(d(+1)))/exp(q)) * exp(m(+1));
end;
% Initial values
steady_state_model;
h = log(NBAR);
l = log(1-NBAR);
da = MUA;
ddem = MUD;
dc = MUA;
dchat = MUA*NU;
m = (log(BETTA) + MUD + MUA*NU*(1-1/PSI) + MUA*(-1));
k = log(((1/(BETTA*exp(MUA*NU*(1-1/PSI))*exp(MUA*(-1))*exp(MUD)) -1+DELTA)/ALFA)^(1/(ALFA-1)))+MUA+h;
yy = log(exp(k)^ALFA * (exp(MUA)*exp(h))^(1-ALFA));
ik = log(exp(k)*(exp(MUA)+DELTA-1));
c = log(exp(yy) - exp(ik));
rf = -m;
q = 0;
nk = log((((exp(MUA) + DELTA - 1)^(1/TAU))/(1-1/TAU))*((exp(ik)/exp(k))^(1-1/TAU)) + ((1/(1-TAU))*(exp(MUA) + DELTA - 1))) ;
d = log(ALFA*exp(yy)/exp(k) + (exp(nk)-DELTA)*exp(q) - (exp(ik)/exp(k)));
uc = (PSI/(PSI-1))*log((1-BETTA)/(1-BETTA*exp(MUA*NU*(1-1/PSI))*exp(MUD)));
vk = log((exp(uc))^(1-GAM));
end;
shocks;
var ea; stderr 1;
var ed; stderr 1;
end;
steady(nocheck);
check;
stoch_simul(order=3, periods=0,drop=0,irf=0,nograph,nocorr,nofunctions,nomoments);
```
triggers two issues.
1. During the `check` command, both the Linux and the Windows Octave `mex`-files trigger a `LAPACK`-error that `The generalized Schur (QZ) decomposition failed`. This is not the case on Windows, but should happen there as well, I guess.
2. When removing the call to check on Linux/Octave so that `k_order_pert` is subsequently triggered, the mod-file crashes Matlab on both Windows and Linux. Presumably this happens due to the singularity that is correctly detected by `mjdgges` on Linux, but improperly handled on all operating systems.
The mod-file
```
theta=[0.999076 5.75 0.76025 0.567383 0.001281 0.0197260625 0.996577 0.00034 0.001028 0.02 0.846875 0.000345]';
%theta= [0.998826 2.250000 1.729 1.629883 0.001281 0.0184760625 0.991577 0.000340 0.001028 0.024966 0.973750 0.000970]';
var c d h ik k l q rf uc vk yy nk dchat dc m da ddem;
varexo ea ed;
parameters ALFA BETTA DELTA GAM PSI NBAR TAU NU MUA SIGA MUD SIGD;
set_param_value('BETTA',theta(1));
set_param_value('GAM',theta(2));
set_param_value('PSI',theta(3));
set_param_value('TAU',theta(4));
set_param_value('MUA',theta(5));
set_param_value('SIGA',theta(6));
set_param_value('MUD',theta(9));
set_param_value('SIGD',theta(10));
DELTA = 0.008333333333333; % Depreciation
ALFA = 0.345000000000000; % Capital share
NBAR = 0.22; % 0.180000000000000; % Steady state NUmber of hours worked;
NU = 0.256884124396632; % 0.204786351767522; % Share of consumption;
model;
#a0 = (exp(MUA) + DELTA - 1)^(1/TAU); % Adjustment cost coefficient
#b0 = (1/(1-TAU))*(exp(MUA) + DELTA - 1); % Adjustment cost coefficient
#THETA = (1-GAM)/(1-(1/PSI));
0 = - da + MUA + SIGA*ea;
0 = - ddem + MUD + SIGD*ed;
0 = - exp(yy) + exp(c)+exp(ik);
0 = - exp(yy) + exp(k*ALFA)*exp((da+h)*(1-ALFA));
0 = - exp(vk) + exp((uc(+1)+dchat(+1))*(1-GAM));
0 = - exp(uc*(1-1/PSI)) + (1-BETTA) + exp(ddem(+1))*BETTA*exp(vk*(1/THETA));
0 = - exp(m) + (exp(ddem) * BETTA * exp(dc*(-1)) * exp(dchat)^(1-1/PSI) * exp((uc+dchat)*(1/PSI-GAM))/exp(vk(-1)*(1-1/THETA)));
0 = - 1 + exp(rf + m(+1));
0 = - (1-ALFA)*exp(yy-h) + (1/NU-1)*exp(c-l);
0 = - 1 + exp(h)+exp(l);
0 = - dchat + NU*(c-c(-1)) + (1-NU)*(l-l(-1)) + NU*da(-1); // used for ease of notation
0 = - dc + c-c(-1) + da(-1);
0 = - exp(k+da(-1)) + (1-DELTA + exp(nk(-1)))*exp(k(-1));
0 = - exp(nk) + b0 + (a0/(1-(1/TAU)))*(exp((ik-k)*(1-(1/TAU))));
0 = - exp(q) + 1/(a0*(exp((ik-k)*(-1/TAU))));
0 = - exp(d) + ALFA*exp(yy-k) + (exp(nk) - DELTA)*exp(q) - exp(ik-k);
0 = - 1 + ((exp(q(+1))+exp(d(+1)))/exp(q)) * exp(m(+1));
end;
% Initial values
steady_state_model;
h = log(NBAR);
l = log(1-NBAR);
da = MUA;
ddem = MUD;
dc = MUA;
dchat = MUA*NU;
m = (log(BETTA) + MUD + MUA*NU*(1-1/PSI) + MUA*(-1));
k = log(((1/(BETTA*exp(MUA*NU*(1-1/PSI))*exp(MUA*(-1))*exp(MUD)) -1+DELTA)/ALFA)^(1/(ALFA-1)))+MUA+h;
yy = log(exp(k)^ALFA * (exp(MUA)*exp(h))^(1-ALFA));
ik = log(exp(k)*(exp(MUA)+DELTA-1));
c = log(exp(yy) - exp(ik));
rf = -m;
q = 0;
nk = log((((exp(MUA) + DELTA - 1)^(1/TAU))/(1-1/TAU))*((exp(ik)/exp(k))^(1-1/TAU)) + ((1/(1-TAU))*(exp(MUA) + DELTA - 1))) ;
d = log(ALFA*exp(yy)/exp(k) + (exp(nk)-DELTA)*exp(q) - (exp(ik)/exp(k)));
uc = (PSI/(PSI-1))*log((1-BETTA)/(1-BETTA*exp(MUA*NU*(1-1/PSI))*exp(MUD)));
vk = log((exp(uc))^(1-GAM));
end;
shocks;
var ea; stderr 1;
var ed; stderr 1;
end;
steady(nocheck);
check;
stoch_simul(order=3, periods=0,drop=0,irf=0,nograph,nocorr,nofunctions,nomoments);
```
triggers two issues.
1. During the `check` command, both the Linux and the Windows Octave `mex`-files trigger a `LAPACK`-error that `The generalized Schur (QZ) decomposition failed`. This is not the case on Windows, but should happen there as well, I guess.
2. When removing the call to check on Linux/Octave so that `k_order_pert` is subsequently triggered, the mod-file crashes Matlab on both Windows and Linux. Presumably this happens due to the singularity that is correctly detected by `mjdgges` on Linux, but improperly handled on all operating systems.
4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1045Clarify interface for evaluate_planner_objective.m2018-09-11T15:00:44ZMichelJuillardClarify interface for evaluate_planner_objective.mIt works OK for evaluation at the steady state, but the way to set histval and shocks in first period is confusing
It works OK for evaluation at the steady state, but the way to set histval and shocks in first period is confusing
MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/773Fix preprocessor info on auxiliary variables2019-12-19T16:28:39ZJohannes Pfeifer Fix preprocessor info on auxiliary variablesSee !770
See !770
4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1246Investigate Matlab crash caused by k_order_perturbation in a loop2018-11-07T17:45:42ZJohannes Pfeifer Investigate Matlab crash caused by k_order_perturbation in a loopThe user at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=6379 reports a Matlab crash on Windows and Linux. `k_order_perturbation` crashes Matlab on Windows, but in a strange way. When I run
```
var a c k v vk;
varexo epsilon;
predetermined_variables k;
parameters SIG DELTA ALFA BETTA RHO GAM SIGZ;
BETTA=0.95; %discount rate
DELTA=0.1; %depreciation rate
ALFA=0.3; %capital share
RHO=0.95; %persistence of technology shock
SIG=0.5; %intertemporal elasticity of substitution
GAM=2;
SIGZ = 0.005;
model;
#theta = (1-GAM)/(1-(SIG));
0 = exp(c) + exp(k(+1)) - (1-DELTA) * exp(k) - exp(a) * exp(k)^ALFA;
0 = exp(c)^(-SIG) - BETTA * exp(c(+1))^(-SIG) * (exp(v(+1))^(SIG-GAM) / exp(vk)^(1-1/theta)) * (exp(a(+1)) * ALFA * exp(k(+1))^(ALFA-1) + 1 - DELTA);
0 = a - RHO * a(-1) - SIGZ*epsilon;
0 = exp(v)^(1-SIG) - exp(c)^(1-SIG) - BETTA* exp(vk)^(1/theta);
0 = exp(vk) - exp(v(+1))^(1-GAM);
end;
steady_state_model;
%initval;
k = log(((1/BETTA+DELTA-1)/ALFA)^(1/(ALFA-1)));
c = log(exp(k)^(ALFA)-DELTA*exp(k)); %steady-state value of consumption
v = (1/(1-SIG))*log(((1/(1-BETTA)) * (exp(c)^(1-SIG))));
vk = (1-GAM)*log(exp(v));
a = 0;
end;
shocks;
var epsilon; stderr 1;
end;
steady(solve_algo=2, maxit=1000, nocheck);
check;
options_.k_order_solver=1; %this is important as then for order=3 there will be jacobia_ not found error.
stoch_simul(order=3, periods=0, drop=0, nodisplay,noprint,nograph,nocorr,nofunctions,nomoments);
```
in a loop:
```
for ii=1:10
dynare Rec1 noclearall
end
```
Matlab crashes in the third iteration. This again suggests there is an issue with running the mex-files in loops. It reminds me of the memory leak issues
Given that this issue apparently also happens under Linux, it might be easier to debug than https://github.com/DynareTeam/dynare/issues/60, https://github.com/DynareTeam/dynare/issues/612, and https://github.com/DynareTeam/dynare/issues/1026
The user at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=6379 reports a Matlab crash on Windows and Linux. `k_order_perturbation` crashes Matlab on Windows, but in a strange way. When I run
```
var a c k v vk;
varexo epsilon;
predetermined_variables k;
parameters SIG DELTA ALFA BETTA RHO GAM SIGZ;
BETTA=0.95; %discount rate
DELTA=0.1; %depreciation rate
ALFA=0.3; %capital share
RHO=0.95; %persistence of technology shock
SIG=0.5; %intertemporal elasticity of substitution
GAM=2;
SIGZ = 0.005;
model;
#theta = (1-GAM)/(1-(SIG));
0 = exp(c) + exp(k(+1)) - (1-DELTA) * exp(k) - exp(a) * exp(k)^ALFA;
0 = exp(c)^(-SIG) - BETTA * exp(c(+1))^(-SIG) * (exp(v(+1))^(SIG-GAM) / exp(vk)^(1-1/theta)) * (exp(a(+1)) * ALFA * exp(k(+1))^(ALFA-1) + 1 - DELTA);
0 = a - RHO * a(-1) - SIGZ*epsilon;
0 = exp(v)^(1-SIG) - exp(c)^(1-SIG) - BETTA* exp(vk)^(1/theta);
0 = exp(vk) - exp(v(+1))^(1-GAM);
end;
steady_state_model;
%initval;
k = log(((1/BETTA+DELTA-1)/ALFA)^(1/(ALFA-1)));
c = log(exp(k)^(ALFA)-DELTA*exp(k)); %steady-state value of consumption
v = (1/(1-SIG))*log(((1/(1-BETTA)) * (exp(c)^(1-SIG))));
vk = (1-GAM)*log(exp(v));
a = 0;
end;
shocks;
var epsilon; stderr 1;
end;
steady(solve_algo=2, maxit=1000, nocheck);
check;
options_.k_order_solver=1; %this is important as then for order=3 there will be jacobia_ not found error.
stoch_simul(order=3, periods=0, drop=0, nodisplay,noprint,nograph,nocorr,nofunctions,nomoments);
```
in a loop:
```
for ii=1:10
dynare Rec1 noclearall
end
```
Matlab crashes in the third iteration. This again suggests there is an issue with running the mex-files in loops. It reminds me of the memory leak issues
Given that this issue apparently also happens under Linux, it might be easier to debug than https://github.com/DynareTeam/dynare/issues/60, https://github.com/DynareTeam/dynare/issues/612, and https://github.com/DynareTeam/dynare/issues/1026
4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1031declare all options_ fields as empty/0/NaN in global_initialization2019-11-21T08:36:43ZHoutan Bastanideclare all options_ fields as empty/0/NaN in global_initializationFollowing the discussion on pr #1030, we must decide whether or not we want to do this and implement it throughout the code (or not)
Following the discussion on pr #1030, we must decide whether or not we want to do this and implement it throughout the code (or not)
https://git.dynare.org/Dynare/dynare/issues/1503Do we really need to have specific dynamic routines for deterministic and sto...2018-09-11T15:00:44ZStéphane Adjemianstepan@adjemian.euDo we really need to have specific dynamic routines for deterministic and stochastic models?See discussion in #1501.See discussion in #1501.https://git.dynare.org/Dynare/dynare/issues/1245Make sure _dynamic-file from block returns with proper arguments2019-12-04T14:52:11ZJohannes Pfeifer Make sure _dynamic-file from block returns with proper argumentsCurrently, there are a few `return` statements where `varargout` has not been set, leading to crashes instead of proper switching to homotopy.
Currently, there are a few `return` statements where `varargout` has not been set, leading to crashes instead of proper switching to homotopy.
4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1004Make initvalf and histvalf compatible with translation to one-lag problem2019-11-26T15:21:02ZJohannes Pfeifer Make initvalf and histvalf compatible with translation to one-lag problemWe currently have both `initvalf` and `histvalf` but with auxiliary variable substitution it is not clear to me how separate the two and how to properly initialize a model. Also, `histvalf` automatically takes care of auxiliary variables while `initvalf` does not.
Related to #617
We currently have both `initvalf` and `histvalf` but with auxiliary variable substitution it is not clear to me how separate the two and how to properly initialize a model. Also, `histvalf` automatically takes care of auxiliary variables while `initvalf` does not.
Related to #617
https://git.dynare.org/Dynare/dynare/issues/762svar identification2019-11-21T08:36:41ZHoutan Bastanisvar identificationimplement partial/global identification for svar, based on Tao's paper
implement partial/global identification for svar, based on Tao's paper
MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/1490Again investigate memory problems with k_order_perturbation on Windows2018-11-14T11:34:59ZJohannes Pfeifer Again investigate memory problems with k_order_perturbation on WindowsTwo users at https://forum.dynare.org/t/cant-work-with-third-order/10523/12 report problems with Dynare 4.5.1. I cannot replicate the issue on my machine.
The stack trace on both affected machines is
```
Register State (from fault):
RAX = 0000000000000000 RBX = 0000000000000000
RCX = 00000000000000c4 RDX = 0000000000000000
RSP = 000000012c03fe20 RBP = 000000012c03fed8
RSI = 0000000000000000 RDI = 0000000006032530
R8 = 000000012c03fdf8 R9 = 000000012c03fed8
R10 = 0000000000000000 R11 = 0000000000000206
R12 = 0000000000000000 R13 = 0000000000000000
R14 = 0000000000000000 R15 = 0000000000000000
RIP = 000000002911f5c7 EFL = 00010202
CS = 0033 FS = 0053 GS = 002b
Stack Trace (from fault):
[ 0] 0x000000002911f5c7 C:\dynare\4.5.1\mex\matlab\win64-7.8-9.2\k_order_perturbation.mexw64+00390599 mexFunction+00384471
[ 1] 0x00000000290eca69 C:\dynare\4.5.1\mex\matlab\win64-7.8-9.2\k_order_perturbation.mexw64+00182889 mexFunction+00176761
[ 2] 0x0000000029120cc4 C:\dynare\4.5.1\mex\matlab\win64-7.8-9.2\k_order_perturbation.mexw64+00396484 mexFunction+00390356
[ 3] 0x000007feff08415f C:\Windows\system32\msvcrt.dll+00016735 srand+00000147
[ 4] 0x000007feff086ebd C:\Windows\system32\msvcrt.dll+00028349 ftime64_s+00000477
[ 5] 0x0000000076a659cd C:\Windows\system32\kernel32.dll+00088525 BaseThreadInitThunk+00000013
[ 6] 0x000000007717a561 C:\Windows\SYSTEM32\ntdll.dll+00173409 RtlUserThreadStart+00000033
```
So it might have to do with Visual Studies's `msvcrt.dll` and the random number generator's call to the system time.Two users at https://forum.dynare.org/t/cant-work-with-third-order/10523/12 report problems with Dynare 4.5.1. I cannot replicate the issue on my machine.
The stack trace on both affected machines is
```
Register State (from fault):
RAX = 0000000000000000 RBX = 0000000000000000
RCX = 00000000000000c4 RDX = 0000000000000000
RSP = 000000012c03fe20 RBP = 000000012c03fed8
RSI = 0000000000000000 RDI = 0000000006032530
R8 = 000000012c03fdf8 R9 = 000000012c03fed8
R10 = 0000000000000000 R11 = 0000000000000206
R12 = 0000000000000000 R13 = 0000000000000000
R14 = 0000000000000000 R15 = 0000000000000000
RIP = 000000002911f5c7 EFL = 00010202
CS = 0033 FS = 0053 GS = 002b
Stack Trace (from fault):
[ 0] 0x000000002911f5c7 C:\dynare\4.5.1\mex\matlab\win64-7.8-9.2\k_order_perturbation.mexw64+00390599 mexFunction+00384471
[ 1] 0x00000000290eca69 C:\dynare\4.5.1\mex\matlab\win64-7.8-9.2\k_order_perturbation.mexw64+00182889 mexFunction+00176761
[ 2] 0x0000000029120cc4 C:\dynare\4.5.1\mex\matlab\win64-7.8-9.2\k_order_perturbation.mexw64+00396484 mexFunction+00390356
[ 3] 0x000007feff08415f C:\Windows\system32\msvcrt.dll+00016735 srand+00000147
[ 4] 0x000007feff086ebd C:\Windows\system32\msvcrt.dll+00028349 ftime64_s+00000477
[ 5] 0x0000000076a659cd C:\Windows\system32\kernel32.dll+00088525 BaseThreadInitThunk+00000013
[ 6] 0x000000007717a561 C:\Windows\SYSTEM32\ntdll.dll+00173409 RtlUserThreadStart+00000033
```
So it might have to do with Visual Studies's `msvcrt.dll` and the random number generator's call to the system time.4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1243Allow model-local variables with block and bytecode2018-09-11T15:00:44ZJohannes Pfeifer Allow model-local variables with block and bytecodeWe currently return the error
`'block' or 'bytecode' options are not yet compatible with pound expressions`
Given that `steady_state_model` cannot be used for handling parameter dependence in the `perfect_foresight`, model-local variables seem the only way to go. We should therefore allow them.
@houtanb Where exactly is the challenge from the proprocessor-side?
We currently return the error
`'block' or 'bytecode' options are not yet compatible with pound expressions`
Given that `steady_state_model` cannot be used for handling parameter dependence in the `perfect_foresight`, model-local variables seem the only way to go. We should therefore allow them.
@houtanb Where exactly is the challenge from the proprocessor-side?
FerhatMihoubiFerhatMihoubihttps://git.dynare.org/Dynare/dynare/issues/978Fix interface/options for stochastic extended path in master2019-04-01T07:09:38ZJohannes Pfeifer Fix interface/options for stochastic extended path in masterNot all required options are set by default. For example, `rs2.mod` needs to manually set
```
options_.ep.IntegrationAlgorithm='UT_2p+1';
```
as otherwise a crash in `setup_integration_nodes.m` happens. We should properly initialize all options and add a unit test that tests the default options.
Not all required options are set by default. For example, `rs2.mod` needs to manually set
```
options_.ep.IntegrationAlgorithm='UT_2p+1';
```
as otherwise a crash in `setup_integration_nodes.m` happens. We should properly initialize all options and add a unit test that tests the default options.
MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/713Block recursive prior definitions2018-09-11T15:00:44ZJohannes Pfeifer Block recursive prior definitionsRecursive specification of priors seem to be currently allowed, e.g.
```
a1 0.2,1E-5,1, BETA_PDF,0.5,0.1;
a2 0.5,1E-5,1, a1 BETA_PDF,0.85,0.1;
```
where the upper bound for `a2` is actually set based on the value `a1` has in the parameter initialization section (and never updates it during estimation based on new values of `a1`). But the user clearly intends to make the prior conditional, which Dynare does not allow. We should block this kind of behavior in the preprocessor, because the actual behavior is unexpected.
Sidenote: would it be sensible to allow for conditional priors at some point in the future?
Recursive specification of priors seem to be currently allowed, e.g.
```
a1 0.2,1E-5,1, BETA_PDF,0.5,0.1;
a2 0.5,1E-5,1, a1 BETA_PDF,0.85,0.1;
```
where the upper bound for `a2` is actually set based on the value `a1` has in the parameter initialization section (and never updates it during estimation based on new values of `a1`). But the user clearly intends to make the prior conditional, which Dynare does not allow. We should block this kind of behavior in the preprocessor, because the actual behavior is unexpected.
Sidenote: would it be sensible to allow for conditional priors at some point in the future?
https://git.dynare.org/Dynare/dynare/issues/1225Make sure mex-files are compatible with 64bit Matlab2018-11-09T10:20:27ZJohannes Pfeifer Make sure mex-files are compatible with 64bit MatlabSee http://de.mathworks.com/help/matlab/matlab_external/upgrading-mex-files-to-use-64-bit-api.html
See http://de.mathworks.com/help/matlab/matlab_external/upgrading-mex-files-to-use-64-bit-api.html
Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/933Add load_mh_file-like option for loading posterior subdraws2018-09-11T15:00:44ZJohannes Pfeifer Add load_mh_file-like option for loading posterior subdrawsSee #566
See #566
https://git.dynare.org/Dynare/dynare/issues/709Preprocessor: Allow reusage of model local variable names in steady_state_mod...2018-09-11T15:00:44ZTom HoldenPreprocessor: Allow reusage of model local variable names in steady_state_model block (wishlist)At present, variables with the same name as model local variables cannot be created in the `steady_state_model` block. It would be very nice if the preprocessor to a C style approach to variable scope, and allowed the creation of variables with the same name in different blocks, when neither block contains the other. An example of quite why this would be useful follows:
An operation I find myself performing frequently is replacing e.g. the endogenous variable `Y` with the endogenous variable `log_Y`. I then create a model local variable for `Y` via `#Y = exp( log_Y );`. Ideally, I should just have to add the line `log_Y = log( Y );` to the end of the `steady_state_model` block for the new `.mod` file to run. However, just doing this produces an error since I'm now using `Y` as a temporary variable within the `steady_state_model` block. Thus I have to make assorted modifications to the `steady_state_model` block to first remove all references to `Y`.
For an example of this in practice, see `example.mod` in https://github.com/tholden/DynareTransformationEngine , which is a repository for making such transformations automatically, chiefly produced as an example of what is possible with the preprocessor. This runs at present, but doesn't if you remove the suffix underscores from the `steady_state_model` block.
At present, variables with the same name as model local variables cannot be created in the `steady_state_model` block. It would be very nice if the preprocessor to a C style approach to variable scope, and allowed the creation of variables with the same name in different blocks, when neither block contains the other. An example of quite why this would be useful follows:
An operation I find myself performing frequently is replacing e.g. the endogenous variable `Y` with the endogenous variable `log_Y`. I then create a model local variable for `Y` via `#Y = exp( log_Y );`. Ideally, I should just have to add the line `log_Y = log( Y );` to the end of the `steady_state_model` block for the new `.mod` file to run. However, just doing this produces an error since I'm now using `Y` as a temporary variable within the `steady_state_model` block. Thus I have to make assorted modifications to the `steady_state_model` block to first remove all references to `Y`.
For an example of this in practice, see `example.mod` in https://github.com/tholden/DynareTransformationEngine , which is a repository for making such transformations automatically, chiefly produced as an example of what is possible with the preprocessor. This runs at present, but doesn't if you remove the suffix underscores from the `steady_state_model` block.
https://git.dynare.org/Dynare/dynare/issues/1483if Dynare++ will not be built, do not build mex files that depend on it2019-08-14T12:33:08ZHoutan Bastaniif Dynare++ will not be built, do not build mex files that depend on it`mex/build/matlab/configure.ac` does not account for the case when makefiles are not created for dynare++ by the main configure script. Hence, `libdynare++` and `gensylv` will still be built, causing an error. See #1482.
Easy solution: test for BLAS, LAPACK, and MatIO. don't build `libdynare++`, `gensylv`, `k_order_perturbation`, or `dynare_simul_` if one of these libraries is not found (same test that we implement for building Dynare++ in the main config file.
Another solution would be to pass the value of `BUILD_DYNAREPLUSPLUS` to `AC_CONFIG_SUBDIRS([mex/build/matlab])` in `configure.ac``mex/build/matlab/configure.ac` does not account for the case when makefiles are not created for dynare++ by the main configure script. Hence, `libdynare++` and `gensylv` will still be built, causing an error. See #1482.
Easy solution: test for BLAS, LAPACK, and MatIO. don't build `libdynare++`, `gensylv`, `k_order_perturbation`, or `dynare_simul_` if one of these libraries is not found (same test that we implement for building Dynare++ in the main config file.
Another solution would be to pass the value of `BUILD_DYNAREPLUSPLUS` to `AC_CONFIG_SUBDIRS([mex/build/matlab])` in `configure.ac`4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1210Allow string arrays to be passed to options2018-11-09T14:13:22ZHoutan BastaniAllow string arrays to be passed to optionsFollowing the discussion in #1199, allow the preprocessor to accept string array values: `['a' 'b' 'c']`
Following the discussion in #1199, allow the preprocessor to accept string array values: `['a' 'b' 'c']`
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/915Integrate convert_dyn_45_to_44 into convert_oo_.m2019-11-27T13:11:55ZJohannes Pfeifer Integrate convert_dyn_45_to_44 into convert_oo_.mSee the discussion in https://github.com/DynareTeam/dynare/commit/a93e0157e4ea0d3a2ee4d5b10842066a0a39c2e9#commitcomment-10984144
See the discussion in https://github.com/DynareTeam/dynare/commit/a93e0157e4ea0d3a2ee4d5b10842066a0a39c2e9#commitcomment-10984144
4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/699Allow for constrained forecast paths of different length2019-09-20T13:05:20ZJohannes Pfeifer Allow for constrained forecast paths of different lengthUser request, see http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5888
User request, see http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5888