dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2019-06-19T15:37:45Zhttps://git.dynare.org/Dynare/dynare/-/issues/1377Decide on treatment of qz_criterium in estimation with particle filter2019-06-19T15:37:45ZJohannes PfeiferDecide on treatment of qz_criterium in estimation with particle filterCurrently, if a unit root is present, estimation with `order=2` will result in an error. Using `diffuse_filter` will disable the check, but obviously makes no sense for particle filtering. See http://www.dynare.org/phpBB3/viewtopic.php?f...Currently, if a unit root is present, estimation with `order=2` will result in an error. Using `diffuse_filter` will disable the check, but obviously makes no sense for particle filtering. See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=131264.6https://git.dynare.org/Dynare/dynare/-/issues/1364Allow loading data from mat-files that contain other variables2019-06-19T15:37:45ZJohannes PfeiferAllow loading data from mat-files that contain other variablesWe rely on `load_mat_file_data.m` from `dseries` to read in `mat`-files. There we use
```
for i=1:length(varlist)
try
tmp = getfield(datafile,varlist{i});
data = [data, tmp(:)];
catch
error(['load_...We rely on `load_mat_file_data.m` from `dseries` to read in `mat`-files. There we use
```
for i=1:length(varlist)
try
tmp = getfield(datafile,varlist{i});
data = [data, tmp(:)];
catch
error(['load_mat_file:: All the vectors (variables) in ' inputname(1) ' must have the same number of rows (observations)!'])
end
end
```
to read _all_ variables and concatenate them in an array. If there is any other variable in the mat-file that does not have conformable dimensions, we abort with a crash. This deviates from earlier behavior and will result in many users reporting problems with backward compatibility if we release `4.5` this way. Is there a way to only load the specified `varobs`? Currently, it seems impossible to pass this through the `dseries`.4.6https://git.dynare.org/Dynare/dynare/-/issues/1359Add interface to load datafile in Matlab's table-format2019-12-03T14:45:18ZJohannes PfeiferAdd 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/1355Allow adding auxiliary variables like Ramsey multipliers to var_list_2022-12-05T19:48:51ZJohannes PfeiferAllow adding auxiliary variables like Ramsey multipliers to var_list_The auxiliary variables are endogenous variables like every other variable. A call like
`ramsey_policy(instruments=(i),irf=13,planner_discount=betta,periods=200) x pi MULT_1;`
would be suficient to display IRFs for the multiplier 1. H...The auxiliary variables are endogenous variables like every other variable. A call like
`ramsey_policy(instruments=(i),irf=13,planner_discount=betta,periods=200) x pi MULT_1;`
would be suficient to display IRFs for the multiplier 1. However, the preprocessor does not allow adding `MULT_1` to the variable list, because:
`Unknown symbol: MULT_1`
We should allow adding any variable present in `M_.endo_names` to the `var_list_`. @houtanb Could you do this, please?
Related to http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=121174.6Houtan BastaniHoutan Bastanihttps://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 `__M...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/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.6https://git.dynare.org/Dynare/dynare/-/issues/1304Octave out of memory issues2018-11-09T14:50:08ZJohannes PfeiferOctave 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...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/1250Investigate mex-file issues2018-11-09T14:09:56ZJohannes PfeiferInvestigate 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.9...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/1246Investigate Matlab crash caused by k_order_perturbation in a loop2018-11-07T17:45:42ZJohannes PfeiferInvestigate 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;
pre...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/1245Make sure _dynamic-file from block returns with proper arguments2019-12-04T14:52:11ZJohannes PfeiferMake 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/1205Allows period=1 with all perfect foresight model solvers2019-04-26T14:25:20ZStéphane Adjemianstepan@adjemian.euAllows period=1 with all perfect foresight model solversSee discussion in #1176.
See discussion in #1176.
4.6Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1197Get rid of globals in various functions2019-09-13T08:16:48ZJohannes PfeiferGet rid of globals in various functionsAs discussed with @MichelJuillard, we should try to get rid of globals in
- `stoch_simul`
- `simult_`
as most of their callers and subsequently called functions already use local instances of the variables
As discussed with @MichelJuillard, we should try to get rid of globals in
- `stoch_simul`
- `simult_`
as most of their callers and subsequently called functions already use local instances of the variables
4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1093Discuss changing options_.hp_ngrid2020-01-20T17:41:57ZJohannes PfeiferDiscuss 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 opt...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/915Integrate convert_dyn_45_to_44 into convert_oo_.m2020-09-03T16:10:28ZJohannes PfeiferIntegrate 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/825Fix using steady state operator on exogenous variables2019-11-27T16:33:42ZJohannes PfeiferFix 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...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/773Fix preprocessor info on auxiliary variables2019-12-19T16:28:39ZJohannes PfeiferFix preprocessor info on auxiliary variablesSee !770
See !770
4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/637M_.state_var2020-02-11T10:08:30ZMichelJuillardM_.state_varCurrently, the vector M_.state_var is created by the preprocessor only when estimation is taking place. Because, this vector contains information useful in any context involving linear representation, I suggest to create it in all cases....Currently, the vector M_.state_var is created by the preprocessor only when estimation is taking place. Because, this vector contains information useful in any context involving linear representation, I suggest to create it in all cases.
M_.state_var points to variables in declaration order, but is not sorted. This is confusing
In addition, dr_block copies it to oo_.dr. This is confusing.
4.6Johannes PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/263latex variable with exponent causes compilation error2020-01-13T17:40:52ZSébastien Villemotlatex variable with exponent causes compilation errorSee: http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=3846
Quick fix is to require users to place brackets around latex
variables containing exponents (and probably underscores)
Complete fix is to place braces around variables with le...See: http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=3846
Quick fix is to require users to place brackets around latex
variables containing exponents (and probably underscores)
Complete fix is to place braces around variables with lead/lags and those variables with no lead/lag but that are followed by an exponent. In the user's case, we would output: B^problem_t-1^\rho
4.6Houtan BastaniHoutan Bastani