dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2018-11-07T17:45:42Zhttps://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/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/1490Again investigate memory problems with k_order_perturbation on Windows2018-11-14T11:34:59ZJohannes PfeiferAgain 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...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/1314octave does not need the compiler argument when using use_dll2019-06-19T15:37:47ZHoutan Bastanioctave does not need the compiler argument when using use_dllThe preprocessor requires Windows users to pass the name of the compiler on their system when using `use_dll`. This is not necessary on Octave, as evidenced by `matlab/utilities/general/dyn_mex.m`. Fix `preprocessor/ModFile.cc` appropria...The preprocessor requires Windows users to pass the name of the compiler on their system when using `use_dll`. This is not necessary on Octave, as evidenced by `matlab/utilities/general/dyn_mex.m`. Fix `preprocessor/ModFile.cc` appropriately.
See discussion here: https://github.com/DynareTeam/dynare/commit/accd70a4c79c3e8dffb8ab367e1879680bd20606#commitcomment-19427662
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1226Support mingw-compiler on Windows2019-06-19T15:37:49ZJohannes PfeiferSupport 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/mat...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.5Johannes PfeiferHoutan BastaniJohannes Pfeiferhttps://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/1179Fix cross-compilation of Dynare++ for Windows2019-06-19T15:37:51ZJohannes PfeiferFix cross-compilation of Dynare++ for WindowsWith the unstable version under Windows 10 I get an error that `libquadmath-0.dll` is missing, while Dynare 4.4.3 still works.
With the unstable version under Windows 10 I get an error that `libquadmath-0.dll` is missing, while Dynare 4.4.3 still works.
4.5Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1478Configure Windows Installer to allow silent install2019-10-23T14:40:47ZJohannes PfeiferConfigure Windows Installer to allow silent installThis is a feature request from a university wanting to do an unattended installation of Dynare on a computer pool. The NSIS installer we use seems to not be configured for silent installs, i.e. passing '/D /d=test_directory' does not wo...This is a feature request from a university wanting to do an unattended installation of Dynare on a computer pool. The NSIS installer we use seems to not be configured for silent installs, i.e. passing '/D /d=test_directory' does not work.
We should follow the instructions at http://nsis.sourceforge.net/Docs/Chapter4.html#silent t to allow for this.
Sébastien VillemotSébastien Villemot