dynare issueshttps://git.dynare.org/Dynare/dynare/issues2019-06-19T15:37:49Zhttps://git.dynare.org/Dynare/dynare/issues/1272Account for MAC in AnalyseComputationalEnvironment.m and GiveCPUnumber.m2019-06-19T15:37:49ZJohannes Pfeifer Account for MAC in AnalyseComputationalEnvironment.m and GiveCPUnumber.mThe call to
`[si0 de0]=system('grep processor /proc/cpuinfo');`
should be
`[si0 de0]=system('sysctl -a | grep machdep.cpu | grep core_count');` (see http://fortysomethinggeek.blogspot.de/2012/11/getting-cpu-info-from-command-line-in.html)
`GiveCPUnumber.m` then also needs to be adjusted to account for this.
Related to #838
The call to
`[si0 de0]=system('grep processor /proc/cpuinfo');`
should be
`[si0 de0]=system('sysctl -a | grep machdep.cpu | grep core_count');` (see http://fortysomethinggeek.blogspot.de/2012/11/getting-cpu-info-from-command-line-in.html)
`GiveCPUnumber.m` then also needs to be adjusted to account for this.
Related to #838
4.5https://git.dynare.org/Dynare/dynare/issues/1266bug with eig in Matlab R2012a2019-06-19T15:37:49ZHoutan Bastanibug with eig in Matlab R2012aOn line 197 of `matlab/identification_analysis.m`, we have `[V,D,W]=eig(cc);`. In older versions of Matlab, eig only has two output arguments and hence this causes an error. To calculate `W`, the left eigenvectors of cc, the documentation recommends `[W,junk] = eig(cc.'); W = conj(W)` separately.
On line 197 of `matlab/identification_analysis.m`, we have `[V,D,W]=eig(cc);`. In older versions of Matlab, eig only has two output arguments and hence this causes an error. To calculate `W`, the left eigenvectors of cc, the documentation recommends `[W,junk] = eig(cc.'); W = conj(W)` separately.
4.5Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/1264Block exogenous variables from being used in planner_objective2019-06-19T15:37:49ZJohannes Pfeifer Block exogenous variables from being used in planner_objectiveCurrently, exogenous variables in the `planner_objective` are simply ignored in the preprocessor. When using
```
var pai, c, n, r, a;
varexo u;
parameters beta, rho, epsilon, omega, phi, gamma;
beta=0.99;
gamma=3; //Frisch elasticity
omega=17; //price stickyness
epsilon=8; //elasticity for each variety of consumption
phi=1; //coefficient associated to labor effort disutility
rho=0.95; //coefficient associated to productivity shock
model;
a=rho*(a(-1))+u;
1/c=beta*(1/(c(+1)))*(r/(pai(+1))); //euler
omega*pai*(pai-1)=beta*omega*(c/(c(+1)))*(pai(+1))*(pai(+1)-1)+epsilon*exp(a)*n*(c/exp(a)*phi*n^gamma-(epsilon-1)/epsilon); //NK pc
//pai*(pai-1)/c = beta*pai(+1)*(pai(+1)-1)/c(+1)+epsilon*phi*n^(gamma+1)/omega-exp(a)*n*(epsilon-1)/(omega*c); //NK pc
(exp(a))*n=c+(omega/2)*((pai-1)^2);
end;
initval;
pai=1;
r=1/beta;
c=0.9671684882;
n=0.9671684882;
a=0;
u=0;
end;
histval;
a(0)=0.9;
end;
shocks;
var u; stderr 0.008;
end;
planner_objective(ln(c)-phi*((n^(1+gamma))/(1+gamma))*exp(u));
ramsey_policy(order=1,planner_discount=0.99);
```
the `exp(u)` does not appear in `_model_objective_static`. This is problematic, because in principle shocks at time t are part of the information set and should enter the objective. For that reason, @MichelJuillard agreed that we should block using exogenous variables in the objective and instead provide an error message like
`You cannot handle exogenous variables in the planner objective. Please define an auxiliary endogenous variable like eps_aux=epsilon and use it instead of the varexo`
Currently, exogenous variables in the `planner_objective` are simply ignored in the preprocessor. When using
```
var pai, c, n, r, a;
varexo u;
parameters beta, rho, epsilon, omega, phi, gamma;
beta=0.99;
gamma=3; //Frisch elasticity
omega=17; //price stickyness
epsilon=8; //elasticity for each variety of consumption
phi=1; //coefficient associated to labor effort disutility
rho=0.95; //coefficient associated to productivity shock
model;
a=rho*(a(-1))+u;
1/c=beta*(1/(c(+1)))*(r/(pai(+1))); //euler
omega*pai*(pai-1)=beta*omega*(c/(c(+1)))*(pai(+1))*(pai(+1)-1)+epsilon*exp(a)*n*(c/exp(a)*phi*n^gamma-(epsilon-1)/epsilon); //NK pc
//pai*(pai-1)/c = beta*pai(+1)*(pai(+1)-1)/c(+1)+epsilon*phi*n^(gamma+1)/omega-exp(a)*n*(epsilon-1)/(omega*c); //NK pc
(exp(a))*n=c+(omega/2)*((pai-1)^2);
end;
initval;
pai=1;
r=1/beta;
c=0.9671684882;
n=0.9671684882;
a=0;
u=0;
end;
histval;
a(0)=0.9;
end;
shocks;
var u; stderr 0.008;
end;
planner_objective(ln(c)-phi*((n^(1+gamma))/(1+gamma))*exp(u));
ramsey_policy(order=1,planner_discount=0.99);
```
the `exp(u)` does not appear in `_model_objective_static`. This is problematic, because in principle shocks at time t are part of the information set and should enter the objective. For that reason, @MichelJuillard agreed that we should block using exogenous variables in the objective and instead provide an error message like
`You cannot handle exogenous variables in the planner objective. Please define an auxiliary endogenous variable like eps_aux=epsilon and use it instead of the varexo`
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1219Tabular output of variance decomposition after Bayesian MH estimation2019-06-19T15:37:49ZStéphane Adjemianstepan@dynare.orgTabular output of variance decomposition after Bayesian MH estimation*Created by: BenjaminBorn*
Dear all,
Johannes asked me to open this as an issue. Would it be possible to provide the output from the conditional variance decomposition after Bayesian estimation in tabular form?
Thanks,
Benjamin
*Created by: BenjaminBorn*
Dear all,
Johannes asked me to open this as an issue. Would it be possible to provide the output from the conditional variance decomposition after Bayesian estimation in tabular form?
Thanks,
Benjamin
4.5https://git.dynare.org/Dynare/dynare/issues/1259normcdf is not supported using MSVC for use_dll2019-06-19T15:37:49ZTom Holdennormcdf is not supported using MSVC for use_dllnormcdf has a one line implementation using standard library functions (included in MSVC), namely:
```
double normcdf(double value)
{
return 0.5 * erfc(-value * M_SQRT1_2);
}
```
It seems a little unnecessary for this not to be supported with MSVC.
normcdf has a one line implementation using standard library functions (included in MSVC), namely:
```
double normcdf(double value)
{
return 0.5 * erfc(-value * M_SQRT1_2);
}
```
It seems a little unnecessary for this not to be supported with MSVC.
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1249Add preprocessor interface for setting perfect foresight tolerance2019-06-19T15:37:49ZJohannes Pfeifer Add preprocessor interface for setting perfect foresight toleranceCurrently, one must manually set `options_.dynatol.f`. I would suggest to use the name `TolFun` for the option.
While we are at it, I would also suggest to use an option `TolFun` for the `steady` command to set `options_.solve_tolf`
Currently, one must manually set `options_.dynatol.f`. I would suggest to use the name `TolFun` for the option.
While we are at it, I would also suggest to use an option `TolFun` for the `steady` command to set `options_.solve_tolf`
4.5Johannes Pfeifer Johannes Pfeifer https://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/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/1237Investigate identification problem2019-06-19T15:37:49ZJohannes Pfeifer Investigate identification problemhttp://www.dynare.org/phpBB3/viewtopic.php?f=1&t=8234
Sent email with mod-file to @rattoma on June 1, 2016
http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=8234
Sent email with mod-file to @rattoma on June 1, 2016
4.5Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/1232Remove onlyclearglobals option2019-06-19T15:37:49ZJohannes Pfeifer Remove onlyclearglobals optionIt was introduced in master, but is now redundant with the `clear all` command being removed due to Matlab's JIT
It was introduced in master, but is now redundant with the `clear all` command being removed due to Matlab's JIT
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/1227Solve use_dll-incompatibility problem on Windows in master2019-06-19T15:37:49ZJohannes Pfeifer Solve use_dll-incompatibility problem on Windows in masterAfter merging the `temporary_terms`-branch (https://github.com/DynareTeam/dynare/commit/127637ffd672fdd8143ee13f2a38234e597d94d3) the `c`-files created are not `C89`-compatible, but require `C99`. This is a problem for Windows machines as Visual Studio before version 2015 only supported `C89`, resulting in errors of the form
`error C2143: syntax error : missing ';' before 'type'`
Before Matlab version `R2014b` users could use the `cygwin`-option by using the provided `mexopts-win64.bat` from http://www.dynare.org/DynareWiki/ConfigureMatlabWindowsForMexCompilation, which should not have this restriction. Since `R2015b`, `mingw` is available, which also supports `C99` (#1226). Moreover, Visual Studio 2015 finally supports `C99` and has a free available version that is supported since `R2015b`. That leaves 64bit Matlab-versions between `R2014a` and `R2015a` unable to deal with the problem unless someone figures out how to solve #641 for `cygwin` (potentially following the advice on how to set up the `xml`-file at http://stackoverflow.com/questions/8552580/using-gcc-mingw-as-matlabs-mex-compiler). Given that there seems to be not that much demand for `use_dll` on Windows, I would propose for 4.5 to focus on the `mingw`-support and state the above restrictions clearly in the release notes and the manual
After merging the `temporary_terms`-branch (https://github.com/DynareTeam/dynare/commit/127637ffd672fdd8143ee13f2a38234e597d94d3) the `c`-files created are not `C89`-compatible, but require `C99`. This is a problem for Windows machines as Visual Studio before version 2015 only supported `C89`, resulting in errors of the form
`error C2143: syntax error : missing ';' before 'type'`
Before Matlab version `R2014b` users could use the `cygwin`-option by using the provided `mexopts-win64.bat` from http://www.dynare.org/DynareWiki/ConfigureMatlabWindowsForMexCompilation, which should not have this restriction. Since `R2015b`, `mingw` is available, which also supports `C99` (#1226). Moreover, Visual Studio 2015 finally supports `C99` and has a free available version that is supported since `R2015b`. That leaves 64bit Matlab-versions between `R2014a` and `R2015a` unable to deal with the problem unless someone figures out how to solve #641 for `cygwin` (potentially following the advice on how to set up the `xml`-file at http://stackoverflow.com/questions/8552580/using-gcc-mingw-as-matlabs-mex-compiler). Given that there seems to be not that much demand for `use_dll` on Windows, I would propose for 4.5 to focus on the `mingw`-support and state the above restrictions clearly in the release notes and the manual
4.5https://git.dynare.org/Dynare/dynare/issues/1226Support mingw-compiler on Windows2019-06-19T15:37:49ZJohannes Pfeifer Support mingw-compiler on WindowsSince Matlab2014a, the `mexopts.bat` cannot be used anymore to set the mex-compiler to `cygwin`, rendering it pretty much useless for most recent versions. However, Mathworks now has a MinGW-addon (http://de.mathworks.com/help/matlab/matlab_external/install-mingw-support-package.html) that we should support.
For this, we need to
1. Allow for a `mingw` command line flag
2. Adjust `dyn_mex` with the respective case distinction and necessary flags
3. Update http://www.dynare.org/DynareWiki/ConfigureMatlabWindowsForMexCompilation
Since Matlab2014a, the `mexopts.bat` cannot be used anymore to set the mex-compiler to `cygwin`, rendering it pretty much useless for most recent versions. However, Mathworks now has a MinGW-addon (http://de.mathworks.com/help/matlab/matlab_external/install-mingw-support-package.html) that we should support.
For this, we need to
1. Allow for a `mingw` command line flag
2. Adjust `dyn_mex` with the respective case distinction and necessary flags
3. Update http://www.dynare.org/DynareWiki/ConfigureMatlabWindowsForMexCompilation
4.5Houtan BastaniJohannes Pfeifer Houtan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1215qz_criterium in estimation2019-06-19T15:37:49ZMarco Rattoqz_criterium in estimationI think it would be useful to allow option `qz_criterium` also in estimation, similarly to simulation. Would it be possible? Is there any strong reason for not allowing this?
I think it would be useful to allow option `qz_criterium` also in estimation, similarly to simulation. Would it be possible? Is there any strong reason for not allowing this?
4.5https://git.dynare.org/Dynare/dynare/issues/1209rework recent static model preprocessor changes2019-06-19T15:37:49ZHoutan Bastanirework recent static model preprocessor changesThe changes to the preprocessor made in 6e514b7d1bfc4b76fbc483da1da0ae7416de7cda have been made in the `computingPass` when they should have been made in the `transformPass`. Move these changes from `StaticModel::computingPass` to `DynamicModel::toStatic`
The changes to the preprocessor made in 6e514b7d1bfc4b76fbc483da1da0ae7416de7cda have been made in the `computingPass` when they should have been made in the `transformPass`. Move these changes from `StaticModel::computingPass` to `DynamicModel::toStatic`
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1211Check newrat-implementation and potentially port Michel's changes2019-06-19T15:37:49ZJohannes Pfeifer Check newrat-implementation and potentially port Michel's changesDuring his first try of removing `objective_function_penalty_base` @MichelJuillard made various changes to `newrat` that were reverted, but potentially still need to be ported to `master`. But I am not entirely sure what these commits do. @rattoma Could you maybe have a look.
1. In the reverted commits https://github.com/DynareTeam/dynare/commit/fe077fc7103658aab7becba95167aa9d240b07f1 and https://github.com/DynareTeam/dynare/commit/f48a026d89828e9e322333263f56b733a719eb34 the initialization of `mr_hessian` was removed.
2. In https://github.com/DynareTeam/dynare/commit/5ade8d7c6fc71cc4ee4ffbb27dad2ed6b4cf8ccd the `newratflag`was passed to the optimizer, but this was reverted in https://github.com/DynareTeam/dynare/commit/d4cf3576e468202df9d1582a045dfcfd74e2e7db . What is the correct setting here?
3. In https://github.com/DynareTeam/dynare/commit/5ade8d7c6fc71cc4ee4ffbb27dad2ed6b4cf8ccd the part
```
if analytic_derivation,
hhx=hh;
else
hhx = reshape(dum,nx,nx);
end
```
was replaced by
`hhx=hh;`
But when I tried this, the program crashed in tests.
During his first try of removing `objective_function_penalty_base` @MichelJuillard made various changes to `newrat` that were reverted, but potentially still need to be ported to `master`. But I am not entirely sure what these commits do. @rattoma Could you maybe have a look.
1. In the reverted commits https://github.com/DynareTeam/dynare/commit/fe077fc7103658aab7becba95167aa9d240b07f1 and https://github.com/DynareTeam/dynare/commit/f48a026d89828e9e322333263f56b733a719eb34 the initialization of `mr_hessian` was removed.
2. In https://github.com/DynareTeam/dynare/commit/5ade8d7c6fc71cc4ee4ffbb27dad2ed6b4cf8ccd the `newratflag`was passed to the optimizer, but this was reverted in https://github.com/DynareTeam/dynare/commit/d4cf3576e468202df9d1582a045dfcfd74e2e7db . What is the correct setting here?
3. In https://github.com/DynareTeam/dynare/commit/5ade8d7c6fc71cc4ee4ffbb27dad2ed6b4cf8ccd the part
```
if analytic_derivation,
hhx=hh;
else
hhx = reshape(dum,nx,nx);
end
```
was replaced by
`hhx=hh;`
But when I tried this, the program crashed in tests.
4.5https://git.dynare.org/Dynare/dynare/issues/1208updated2histval2018-11-08T10:17:14ZMarco Rattoupdated2histvalfor real time forecasting exercises, it would be useful a utility
`updated2histval`
with the same behavior as:
`smoother2histval`
but that uses `oo_.UpdatedVariables` in place of `oo_.SmoothedVariables`
would this be feasible?
for real time forecasting exercises, it would be useful a utility
`updated2histval`
with the same behavior as:
`smoother2histval`
but that uses `oo_.UpdatedVariables` in place of `oo_.SmoothedVariables`
would this be feasible?
5.0https://git.dynare.org/Dynare/dynare/issues/1205Allows period=1 with all perfect foresight model solvers2019-04-26T14:25:20ZStéphane Adjemianstepan@dynare.orgAllows period=1 with all perfect foresight model solversSee discussion in #1176.
See discussion in #1176.
4.6Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1204Crash in unstable mex when called from parallel workers2018-11-08T10:16:48ZTom HoldenCrash in unstable mex when called from parallel workersI'm afraid I don't have time to produce a minimal example of this bug now, but I'll leave the replication steps here in case anyone else does.
1) Download my version of Dynare, with sub-modules from https://github.com/tholden/dynare
2) Replace the files in the mex subfolder with those from the latest unstable.
3) Browse to the dynare\examples\nonlinear-estimation directory within MATLAB, and then execute `dynare NKNonCentralEstimate.mod`
4) Note that Dynare correctly calculates the initial likelihood, but then when it starts calculating the first numerical derivative of the likelihood, in parallel, each of the parallel workers crash in turn.
5) Reset the repository so you have my compiled MEX. Rerun the same test and observe that the parallel workers do not crash.
I would strongly expect that in fact you don't need to use my version of Dynare, or to use my code for estimating an approximation around the mean, and in the latest unstable this ought to be present whenever you evaluate the likelihood in parallel.
I'm afraid I don't have time to produce a minimal example of this bug now, but I'll leave the replication steps here in case anyone else does.
1) Download my version of Dynare, with sub-modules from https://github.com/tholden/dynare
2) Replace the files in the mex subfolder with those from the latest unstable.
3) Browse to the dynare\examples\nonlinear-estimation directory within MATLAB, and then execute `dynare NKNonCentralEstimate.mod`
4) Note that Dynare correctly calculates the initial likelihood, but then when it starts calculating the first numerical derivative of the likelihood, in parallel, each of the parallel workers crash in turn.
5) Reset the repository so you have my compiled MEX. Rerun the same test and observe that the parallel workers do not crash.
I would strongly expect that in fact you don't need to use my version of Dynare, or to use my code for estimating an approximation around the mean, and in the latest unstable this ought to be present whenever you evaluate the likelihood in parallel.
5.0Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1203In the latest unstable, sparse_hessian_times_B_kronecker_C.mexw64 has a depen...2019-06-19T15:37:50ZTom HoldenIn the latest unstable, sparse_hessian_times_B_kronecker_C.mexw64 has a dependency on libgomp-1.dllI was getting errors about missing dependencies. Running Dependency Walker on it revealed libgomp-1.dll as the problem. Copying this across from MinGW fixed the issue.
I was getting errors about missing dependencies. Running Dependency Walker on it revealed libgomp-1.dll as the problem. Copying this across from MinGW fixed the issue.
4.5https://git.dynare.org/Dynare/dynare/issues/1201Depth issue2019-06-19T15:37:50ZStéphane Adjemianstepan@dynare.orgDepth issueLooking into #1175 , by reverting commit 3c7e60b744567f6f39a9c611bce6dcaadcd52bc6, I obtained the following error from matlab when trying to run Christiano-Motto-Rostagno model (the one in subfolder `figure4` of the archive available [here](http://faculty.wcas.northwestern.edu/~lchrist/research/ECB/risk_shocks/20100922_data.zip)
```
Error: File: cmr_static.m Line: 1292 Column: 16331
Nesting of {, [, and ( cannot exceed a depth of 32.
```
@MichelJuillard May this be a consequence of your patch about on auxiliary variables in steady state and static files (see #1133)?
Looking into #1175 , by reverting commit 3c7e60b744567f6f39a9c611bce6dcaadcd52bc6, I obtained the following error from matlab when trying to run Christiano-Motto-Rostagno model (the one in subfolder `figure4` of the archive available [here](http://faculty.wcas.northwestern.edu/~lchrist/research/ECB/risk_shocks/20100922_data.zip)
```
Error: File: cmr_static.m Line: 1292 Column: 16331
Nesting of {, [, and ( cannot exceed a depth of 32.
```
@MichelJuillard May this be a consequence of your patch about on auxiliary variables in steady state and static files (see #1133)?
4.5Houtan BastaniHoutan Bastani