dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2020-01-10T17:30:50Zhttps://git.dynare.org/Dynare/dynare/-/issues/1645Provide an example for ramsey_policy and osr2020-01-10T17:30:50ZSébastien VillemotProvide an example for ramsey_policy and osrTo be distributed on the website and in the `examples` subdir.
Suggested by Aurélien Poissonnier.To be distributed on the website and in the `examples` subdir.
Suggested by Aurélien Poissonnier.4.6Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/1644How to include m2html when compiling the MEX for MATLAB2019-05-22T15:36:00ZWilli Mutschlerwilli@mutschler.euHow to include m2html when compiling the MEX for MATLABHi, just a minor (and not really important) question, but still for completeness.
Whenever I compile the preprocessor I always get
`M2HTML documentation: no` .
I did download m2html from https://www.artefact.tk/software/matlab/m2html/, unzipped it and added the path to matlab. I am on Ubuntu. Am I doing anything wrong?Hi, just a minor (and not really important) question, but still for completeness.
Whenever I compile the preprocessor I always get
`M2HTML documentation: no` .
I did download m2html from https://www.artefact.tk/software/matlab/m2html/, unzipped it and added the path to matlab. I am on Ubuntu. Am I doing anything wrong?Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1642Bug in analytical computations of second-order params derivs (d2A and d2Om)2019-03-27T11:52:59ZWilli Mutschlerwilli@mutschler.euBug in analytical computations of second-order params derivs (d2A and d2Om)The function `get_first_order_solution_params_deriv.m` (previously `getH.m`) does not compute the second-order derivatives `d2A` and `d2Om` correctly when using analytical derivatives (kronflag=0|1). If we use numerical derivatives (kronflag=-1|-2) the computations are correct.
To replicate the bug, I looked at the Brock and Mirman model (i.e. RBC model with log utility and full depreciation), where we know analytically the policy functions, i.e. also the Kalman transition matrices of a first-order approximation (A, B and Om) analytically. Hence, using symbolic computations it is possible to compute the true `d2A` and `d2Om` and compare the values to dynare.
Here is a mod file to replicate the bug:
[BrockMirmanBug.mod](/uploads/006601083ca694efc36c5b9b396c3aa9/BrockMirmanBug.mod)
and the corresponding matlab file that computes the true objects of the Brock Mirman Model analytically using Matlab's symbolic toolbox:
[BrockMirmanTruePolicyAndDerivatives.m](/uploads/f1cf3e22d26d7e904b6e49764520ee5e/BrockMirmanTruePolicyAndDerivatives.m)
@rattoma is already aware of this bug.The function `get_first_order_solution_params_deriv.m` (previously `getH.m`) does not compute the second-order derivatives `d2A` and `d2Om` correctly when using analytical derivatives (kronflag=0|1). If we use numerical derivatives (kronflag=-1|-2) the computations are correct.
To replicate the bug, I looked at the Brock and Mirman model (i.e. RBC model with log utility and full depreciation), where we know analytically the policy functions, i.e. also the Kalman transition matrices of a first-order approximation (A, B and Om) analytically. Hence, using symbolic computations it is possible to compute the true `d2A` and `d2Om` and compare the values to dynare.
Here is a mod file to replicate the bug:
[BrockMirmanBug.mod](/uploads/006601083ca694efc36c5b9b396c3aa9/BrockMirmanBug.mod)
and the corresponding matlab file that computes the true objects of the Brock Mirman Model analytically using Matlab's symbolic toolbox:
[BrockMirmanTruePolicyAndDerivatives.m](/uploads/f1cf3e22d26d7e904b6e49764520ee5e/BrockMirmanTruePolicyAndDerivatives.m)
@rattoma is already aware of this bug.Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/-/issues/1641Fix dyn_first_order_solver for models without lagged variables2019-03-08T16:51:44ZJohannes Pfeifer Fix dyn_first_order_solver for models without lagged variablesThe model
```
// Declare variables
var y r k b tax agov wage gama s cf cs;
// Declare parameter values
parameters cbeta cdelta cphi ctheta cn ca cd cb ct da ft;
cbeta=0.98;
cdelta=5;
cphi=0.2058;
cn=1;
ctheta=0.2;
ca=0.3;
cd=0.97;
cb=0.09;
ct=0.05;
ft=0.1;
da=2;
// predetermined_variables k;
model;
y= da*k^ctheta;
r= da*ctheta*k^(ctheta-1);
wage= da*(1-ctheta)*k^ctheta;
gama(+1)=cn*(cd+cphi*agov^ca)*k(+1)^ctheta/k^ctheta;
tax=ct*wage+ft*r*(b+k);
b(+1)*cn*(cd+cphi*agov^ca)=agov+r*b-tax;
s=wage*(1-ct)*cbeta^cdelta*(r*(1-ft))^(cdelta-1)/(1+cbeta^cdelta*(r*(1-ft))^(cdelta-1));
k(+1)+b(+1)=s/(cn*(cd+cphi*agov^ca));
b=cb*y;
cf=wage*(1-ct)/(1+cbeta^(-cdelta)*(r*(1-ft))^(1-cdelta));
cs=wage*(1-ct)*(cbeta*r*(1-ft))^(1-cdelta)/(1+cbeta^(0-cdelta)*(r*(1-ft))^(1-cdelta));
end;
initval;
k =0.1;
y = da*k^ctheta;
r= da*ctheta*k^(ctheta-1);
wage= da*(1-ctheta)*k^ctheta;
b =cb*y;
tax =ct*wage;
agov =0.1;
s=(wage-tax)*cbeta^cdelta*r^(cdelta-1)/(1+cbeta^cdelta*r^(cdelta-1));
end;
steady;
// check;
stoch_simul(order=1);
```
crashes `dyn_first_order_solver` due to non-conformable matrix dimensions in ` E(row_indx_de_1,index_e1) = -aa(row_indx,index_e);`
Setting the predetermined variables correctly solves the issue.The model
```
// Declare variables
var y r k b tax agov wage gama s cf cs;
// Declare parameter values
parameters cbeta cdelta cphi ctheta cn ca cd cb ct da ft;
cbeta=0.98;
cdelta=5;
cphi=0.2058;
cn=1;
ctheta=0.2;
ca=0.3;
cd=0.97;
cb=0.09;
ct=0.05;
ft=0.1;
da=2;
// predetermined_variables k;
model;
y= da*k^ctheta;
r= da*ctheta*k^(ctheta-1);
wage= da*(1-ctheta)*k^ctheta;
gama(+1)=cn*(cd+cphi*agov^ca)*k(+1)^ctheta/k^ctheta;
tax=ct*wage+ft*r*(b+k);
b(+1)*cn*(cd+cphi*agov^ca)=agov+r*b-tax;
s=wage*(1-ct)*cbeta^cdelta*(r*(1-ft))^(cdelta-1)/(1+cbeta^cdelta*(r*(1-ft))^(cdelta-1));
k(+1)+b(+1)=s/(cn*(cd+cphi*agov^ca));
b=cb*y;
cf=wage*(1-ct)/(1+cbeta^(-cdelta)*(r*(1-ft))^(1-cdelta));
cs=wage*(1-ct)*(cbeta*r*(1-ft))^(1-cdelta)/(1+cbeta^(0-cdelta)*(r*(1-ft))^(1-cdelta));
end;
initval;
k =0.1;
y = da*k^ctheta;
r= da*ctheta*k^(ctheta-1);
wage= da*(1-ctheta)*k^ctheta;
b =cb*y;
tax =ct*wage;
agov =0.1;
s=(wage-tax)*cbeta^cdelta*r^(cdelta-1)/(1+cbeta^cdelta*r^(cdelta-1));
end;
steady;
// check;
stoch_simul(order=1);
```
crashes `dyn_first_order_solver` due to non-conformable matrix dimensions in ` E(row_indx_de_1,index_e1) = -aa(row_indx,index_e);`
Setting the predetermined variables correctly solves the issue.4.6https://git.dynare.org/Dynare/dynare/-/issues/1640Build issues under Arch Linux (Dynare 4.5.7, Octave 5.1.0)2019-03-07T15:27:58ZAngelo SaltonBuild issues under Arch Linux (Dynare 4.5.7, Octave 5.1.0)Hello,
I'm forwarding an issue found by a fellow Arch user on [AUR](https://aur.archlinux.org/packages/dynare/):
> To run smoothly under Octave 5.1.0 I had to symlink the libs from the Octave folder:
>
> ```
> ln -s /usr/lib/octave/5.1.0/liboctave.so /usr/lib/liboctave.so
> ln -s /usr/lib/octave/5.1.0/liboctinterp.so /usr/lib/liboctinterp.so
> ln -s /usr/lib/octave/5.1.0/liboctinterp.so /usr/lib/liboctinterp.so.6
> ```
>
> Just setting the LDFLAGS during the build won't do the trick.Hello,
I'm forwarding an issue found by a fellow Arch user on [AUR](https://aur.archlinux.org/packages/dynare/):
> To run smoothly under Octave 5.1.0 I had to symlink the libs from the Octave folder:
>
> ```
> ln -s /usr/lib/octave/5.1.0/liboctave.so /usr/lib/liboctave.so
> ln -s /usr/lib/octave/5.1.0/liboctinterp.so /usr/lib/liboctinterp.so
> ln -s /usr/lib/octave/5.1.0/liboctinterp.so /usr/lib/liboctinterp.so.6
> ```
>
> Just setting the LDFLAGS during the build won't do the trick.Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1639Add the possibility to use Matlab's namespace in model block2019-11-27T13:11:53ZStéphane Adjemianstepan@adjemian.euAdd the possibility to use Matlab's namespace in model block... or in `steady_state_model` block, where it should be possible to write something like:
```
z = example.z_steadystate();
```
provided that the file `+example/z_steadystate` exists.... or in `steady_state_model` block, where it should be possible to write something like:
```
z = example.z_steadystate();
```
provided that the file `+example/z_steadystate` exists.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1638Octave: persistent variables do not get set in prior_draw2019-03-18T14:23:00ZWilli Mutschlerwilli@mutschler.euOctave: persistent variables do not get set in prior_drawI noticed that running `tests/identification/as2007/as2007.mod` of the master branch with Octave (ver. 4.4.1) does not work with the following error:
```
Monte Carlo Testing
error: 'a' undefined near line 40 column 19
error: called from
gamrnd at line 40 column 7
gamrnd at line 122 column 27
prior_draw at line 128 column 24
dynare_identification at line 529 column 20
driver at line 247 column 1
dynare at line 288 column 1
stopped in /home/wmutschl/dynare/wip/matlab/missing/stats/gamrnd.m at line 40
40: b = ones(size(a));
```
I think the reason is that in `dynare_identification` in line 155/157 `prior_draw(bayestopt_, options_.prior_trunc, false)` is called once to initialize the following persistent variables in `prior_draw`:
```
persistent p6 p7 p3 p4 lb ub
persistent uniform_index gaussian_index gamma_index beta_index inverse_gamma_1_index inverse_gamma_2_index weibull_index
persistent uniform_draws gaussian_draws gamma_draws beta_draws inverse_gamma_1_draws inverse_gamma_2_draws weibull_draws
```
Once we have that, `prior_draw()` generates a new draw. At least this is the ways it works in Matlab and the test file runs through.
However, in Octave the persistent variables do not get set for some reason, and hence `gamrnd` is called with undefined inputs, as far as I can see.I noticed that running `tests/identification/as2007/as2007.mod` of the master branch with Octave (ver. 4.4.1) does not work with the following error:
```
Monte Carlo Testing
error: 'a' undefined near line 40 column 19
error: called from
gamrnd at line 40 column 7
gamrnd at line 122 column 27
prior_draw at line 128 column 24
dynare_identification at line 529 column 20
driver at line 247 column 1
dynare at line 288 column 1
stopped in /home/wmutschl/dynare/wip/matlab/missing/stats/gamrnd.m at line 40
40: b = ones(size(a));
```
I think the reason is that in `dynare_identification` in line 155/157 `prior_draw(bayestopt_, options_.prior_trunc, false)` is called once to initialize the following persistent variables in `prior_draw`:
```
persistent p6 p7 p3 p4 lb ub
persistent uniform_index gaussian_index gamma_index beta_index inverse_gamma_1_index inverse_gamma_2_index weibull_index
persistent uniform_draws gaussian_draws gamma_draws beta_draws inverse_gamma_1_draws inverse_gamma_2_draws weibull_draws
```
Once we have that, `prior_draw()` generates a new draw. At least this is the ways it works in Matlab and the test file runs through.
However, in Octave the persistent variables do not get set for some reason, and hence `gamrnd` is called with undefined inputs, as far as I can see.Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1637Investigate parsing of attached mod-file2019-02-05T17:03:42ZJohannes Pfeifer Investigate parsing of attached mod-fileThe file [Q4_disc.mod](/uploads/a84d498060bfb51694ce8e527f06a8de/Q4_disc.mod) seems to not be correctly parsed. The parameter `lambda` is defined, but is not set by the preprocessor.The file [Q4_disc.mod](/uploads/a84d498060bfb51694ce8e527f06a8de/Q4_disc.mod) seems to not be correctly parsed. The parameter `lambda` is defined, but is not set by the preprocessor.Houtan BastaniHoutan Bastanihttps://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.