dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2019-02-05T17:03:42Zhttps://git.dynare.org/Dynare/dynare/-/issues/1636Fix infinite loop in mr_hessian2019-02-05T17:03:42ZJohannes Pfeifer Fix infinite loop in mr_hessian@rattoma `mr_hessian` contains the loop
```
while (fx-f0)==0
hess_info.h1(i)= hess_info.h1(i)*2;
xh1(i)=x(i)+hess_info.h1(i);
[fx,exit_flag,ffx]=penalty_objective_function(xh1,func,penalty,varargin{:});
ic=1;
end
```
That loop does not have a proper termination criterion. I have a mod-file where `hess_info.h1(i)` becomes 0 so that it is always true that `fx=f0`. So either we condition on `ic` also being smaller than a particlar number, or we need to check that `hess_info.h1(i)*2` is not 0.@rattoma `mr_hessian` contains the loop
```
while (fx-f0)==0
hess_info.h1(i)= hess_info.h1(i)*2;
xh1(i)=x(i)+hess_info.h1(i);
[fx,exit_flag,ffx]=penalty_objective_function(xh1,func,penalty,varargin{:});
ic=1;
end
```
That loop does not have a proper termination criterion. I have a mod-file where `hess_info.h1(i)` becomes 0 so that it is always true that `fx=f0`. So either we condition on `ic` also being smaller than a particlar number, or we need to check that `hess_info.h1(i)*2` is not 0.4.6Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/-/issues/1635Bug in shock_decomposition2019-01-22T18:42:02Zjbejarro78Bug in shock_decompositionAfter running an estimation and the shock_decomposition command, I realize that shock_decomposition of an observed variable x is not consistent with the shock_decomposition computed by DYNARE. The problem is that DYNARE generates some Auxiliary ENDO and LAG variables that change variables order for the shock_decomposition and therefore shock_decomposition is not conssitent with that observed variable. Could you fix that? or could I avoide that DYNARE does not generates those auxiliary variables.After running an estimation and the shock_decomposition command, I realize that shock_decomposition of an observed variable x is not consistent with the shock_decomposition computed by DYNARE. The problem is that DYNARE generates some Auxiliary ENDO and LAG variables that change variables order for the shock_decomposition and therefore shock_decomposition is not conssitent with that observed variable. Could you fix that? or could I avoide that DYNARE does not generates those auxiliary variables.https://git.dynare.org/Dynare/dynare/-/issues/1634Bug in positive/negative IRFs in Dynare++2019-02-05T20:00:07ZJohannes Pfeifer Bug in positive/negative IRFs in Dynare++See
https://forum.dynare.org/t/asymmetric-irfs-at-first-order-in-dynare/12246/4
The issue seems to have not yet been solved.See
https://forum.dynare.org/t/asymmetric-irfs-at-first-order-in-dynare/12246/4
The issue seems to have not yet been solved.4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1633Filter out cases where stochastic simulation is run with no shocks2019-09-10T08:47:48ZJohannes Pfeifer Filter out cases where stochastic simulation is run with no shocksWhen using `stoch_simul` without varexo, a cryptic error message will appear. See https://forum.dynare.org/t/how-to-compute-the-decision-rule-matrix-oo-dr-ghx-of-a-deterministic-model/13095
We should provide an informative message, potentially at the level of the preprocessor.When using `stoch_simul` without varexo, a cryptic error message will appear. See https://forum.dynare.org/t/how-to-compute-the-decision-rule-matrix-oo-dr-ghx-of-a-deterministic-model/13095
We should provide an informative message, potentially at the level of the preprocessor.4.6https://git.dynare.org/Dynare/dynare/-/issues/1632Inconsistency in treatment of qz_criterium in dyn_first_order_solver.m / mjdg...2019-01-15T18:06:09ZTom HoldenInconsistency in treatment of qz_criterium in dyn_first_order_solver.m / mjdgges.cI was under the impression that `qz_criterium` was intended to be a threshold on the absolute value of `dr.eigval`. See e.g. line 85 of `AIM_first_order_solver.m`:
`nba = nd-sum( abs(dr.eigval) < qz_criterium );`
However, it appears that in `dyn_first_order_solver.m` it is instead a threshold on the squared absolute value of `dr.eigval`. See line 190 of `dyn_first_order_solver.m`:
`[err, ss, tt, w, sdim, dr.eigval, info1] = mjdgges(E, D, DynareOptions.qz_criterium, DynareOptions.qz_zero_threshold);`
line 31 of `mjdgges.c`:
`return ((*alphar **alphar + *alphai **alphai) < criterium **beta **beta);`
and line 107 of `mjdgges.c`:
`criterium = *mxGetPr(prhs[2]);`
The eigenvalues are `( alphar[j] + alphai[j] * 1i ) / beta[j]` according to [the MKL manual](https://software.intel.com/en-us/mkl-developer-reference-fortran-gges). Thus, it seems that this code is comparing the **squared** absolute value of the eigenvalue to `qz_criterium`.
The easiest fix would be to replace line 190 of `dyn_first_order_solver.m` with:
`[err, ss, tt, w, sdim, dr.eigval, info1] = mjdgges(E, D, DynareOptions.qz_criterium .^ 2, DynareOptions.qz_zero_threshold);`
so you're comparing squared to squared.I was under the impression that `qz_criterium` was intended to be a threshold on the absolute value of `dr.eigval`. See e.g. line 85 of `AIM_first_order_solver.m`:
`nba = nd-sum( abs(dr.eigval) < qz_criterium );`
However, it appears that in `dyn_first_order_solver.m` it is instead a threshold on the squared absolute value of `dr.eigval`. See line 190 of `dyn_first_order_solver.m`:
`[err, ss, tt, w, sdim, dr.eigval, info1] = mjdgges(E, D, DynareOptions.qz_criterium, DynareOptions.qz_zero_threshold);`
line 31 of `mjdgges.c`:
`return ((*alphar **alphar + *alphai **alphai) < criterium **beta **beta);`
and line 107 of `mjdgges.c`:
`criterium = *mxGetPr(prhs[2]);`
The eigenvalues are `( alphar[j] + alphai[j] * 1i ) / beta[j]` according to [the MKL manual](https://software.intel.com/en-us/mkl-developer-reference-fortran-gges). Thus, it seems that this code is comparing the **squared** absolute value of the eigenvalue to `qz_criterium`.
The easiest fix would be to replace line 190 of `dyn_first_order_solver.m` with:
`[err, ss, tt, w, sdim, dr.eigval, info1] = mjdgges(E, D, DynareOptions.qz_criterium .^ 2, DynareOptions.qz_zero_threshold);`
so you're comparing squared to squared.Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1631Fix calls to dynamic routines in identification2019-01-09T14:19:54ZJohannes Pfeifer Fix calls to dynamic routines in identificationThe attached file contains a moving average process. It crashes identification in calls like
```
[residual, g1 ] = feval([M_.fname,'_dynamic'],yy0, ...
repmat(oo_.exo_steady_state',[M_.maximum_exo_lag+M_.maximum_exo_lead+1]), M_.params, ...
oo_.dr.ys, 1);
```
Here, the period number (last argument) is always set to 1 instead of presumably `M_.maximum_exo_lag+1 `.
[dsge_mada_debt1.mod](/uploads/cad3e4c1ca2f06c5f85913d13b27a715/dsge_mada_debt1.mod)The attached file contains a moving average process. It crashes identification in calls like
```
[residual, g1 ] = feval([M_.fname,'_dynamic'],yy0, ...
repmat(oo_.exo_steady_state',[M_.maximum_exo_lag+M_.maximum_exo_lead+1]), M_.params, ...
oo_.dr.ys, 1);
```
Here, the period number (last argument) is always set to 1 instead of presumably `M_.maximum_exo_lag+1 `.
[dsge_mada_debt1.mod](/uploads/cad3e4c1ca2f06c5f85913d13b27a715/dsge_mada_debt1.mod)4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1630Options at the top of a mod file should be parsed by the preprocessor2018-12-19T15:16:36ZSébastien VillemotOptions at the top of a mod file should be parsed by the preprocessorThe options at the top of a mod file are currently read from `dynare.m`, then passed when invoking the preprocessor.
But we want this feature to work outside of MATLAB. So this parsing should be done by the preprocessor itself, who should accept these options as if they had been passed on the command-line.The options at the top of a mod file are currently read from `dynare.m`, then passed when invoking the preprocessor.
But we want this feature to work outside of MATLAB. So this parsing should be done by the preprocessor itself, who should accept these options as if they had been passed on the command-line.Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1629Problems with 4.5.4-1 on Ubuntu 18.042018-11-16T16:48:01Zv-marinkovProblems with 4.5.4-1 on Ubuntu 18.04Ubuntu 18.04 LTS has Dynare 4.5.4-1 in the repositories (funny enough Debian has newer packages but I can't install them because they require the newer dependencies as well). This version, however, is not playing nicely with Matlab 2018b and fails to configure everything. Dynare works through Matlab but every time I run `apt upgrade` or `apt install somepackagename` it tries to finish configuring and exits with the following error:
```
Setting up dynare-matlab (4.5.4-1) ...
Building Matlab extensions (logfile at /tmp/dynare-matlab-mexbuild-1542385181.sBPwNf2)
configure: WARNING: you should use --build, --host, --target
configure: WARNING: invalid host type: '9.5
Invalid configuration `'9.5': machine `'9.5' not recognized
configure: error: /bin/bash ./config.sub '9.5 failed
dpkg: error processing package dynare-matlab (--configure):
installed dynare-matlab package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
dynare-matlab
E: Sub-process /usr/bin/dpkg returned an error code (1)
```
I tried to tinker with the `configure` file in `/usr/src/matlab/dynare-matlab/mex/build/matlab` but to no avail.
If I run
```
cd /usr/src/matlab/dynare-matlab
cd mex/build/matlab && ./configure --with-matlab=$(dirname $(dirname $(readlink -f `which matlab`))) MATLAB_VERSION=9.5 && make
```
It performs many operations but fails with:
```
Making all in mjdgges
make[1]: Entering directory '/usr/src/matlab/dynare-matlab/mex/build/matlab/mjdgges'
gcc -fexceptions -fPIC -pthread -g -O2 -fno-omit-frame-pointer -Wall -Wno-parentheses -shared -Wl,--no-undefined -Wl,-rpath-link,/usr/local/MATLAB/R2018b/bin/glnxa64 -L/usr/local/MATLAB/R2018b/bin/glnxa64 -Wl,--version-script,/usr/local/MATLAB/R2018b/extern/lib/glnxa64/mexFunction.map -o mjdgges.mexa64 mjdgges.o -lmx -lmex -lmat -lm -lstdc++ -lmwlapack -lmwblas
mjdgges.o: In function `mexFunction':
/usr/src/matlab/dynare-matlab/mex/build/matlab/mjdgges/../../../sources/mjdgges/mjdgges.c:123: undefined reference to `mxGetPiIsDeprecated'
collect2: error: ld returned 1 exit status
Makefile:393: recipe for target 'mjdgges.mexa64' failed
make[1]: *** [mjdgges.mexa64] Error 1
make[1]: Leaving directory '/usr/src/matlab/dynare-matlab/mex/build/matlab/mjdgges'
Makefile:405: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1
```Ubuntu 18.04 LTS has Dynare 4.5.4-1 in the repositories (funny enough Debian has newer packages but I can't install them because they require the newer dependencies as well). This version, however, is not playing nicely with Matlab 2018b and fails to configure everything. Dynare works through Matlab but every time I run `apt upgrade` or `apt install somepackagename` it tries to finish configuring and exits with the following error:
```
Setting up dynare-matlab (4.5.4-1) ...
Building Matlab extensions (logfile at /tmp/dynare-matlab-mexbuild-1542385181.sBPwNf2)
configure: WARNING: you should use --build, --host, --target
configure: WARNING: invalid host type: '9.5
Invalid configuration `'9.5': machine `'9.5' not recognized
configure: error: /bin/bash ./config.sub '9.5 failed
dpkg: error processing package dynare-matlab (--configure):
installed dynare-matlab package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
dynare-matlab
E: Sub-process /usr/bin/dpkg returned an error code (1)
```
I tried to tinker with the `configure` file in `/usr/src/matlab/dynare-matlab/mex/build/matlab` but to no avail.
If I run
```
cd /usr/src/matlab/dynare-matlab
cd mex/build/matlab && ./configure --with-matlab=$(dirname $(dirname $(readlink -f `which matlab`))) MATLAB_VERSION=9.5 && make
```
It performs many operations but fails with:
```
Making all in mjdgges
make[1]: Entering directory '/usr/src/matlab/dynare-matlab/mex/build/matlab/mjdgges'
gcc -fexceptions -fPIC -pthread -g -O2 -fno-omit-frame-pointer -Wall -Wno-parentheses -shared -Wl,--no-undefined -Wl,-rpath-link,/usr/local/MATLAB/R2018b/bin/glnxa64 -L/usr/local/MATLAB/R2018b/bin/glnxa64 -Wl,--version-script,/usr/local/MATLAB/R2018b/extern/lib/glnxa64/mexFunction.map -o mjdgges.mexa64 mjdgges.o -lmx -lmex -lmat -lm -lstdc++ -lmwlapack -lmwblas
mjdgges.o: In function `mexFunction':
/usr/src/matlab/dynare-matlab/mex/build/matlab/mjdgges/../../../sources/mjdgges/mjdgges.c:123: undefined reference to `mxGetPiIsDeprecated'
collect2: error: ld returned 1 exit status
Makefile:393: recipe for target 'mjdgges.mexa64' failed
make[1]: *** [mjdgges.mexa64] Error 1
make[1]: Leaving directory '/usr/src/matlab/dynare-matlab/mex/build/matlab/mjdgges'
Makefile:405: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1
```https://git.dynare.org/Dynare/dynare/-/issues/1628Document new preprocessor options2019-10-09T10:33:13ZJohannes Pfeifer Document new preprocessor optionsAs far as I can see, the options `[output=dynamic|first|second|third]` and `[language=julia]` have not yet been documentedAs far as I can see, the options `[output=dynamic|first|second|third]` and `[language=julia]` have not yet been documented4.6https://git.dynare.org/Dynare/dynare/-/issues/1627Bug in evaluate_steady_state.m for models with [dynamic] tags which update pa...2018-11-15T09:25:10ZTom HoldenBug in evaluate_steady_state.m for models with [dynamic] tags which update parametersA steady-state file (e.g. one created via a steady_state_model block) may update parameters. These get stored in the params output of evaluate_steady_state.m, not in M.params. However, within the `if M.static_and_dynamic_models_differ` block at the bottom of the file, M.params is used rather than params. This seems like a mistake.A steady-state file (e.g. one created via a steady_state_model block) may update parameters. These get stored in the params output of evaluate_steady_state.m, not in M.params. However, within the `if M.static_and_dynamic_models_differ` block at the bottom of the file, M.params is used rather than params. This seems like a mistake.https://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/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/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/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/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/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/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/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/1611Make dynare_sensitivity compatible with recursive estimation or provide infor...2021-08-15T19:07:37ZJohannes Pfeifer Make dynare_sensitivity compatible with recursive estimation or provide informative errorSee https://forum.dynare.org/t/calculating-rmses/11903See https://forum.dynare.org/t/calculating-rmses/119034.8