dynare issueshttps://git.dynare.org/Dynare/dynare/issues2019-07-04T13:09:42Zhttps://git.dynare.org/Dynare/dynare/issues/300Implement k-order derivatives of external functions2019-07-04T13:09:42ZSébastien VillemotImplement k-order derivatives of external functionsOtherwise order ≥ 3 fails with a cryptic preprocessor error
Otherwise order ≥ 3 fails with a cryptic preprocessor error
4.6https://git.dynare.org/Dynare/dynare/issues/295offer a quiet and a verbose mode2019-06-19T15:37:41ZSébastien Villemotoffer a quiet and a verbose modeSome users who run Dynare in a loop would like to suppress all messages. On the contrary, some want more messages, for example when debugging.
We currently have a way to disable warnings (see #301). Error messages should probably never be disabled.
For normal messages, we currently have the `noprint` option, but it is limited to some commands only.
I think we should provide three (global) levels of verbosity:
- a quiet mode, with nothing printed (except warnings and error messages)
- a normal mode
- a verbose mode (with some debug messages or more details)
The quiet and verbose modes should probably map to equivalent options of the `dynare` command.
The quiet option could set `options_.noprint=1` internally. The verbose option could set `options_.verbose=1`. Of course one can't have both quiet and verbose set at the same time.
We may want to deprecate the `noprint` options given at the command level. The problem is that if `verbose` is set at the global level, then a `noprint` at a local level would create many problems (in particular because all options have a global effect).
Then we have to modify the preprocessor, all M-files and MEX files to obey these two settings.
Some users who run Dynare in a loop would like to suppress all messages. On the contrary, some want more messages, for example when debugging.
We currently have a way to disable warnings (see #301). Error messages should probably never be disabled.
For normal messages, we currently have the `noprint` option, but it is limited to some commands only.
I think we should provide three (global) levels of verbosity:
- a quiet mode, with nothing printed (except warnings and error messages)
- a normal mode
- a verbose mode (with some debug messages or more details)
The quiet and verbose modes should probably map to equivalent options of the `dynare` command.
The quiet option could set `options_.noprint=1` internally. The verbose option could set `options_.verbose=1`. Of course one can't have both quiet and verbose set at the same time.
We may want to deprecate the `noprint` options given at the command level. The problem is that if `verbose` is set at the global level, then a `noprint` at a local level would create many problems (in particular because all options have a global effect).
Then we have to modify the preprocessor, all M-files and MEX files to obey these two settings.
https://git.dynare.org/Dynare/dynare/issues/294rework option handling2019-11-21T08:36:45ZSébastien Villemotrework option handlingIt's desirable at times to know whether or not a user has set an option in the .mod file.
To do this, we can hack the preprocessor to maintain a separate cellarray, that it would assign to every time it encounters an option. Something to the effect of:
'option' , assigned , default_val
<<string>>, <<0 or 1>>, <<general>>
This can be done in the preprocessor without changing the backend matlab code. It would thereby provide the possibility, when needed, to check whether or not an option was assigned by the user, allowing us to know whether or not we can change the value.
It's desirable at times to know whether or not a user has set an option in the .mod file.
To do this, we can hack the preprocessor to maintain a separate cellarray, that it would assign to every time it encounters an option. Something to the effect of:
'option' , assigned , default_val
<<string>>, <<0 or 1>>, <<general>>
This can be done in the preprocessor without changing the backend matlab code. It would thereby provide the possibility, when needed, to check whether or not an option was assigned by the user, allowing us to know whether or not we can change the value.
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/285Allow user-specified path for exogenous in extended_path2019-06-19T15:37:42ZSébastien VillemotAllow user-specified path for exogenous in extended_pathThat could be implemented with the shocks blocks.
That could be implemented with the shocks blocks.
https://git.dynare.org/Dynare/dynare/issues/263latex variable with exponent causes compilation error2019-12-03T12:41:58ZSébastien Villemotlatex variable with exponent causes compilation errorSee: http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=3846
Quick fix is to require users to place brackets around latex
variables containing exponents (and probably underscores)
Complete fix is to place braces around variables with lead/lags and those variables with no lead/lag but that are followed by an exponent. In the user's case, we would output: B^problem_t-1^\rho
See: http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=3846
Quick fix is to require users to place brackets around latex
variables containing exponents (and probably underscores)
Complete fix is to place braces around variables with lead/lags and those variables with no lead/lag but that are followed by an exponent. In the user's case, we would output: B^problem_t-1^\rho
4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/251SMM: create preprocessor interface, make it compatible with Octave2019-06-19T15:37:42ZSébastien VillemotSMM: create preprocessor interface, make it compatible with OctaveIn particular, the current code is not compatible with Octave since it uses RandStream at several places.
In particular, the current code is not compatible with Octave since it uses RandStream at several places.
https://git.dynare.org/Dynare/dynare/issues/248Add tests for the parallelization engine2019-06-19T15:37:42ZSébastien VillemotAdd tests for the parallelization engineMarco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/243Publicly distribute the Dynare slides2019-09-09T12:34:39ZSébastien VillemotPublicly distribute the Dynare slidesWe already distribute the slides on the summerschool temporary website, but this is not very visible. We should probably have a more permanent location, and maybe also add them in the Dynare package.
Also, we may consider putting the LaTeX source in git.
We already distribute the slides on the summerschool temporary website, but this is not very visible. We should probably have a more permanent location, and maybe also add them in the Dynare package.
Also, we may consider putting the LaTeX source in git.
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/240rewrite getPowerDeriv assignments in temporary terms2019-06-19T15:37:42ZSébastien Villemotrewrite getPowerDeriv assignments in temporary termsFrom Stephane:
In models with power functions of the form x**a (utility functions, production functions, agregation functions, quadratic costs, ...) the evaluation of the jacobian matrix (or higher order derivates) necessitate potentially a huge number of calls to the routine getPowerDeriv (the name of the routine is explicit enough). In my example (a real business cycle model with perfect foresight) most of the time is spent in this routine, while, if my understanding is correct, this is not necessary because x>0.
I wrote a mex file (see the new branch called mex-!GetPowerDeriv) as a replacement for the matlab routine, unfortunatly the overhead cost is so high that the use of the mex file increases the total time of execution!
In my case I resolved the issue by using option use_dll, but this is not a solution for the majority of our users (they would have to install cygwin/gcc and configure matlab/mex). So my question is: Do we really need to call this routine in all situations ? Would it not be possible to replace calls to this routine by something like:
if (abs(x)>1e-12)
tmp = ANALYTICAL_EXPRESSION_OF_THE_DERIVATIVEx,params;
else
tmp = 0;
end
From Stephane:
In models with power functions of the form x**a (utility functions, production functions, agregation functions, quadratic costs, ...) the evaluation of the jacobian matrix (or higher order derivates) necessitate potentially a huge number of calls to the routine getPowerDeriv (the name of the routine is explicit enough). In my example (a real business cycle model with perfect foresight) most of the time is spent in this routine, while, if my understanding is correct, this is not necessary because x>0.
I wrote a mex file (see the new branch called mex-!GetPowerDeriv) as a replacement for the matlab routine, unfortunatly the overhead cost is so high that the use of the mex file increases the total time of execution!
In my case I resolved the issue by using option use_dll, but this is not a solution for the majority of our users (they would have to install cygwin/gcc and configure matlab/mex). So my question is: Do we really need to call this routine in all situations ? Would it not be possible to replace calls to this routine by something like:
if (abs(x)>1e-12)
tmp = ANALYTICAL_EXPRESSION_OF_THE_DERIVATIVEx,params;
else
tmp = 0;
end
https://git.dynare.org/Dynare/dynare/issues/237Document sbvar command2019-11-21T08:36:41ZSébastien VillemotDocument sbvar commandMichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/234add @#elseif to macroprocessor2019-08-19T15:05:51ZSébastien Villemotadd @#elseif to macroprocessorsaves users from:
if
else
if
else
endif
endif
saves users from:
if
else
if
else
endif
endif
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/226New estimation2019-06-19T15:37:42ZSébastien VillemotNew estimationWrite the new estimation interface in the preprocessor. A description of what is needed is given on the wiki (http://www.dynare.org/DynareWiki/NewEstimation).
Write the new estimation interface in the preprocessor. A description of what is needed is given on the wiki (http://www.dynare.org/DynareWiki/NewEstimation).
Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/172improve derivation engine for derivatives of STEADY_STATE wrt parameters2019-06-19T15:37:42ZSébastien Villemotimprove derivation engine for derivatives of STEADY_STATE wrt parametersCurrently the derivatives of STEADY_STATE operator wrt to parameters are not handled in an efficient way, because the preprocessor does not exploit the a priori information for identifying null derivatives. This results in huge files for not so complicated models, which cannot be exploited by identification routines.
The proposal is to implement an algorithm in the preprocessor for identifying null derivatives ex ante:
- Create a non-directed graph whose nodes are the endogenous variables and the parameters
- For each pair of nodes, add an edge between the two if there is an equation in the static model containing both corresponding symbols (endogenous/parameters)
- For each endogenous, its derivative wrt a parameter is always zero if there is no path between the node representing the endogenous and the node representing the parameter.
Currently the derivatives of STEADY_STATE operator wrt to parameters are not handled in an efficient way, because the preprocessor does not exploit the a priori information for identifying null derivatives. This results in huge files for not so complicated models, which cannot be exploited by identification routines.
The proposal is to implement an algorithm in the preprocessor for identifying null derivatives ex ante:
- Create a non-directed graph whose nodes are the endogenous variables and the parameters
- For each pair of nodes, add an edge between the two if there is an equation in the static model containing both corresponding symbols (endogenous/parameters)
- For each endogenous, its derivative wrt a parameter is always zero if there is no path between the node representing the endogenous and the node representing the parameter.
https://git.dynare.org/Dynare/dynare/issues/1527Add Occbin2019-06-19T15:37:42ZJohannes Pfeifer Add Occbinhttps://git.dynare.org/Dynare/dynare/issues/1523rename isfile.m as there is a function called isfile in Matlab R2017b2019-06-19T15:37:42ZHoutan Bastanirename isfile.m as there is a function called isfile in Matlab R2017bStéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1518Clean up setting estim_params_ as global2019-06-19T15:37:42ZJohannes Pfeifer Clean up setting estim_params_ as globalIn line 675 of `ModFile.cc` we set
```global M_ options_ oo_ estim_params_ bayestopt_ dataset_ dataset_info estimation_info ys0_ ex0_```
But in line 1031 of `ComputingTasks.cc` we again set `estim_params` global if an `estimated_params`-block is present:
```output << "global estim_params_" << endl```
I would get rid of the latter statement and only keep the one setting all globals global.In line 675 of `ModFile.cc` we set
```global M_ options_ oo_ estim_params_ bayestopt_ dataset_ dataset_info estimation_info ys0_ ex0_```
But in line 1031 of `ComputingTasks.cc` we again set `estim_params` global if an `estimated_params`-block is present:
```output << "global estim_params_" << endl```
I would get rid of the latter statement and only keep the one setting all globals global.4.5.2Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1510Block histval from accepting positive lags2019-06-19T15:37:42ZJohannes Pfeifer Block histval from accepting positive lags`histval` serves for setting past values, not future ones. The Matlab-files are not able to handle this case. The code
```
% Test whether preprocessor recognizes state variables introduced by optimal policy Github #1193
var pai, c, n, r, a;
varexo u;
parameters beta, rho, epsilon, omega, phi, gamma;
beta=0.99;
gamma=3;
omega=17;
epsilon=8;
phi=1;
rho=0.95;
model;
a = rho*a(-1)+u;
1/c = beta*r/(c(+1)*pai(+1));
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);
exp(a)*n = c+(omega/2)*(pai-1)^2;
end;
initval;
r=1;
end;
histval;
a(5)=1;
end;
steady_state_model;
a = 0;
pai = beta*r;
c = find_c(0.96,pai,beta,epsilon,phi,gamma,omega);
n = c+(omega/2)*(pai-1)^2;
end;
shocks;
var u; stderr 0.008;
var u;
periods 1;
values 1;
end;
options_.dr_display_tol=0;
planner_objective(ln(c)-phi*((n^(1+gamma))/(1+gamma)));
ramsey_policy(planner_discount=0.99,order=1,instruments=(r),periods=500);
```
causes a crash in `simult_` because of the `a(5)` in the `histval`-block`histval` serves for setting past values, not future ones. The Matlab-files are not able to handle this case. The code
```
% Test whether preprocessor recognizes state variables introduced by optimal policy Github #1193
var pai, c, n, r, a;
varexo u;
parameters beta, rho, epsilon, omega, phi, gamma;
beta=0.99;
gamma=3;
omega=17;
epsilon=8;
phi=1;
rho=0.95;
model;
a = rho*a(-1)+u;
1/c = beta*r/(c(+1)*pai(+1));
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);
exp(a)*n = c+(omega/2)*(pai-1)^2;
end;
initval;
r=1;
end;
histval;
a(5)=1;
end;
steady_state_model;
a = 0;
pai = beta*r;
c = find_c(0.96,pai,beta,epsilon,phi,gamma,omega);
n = c+(omega/2)*(pai-1)^2;
end;
shocks;
var u; stderr 0.008;
var u;
periods 1;
values 1;
end;
options_.dr_display_tol=0;
planner_objective(ln(c)-phi*((n^(1+gamma))/(1+gamma)));
ramsey_policy(planner_discount=0.99,order=1,instruments=(r),periods=500);
```
causes a crash in `simult_` because of the `a(5)` in the `histval`-block4.5.2Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1509allow preprocessor to accept text input instead of mod file2019-06-19T15:37:42ZHoutan Bastaniallow preprocessor to accept text input instead of mod filefor GUI interface, create a preprocessor argument that would be the `.mod` file in string format. This way the GUI would not have to make a `.mod` file every time the user changed somethingfor GUI interface, create a preprocessor argument that would be the `.mod` file in string format. This way the GUI would not have to make a `.mod` file every time the user changed something4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1507Make log and ln operators in LaTeX code2019-06-19T15:37:42ZJohannes Pfeifer Make log and ln operators in LaTeX codeWhen requesting LaTeX output, we should output `log` and `ln` as `\log` and `\ln` to make them operators that are correctly set typographically.When requesting LaTeX output, we should output `log` and `ln` as `\log` and `\ln` to make them operators that are correctly set typographically.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1506Fix get_posterior_parameters.m2019-06-19T15:37:42ZJohannes Pfeifer Fix get_posterior_parameters.mFor some reason I do not understand, the function `get_posterior_parameters.m` not only reads out the parameters to the function output `xparam`, but also sets them in the global workspace. I do not really understand why. We call it for example in `evaluate_smoother.m` in the context of
```
if ischar(parameters)
switch parameters
case 'posterior_mode'
parameters = get_posterior_parameters('mode');
case 'posterior_mean'
parameters = get_posterior_parameters('mean');
case 'prior_mode'
parameters = bayestopt_.p5(:);
```
Note that in the `prior mode` case, nothing in the base workspace is altered. As far as I can see, all calls to this function are followed by an explicit setting of the parameter via e.g. `set_all_parameters`.
The problem is that the setting of `M_.Sigma_e` and `M_.H` in the function is wrong as correlations are treated as covariances and measurement errors are ignored. There are two ways out:
1. Get rid of setting variables from the base workspace in the function, making the function read-only (as the name suggests)
2. Fix the parts of the function setting the covariance matrices.
I would suggest to go for 1 as I cannot see a purpose of the parameter setting.For some reason I do not understand, the function `get_posterior_parameters.m` not only reads out the parameters to the function output `xparam`, but also sets them in the global workspace. I do not really understand why. We call it for example in `evaluate_smoother.m` in the context of
```
if ischar(parameters)
switch parameters
case 'posterior_mode'
parameters = get_posterior_parameters('mode');
case 'posterior_mean'
parameters = get_posterior_parameters('mean');
case 'prior_mode'
parameters = bayestopt_.p5(:);
```
Note that in the `prior mode` case, nothing in the base workspace is altered. As far as I can see, all calls to this function are followed by an explicit setting of the parameter via e.g. `set_all_parameters`.
The problem is that the setting of `M_.Sigma_e` and `M_.H` in the function is wrong as correlations are treated as covariances and measurement errors are ignored. There are two ways out:
1. Get rid of setting variables from the base workspace in the function, making the function read-only (as the name suggests)
2. Fix the parts of the function setting the covariance matrices.
I would suggest to go for 1 as I cannot see a purpose of the parameter setting.4.5.2https://git.dynare.org/Dynare/dynare/issues/1502Add a dynare option for specifying if we consider a stochastic or determinist...2019-06-19T15:37:42ZStéphane Adjemianstepan@dynare.orgAdd a dynare option for specifying if we consider a stochastic or deterministic modelSee discussion in #1501.See discussion in #1501.4.6Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1501Backward models with lagged exogenous variables2019-06-19T15:37:42ZStéphane Adjemianstepan@dynare.orgBackward models with lagged exogenous variablesThe Jacobian matrix of backward models with lagged exogenous variables is wrong, columns for the lagged exogenous variables are missing. It is unclear to me why we do not simply add auxiliary endogenous variables for the lagged exogenous variables (as in the case of backward/forward models). I suppose that the simplest fix is to add auxiliary variables (rather than augmenting the size of the Jacobian matrix).
An example is available [here](https://mnemosyne.adjemian.eu/snippets/1)The Jacobian matrix of backward models with lagged exogenous variables is wrong, columns for the lagged exogenous variables are missing. It is unclear to me why we do not simply add auxiliary endogenous variables for the lagged exogenous variables (as in the case of backward/forward models). I suppose that the simplest fix is to add auxiliary variables (rather than augmenting the size of the Jacobian matrix).
An example is available [here](https://mnemosyne.adjemian.eu/snippets/1)Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1455Error when installing Dynare in Ubuntu 16.042019-06-19T15:37:42ZStéphane Adjemianstepan@dynare.orgError when installing Dynare in Ubuntu 16.04*Created by: raspatan*
I couldn't install Dynare 4.4.3 on Ubuntu 16.04. I am using Matlab 2017a. [Here](https://paste.ubuntu.com/24632092/) is the full log file with the error. This is the last bit of the code:
```
install: cannot stat '/usr/src/matlab/dynare-matlab/mex/matlab/*': No such file or directory
dpkg: error processing package dynare-matlab (--configure):
subprocess installed post-installation script returned error exit status 1
Setting up libapache-poi-java (3.10.1-2) ...
Setting up octave-control (3.0.0-1) ...
Setting up octave-io (2.4.0-1) ...
Setting up octave-struct (1.0.11-1) ...
Setting up octave-optim (1.4.1-2) ...
Setting up octave-statistics (1.2.4-1) ...
Setting up liboctave-dev (4.0.0-3ubuntu9.1) ...
Setting up matlab2tikz (0.4.7-1) ...
Processing triggers for libc-bin (2.23-0ubuntu7) ...
Processing triggers for ca-certificates (20160104ubuntu1) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
done.
Errors were encountered while processing:
dynare-matlab
E: Sub-process /usr/bin/dpkg returned an error code (1)
```
There is a bug open in launchpad [here](https://bugs.launchpad.net/ubuntu/+source/dynare/+bug/1580761).*Created by: raspatan*
I couldn't install Dynare 4.4.3 on Ubuntu 16.04. I am using Matlab 2017a. [Here](https://paste.ubuntu.com/24632092/) is the full log file with the error. This is the last bit of the code:
```
install: cannot stat '/usr/src/matlab/dynare-matlab/mex/matlab/*': No such file or directory
dpkg: error processing package dynare-matlab (--configure):
subprocess installed post-installation script returned error exit status 1
Setting up libapache-poi-java (3.10.1-2) ...
Setting up octave-control (3.0.0-1) ...
Setting up octave-io (2.4.0-1) ...
Setting up octave-struct (1.0.11-1) ...
Setting up octave-optim (1.4.1-2) ...
Setting up octave-statistics (1.2.4-1) ...
Setting up liboctave-dev (4.0.0-3ubuntu9.1) ...
Setting up matlab2tikz (0.4.7-1) ...
Processing triggers for libc-bin (2.23-0ubuntu7) ...
Processing triggers for ca-certificates (20160104ubuntu1) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
done.
Errors were encountered while processing:
dynare-matlab
E: Sub-process /usr/bin/dpkg returned an error code (1)
```
There is a bug open in launchpad [here](https://bugs.launchpad.net/ubuntu/+source/dynare/+bug/1580761).https://git.dynare.org/Dynare/dynare/issues/1482No rule to make target `../../../../dynare++/kord/faa_di_bruno.cpp', needed b...2019-08-14T12:33:09ZStéphane Adjemianstepan@dynare.orgNo rule to make target `../../../../dynare++/kord/faa_di_bruno.cpp', needed by `libdynare___a-faa_di_bruno.o'. Stop.*Created by: barrymoo*
## Details
OS: RHEL 7 (Kernel 3.10.0-514.6.1)
GCC Version: Red Hat 4.8.5-11
Attachments: `config.log` and `make.log`
## Configuration Script
``` bash
#!/usr/bin/env bash
module purge
module load boost/1.62.0 mkl/2017.1.132
autoreconf -si
MATLAB_VERSION=R2017a \
./configure \
--with-matlab=/ihome/crc/install/matlab/R2017a \
--disable-octave \
--enable-openmp \
--prefix=/ihome/crc/install/dynare/4.5.0
make &> make.log
```
## Error
``` bash
$ tail make.log
ln -s -f /ihome/crc/build/dyndare/dynare-4.5.0/mex/build/matlab/bytecode/$p $p; \
done
make[2]: Leaving directory `/ihome/crc/build/dyndare/dynare-4.5.0/mex/build/matlab/bytecode'
Making all in libdynare++
make[2]: Entering directory `/ihome/crc/build/dyndare/dynare-4.5.0/mex/build/matlab/libdynare++'
make[2]: *** No rule to make target `../../../../dynare++/kord/faa_di_bruno.cpp', needed by `libdynare___a-faa_di_bruno.o'. Stop.
make[2]: Leaving directory `/ihome/crc/build/dyndare/dynare-4.5.0/mex/build/matlab/libdynare++'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/ihome/crc/build/dyndare/dynare-4.5.0/mex/build/matlab'
make: *** [all-recursive] Error 1
```
## Notes
I tried both the 4.5.0 release and the 4.6-unstable git repo. Any help is appreciated.*Created by: barrymoo*
## Details
OS: RHEL 7 (Kernel 3.10.0-514.6.1)
GCC Version: Red Hat 4.8.5-11
Attachments: `config.log` and `make.log`
## Configuration Script
``` bash
#!/usr/bin/env bash
module purge
module load boost/1.62.0 mkl/2017.1.132
autoreconf -si
MATLAB_VERSION=R2017a \
./configure \
--with-matlab=/ihome/crc/install/matlab/R2017a \
--disable-octave \
--enable-openmp \
--prefix=/ihome/crc/install/dynare/4.5.0
make &> make.log
```
## Error
``` bash
$ tail make.log
ln -s -f /ihome/crc/build/dyndare/dynare-4.5.0/mex/build/matlab/bytecode/$p $p; \
done
make[2]: Leaving directory `/ihome/crc/build/dyndare/dynare-4.5.0/mex/build/matlab/bytecode'
Making all in libdynare++
make[2]: Entering directory `/ihome/crc/build/dyndare/dynare-4.5.0/mex/build/matlab/libdynare++'
make[2]: *** No rule to make target `../../../../dynare++/kord/faa_di_bruno.cpp', needed by `libdynare___a-faa_di_bruno.o'. Stop.
make[2]: Leaving directory `/ihome/crc/build/dyndare/dynare-4.5.0/mex/build/matlab/libdynare++'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/ihome/crc/build/dyndare/dynare-4.5.0/mex/build/matlab'
make: *** [all-recursive] Error 1
```
## Notes
I tried both the 4.5.0 release and the 4.6-unstable git repo. Any help is appreciated.https://git.dynare.org/Dynare/dynare/issues/1469Compile fail w/ fix2019-06-19T15:37:42ZStéphane Adjemianstepan@dynare.orgCompile fail w/ fix*Created by: cstackpole*
Greetings,
Had issues compiling the last few daily's. Ended up with a bunch of errors about comparisons between signed and unsigned integers. @almightybeeij helped me figure out it was a missing include.
In preprocessor/ModelTree.cc there is a missing line.
`#include <boost/range/empty.hpp>`
Thanks!*Created by: cstackpole*
Greetings,
Had issues compiling the last few daily's. Ended up with a bunch of errors about comparisons between signed and unsigned integers. @almightybeeij helped me figure out it was a missing include.
In preprocessor/ModelTree.cc there is a missing line.
`#include <boost/range/empty.hpp>`
Thanks!Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1500Remove `tests/practicing` from repository2019-06-19T15:37:42ZHoutan BastaniRemove `tests/practicing` from repositoryFollowing https://github.com/DynareTeam/dynare/issues/637#issuecomment-234199900, we should remove `tests/practicing` from the repository.
We can:
1) simply delete it
1) compress the files and serve them on www.dynare.org somewhere
What do people prefer?Following https://github.com/DynareTeam/dynare/issues/637#issuecomment-234199900, we should remove `tests/practicing` from the repository.
We can:
1) simply delete it
1) compress the files and serve them on www.dynare.org somewhere
What do people prefer?4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1463Errors in code in mh_optimal_bandwidth.m2019-06-19T15:37:42ZStéphane Adjemianstepan@dynare.orgErrors in code in mh_optimal_bandwidth.m*Created by: spcatterall*
It appears to me that there is an error in line 146 of mh_optimal_bandwidth.m:
`g3 = abs(2*correction*k6(0)/(mu21*Itilda4*correction))^(1/9);`
This line should be identical to line 113:
`g3 = abs(2*correction*k6(0)/(mu21*Itilda4*number_of_draws))^(1/9);`
Also, all references to 'n' in lines 135-152 should be replaced by 'number_of_draws'.
[I've recently written code in R which performs the same function as mh_optimal_bandwidth.m and I've read the paper underpinning these methods. I came across this matlab code during a google search.]*Created by: spcatterall*
It appears to me that there is an error in line 146 of mh_optimal_bandwidth.m:
`g3 = abs(2*correction*k6(0)/(mu21*Itilda4*correction))^(1/9);`
This line should be identical to line 113:
`g3 = abs(2*correction*k6(0)/(mu21*Itilda4*number_of_draws))^(1/9);`
Also, all references to 'n' in lines 135-152 should be replaced by 'number_of_draws'.
[I've recently written code in R which performs the same function as mh_optimal_bandwidth.m and I've read the paper underpinning these methods. I came across this matlab code during a google search.]https://git.dynare.org/Dynare/dynare/issues/1496Allow writing steady_state_model-block into LaTeX-document2019-06-19T15:37:42ZJohannes Pfeifer Allow writing steady_state_model-block into LaTeX-documentThis would make debugging a lot easierThis would make debugging a lot easier4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1495Problem with JSON output for model local variables2019-06-19T15:37:42ZHoutan BastaniProblem with JSON output for model local variablesThe lists created by `ModelTree::writeJsonModelLocalVariables` should be combined into the same listThe lists created by `ModelTree::writeJsonModelLocalVariables` should be combined into the same list4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1492Third order does not work with official stable OS X package (4.5.1)2019-06-19T15:37:42ZStéphane Adjemianstepan@dynare.orgThird order does not work with official stable OS X package (4.5.1)I obtain the following error message:
```matlab
Invalid MEX-file '/Applications/Dynare/4.5.1/matlab/../mex/matlab/osx/k_order_perturbation.mexmaci64': Missing dependent shared libraries:
'@rpath/libhdf5.6.dylib' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '__DefaultRuneLocale' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '__Unwind_Resume' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '___bzero' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '___cxa_atexit' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '___maskrune' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '___memcpy_chk' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '___powidf2' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '___stack_chk_fail' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '___stack_chk_guard' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '___stderrp' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '___stdoutp' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '___vsnprintf_chk' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_abort' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_asctime_r' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_calloc' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_clock' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_ctime' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_dlclose' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_dlerror' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_dlopen' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_dlsym' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_drand48' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_exit' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_fclose' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_feof' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_fflush' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_floor' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_fopen' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_fprintf' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_fread' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_free' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_fseek' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_ftell' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_fwrite' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_getloadavg' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_getrusage' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_gettimeofday' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_localtime_r' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_log' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_malloc' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_memcpy' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_memmove' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_memset' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_mktemp' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pow' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_printf' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_attr_destroy' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_attr_init' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_attr_setdetachstate' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_cond_broadcast' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_cond_destroy' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_cond_init' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_cond_wait' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_create' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_exit' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_join' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_mutex_init' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_mutex_lock' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_mutex_unlock' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_putchar' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_puts' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_remove' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_rename' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_round' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_sprintf' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_srand48' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_strcat' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_strcmp' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_strcpy' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_strdup' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_strlen' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_strncpy' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_sysconf' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_time' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_uname' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_vasprintf' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'.
Error in k_order_pert (line 57)
[err, g_0, g_1, g_2, g_3, derivs] = k_order_perturbation(dr, ...
Error in stochastic_solvers (line 96)
[dr,info] = k_order_pert(dr,M_,options_);
Error in resol (line 144)
[dr,info] = stochastic_solvers(dr,check_flag,M,options,oo);
Error in stoch_simul (line 84)
[oo_.dr,info,M_,options_,oo_] = resol(0,M_,options_,oo_);
```
Note however that if Dynare is installed through Homebrew, there is no such problems with `k_order_perturbation` Mex file. @houtanb Is it possible to have access to the code generating the package?I obtain the following error message:
```matlab
Invalid MEX-file '/Applications/Dynare/4.5.1/matlab/../mex/matlab/osx/k_order_perturbation.mexmaci64': Missing dependent shared libraries:
'@rpath/libhdf5.6.dylib' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '__DefaultRuneLocale' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '__Unwind_Resume' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '___bzero' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '___cxa_atexit' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '___maskrune' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '___memcpy_chk' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '___powidf2' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '___stack_chk_fail' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '___stack_chk_guard' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '___stderrp' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '___stdoutp' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '___vsnprintf_chk' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_abort' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_asctime_r' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_calloc' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_clock' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_ctime' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_dlclose' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_dlerror' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_dlopen' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_dlsym' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_drand48' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_exit' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_fclose' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_feof' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_fflush' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_floor' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_fopen' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_fprintf' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_fread' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_free' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_fseek' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_ftell' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_fwrite' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_getloadavg' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_getrusage' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_gettimeofday' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_localtime_r' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_log' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_malloc' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_memcpy' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_memmove' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_memset' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_mktemp' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pow' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_printf' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_attr_destroy' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_attr_init' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_attr_setdetachstate' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_cond_broadcast' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_cond_destroy' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_cond_init' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_cond_wait' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_create' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_exit' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_join' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_mutex_init' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_mutex_lock' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_pthread_mutex_unlock' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_putchar' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_puts' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_remove' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_rename' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_round' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_sprintf' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_srand48' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_strcat' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_strcmp' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_strcpy' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_strdup' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_strlen' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_strncpy' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_sysconf' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_time' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_uname' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'
Missing symbol '_vasprintf' required by '/Applications/Dynare/4.5.1/mex/matlab/osx/k_order_perturbation.mexmaci64'.
Error in k_order_pert (line 57)
[err, g_0, g_1, g_2, g_3, derivs] = k_order_perturbation(dr, ...
Error in stochastic_solvers (line 96)
[dr,info] = k_order_pert(dr,M_,options_);
Error in resol (line 144)
[dr,info] = stochastic_solvers(dr,check_flag,M,options,oo);
Error in stoch_simul (line 84)
[oo_.dr,info,M_,options_,oo_] = resol(0,M_,options_,oo_);
```
Note however that if Dynare is installed through Homebrew, there is no such problems with `k_order_perturbation` Mex file. @houtanb Is it possible to have access to the code generating the package?Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1494Investigate crash in newrat.m2019-06-19T15:37:42ZJohannes Pfeifer Investigate crash in newrat.mSee https://forum.dynare.org/t/mode-compute-5-in-dsge-var/10642
@rattoma Could you please have a look. The problem is that in the `else`-clause of
```
if length(find(ig))<nx
ggx=ggx*0;
ggx(find(ig))=gg(find(ig));
if analytic_derivation
hhx=hh;
else
hhx = reshape(dum,nx,nx);
end
```
the `dum` variable has not been set.See https://forum.dynare.org/t/mode-compute-5-in-dsge-var/10642
@rattoma Could you please have a look. The problem is that in the `else`-clause of
```
if length(find(ig))<nx
ggx=ggx*0;
ggx(find(ig))=gg(find(ig));
if analytic_derivation
hhx=hh;
else
hhx = reshape(dum,nx,nx);
end
```
the `dum` variable has not been set.4.6Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/1487Potentially make empirical moments independent of simul_replic2019-06-19T15:37:42ZJohannes Pfeifer Potentially make empirical moments independent of simul_replicWe currently rely on the last simulated series for computing moments. If `simul_replic` is increased, the moments will therefore change. I would propose to output the first instead of the last run in `simult.m`. That way, the results would always be the same. Of course, this would entail some loss of backward compatibility. I would accept this, because in principle any replication for the moments should do and the manual states that `simul_replic` is not used for moment computation. Related to https://forum.dynare.org/t/impact-of-simul-replic-option-on-empirical-moments/10553/4We currently rely on the last simulated series for computing moments. If `simul_replic` is increased, the moments will therefore change. I would propose to output the first instead of the last run in `simult.m`. That way, the results would always be the same. Of course, this would entail some loss of backward compatibility. I would accept this, because in principle any replication for the moments should do and the manual states that `simul_replic` is not used for moment computation. Related to https://forum.dynare.org/t/impact-of-simul-replic-option-on-empirical-moments/10553/4https://git.dynare.org/Dynare/dynare/issues/1486Make variance decomposition of observables account for measurement error2019-06-19T15:37:42ZJohannes Pfeifer Make variance decomposition of observables account for measurement errorCurrently, we only decompose the variable after the measurement error has been taken out.Currently, we only decompose the variable after the measurement error has been taken out.4.6Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/163Finish first version of internal documentation2019-06-19T15:37:43ZSébastien VillemotFinish first version of internal documentationSee doc/internals/dynare-internals.org for the first draft.
For the IMF.
See doc/internals/dynare-internals.org for the first draft.
For the IMF.
https://git.dynare.org/Dynare/dynare/issues/162Global method: stochastic simulation approach2019-06-19T15:37:43ZSébastien VillemotGlobal method: stochastic simulation approachAs advocated by Judd, Maliar & Maliar in recent NBER WP.
For the IMF.
As advocated by Judd, Maliar & Maliar in recent NBER WP.
For the IMF.
https://git.dynare.org/Dynare/dynare/issues/149Handle missing values in block decomposed version of Kalman filter2019-06-19T15:37:43ZSébastien VillemotHandle missing values in block decomposed version of Kalman filterhttps://git.dynare.org/Dynare/dynare/issues/147Accuracy checks2019-11-21T08:36:40ZSébastien VillemotAccuracy checkshttps://git.dynare.org/Dynare/dynare/issues/135Improve display of decision rules with EXPECTATION operator2019-11-21T08:36:45ZSébastien VillemotImprove display of decision rules with EXPECTATION operatorCurrently, if the user inputs EXPECTATION(-1)(some_expr) in her model, then a new aux variable is created, and this var is a state var, which appears in the decision rules as EXPECTATION(-1)(...) (with the dots instead of the expression). This is not very informative. Displaying the full expression would require to add a new writeOutput method in the preprocessor.
And for something like EXPECTATION(-2)(some_expr), it is even worse, because there are 2 aux vars: one for the operator, and the second one which appears when removing lags of 2. It is the latter which appears in stoch_simul. Fixing this requires to fix the orig_endo field of M_.aux_vars in that case.
Currently, if the user inputs EXPECTATION(-1)(some_expr) in her model, then a new aux variable is created, and this var is a state var, which appears in the decision rules as EXPECTATION(-1)(...) (with the dots instead of the expression). This is not very informative. Displaying the full expression would require to add a new writeOutput method in the preprocessor.
And for something like EXPECTATION(-2)(some_expr), it is even worse, because there are 2 aux vars: one for the operator, and the second one which appears when removing lags of 2. It is the latter which appears in stoch_simul. Fixing this requires to fix the orig_endo field of M_.aux_vars in that case.
https://git.dynare.org/Dynare/dynare/issues/133datafile option in simul2019-11-21T08:36:42ZSébastien Villemotdatafile option in simulthis option is very similar to initval_file but it requires two different files for endogenous and exogenous variables.
The entry in the manual doesn't describe the required files.
It may be interesting to use it for loading only trajectories for the exogenous variables.
this option is very similar to initval_file but it requires two different files for endogenous and exogenous variables.
The entry in the manual doesn't describe the required files.
It may be interesting to use it for loading only trajectories for the exogenous variables.
https://git.dynare.org/Dynare/dynare/issues/116IRF: give the possibility to choose the starting point (at least at order 2 a...2019-11-21T08:36:40ZSébastien VillemotIRF: give the possibility to choose the starting point (at least at order 2 and above)In particular, give the possibility to start from the stochastic steady state
In particular, give the possibility to start from the stochastic steady state
https://git.dynare.org/Dynare/dynare/issues/115IRF: add the possibility to change the size of the shocks in the computations2019-11-21T08:36:40ZSébastien VillemotIRF: add the possibility to change the size of the shocks in the computationsAt order 1, it is equivalent to changing the standard deviation of the shocks and adding the corresponding inverse transformation in the equations.
But at orders 2 and above, the equivalence does not hold.
At order 1, it is equivalent to changing the standard deviation of the shocks and adding the corresponding inverse transformation in the equations.
But at orders 2 and above, the equivalence does not hold.
https://git.dynare.org/Dynare/dynare/issues/6Possible optimization of decision rules at first order2019-11-21T08:36:46ZSébastien VillemotPossible optimization of decision rules at first orderIn dr.pdf, at the end of section 4.1, we have:
g^-_y = Z'_11 T^{-1}_11 S_{11} (Z'_{11})^{-1}
But dr1.m used to contain the following formula:
g^-_y = (T^{-1}_11 X)^{-1} S_{11} X
which is probably more efficient given that X=Z_{11}+Z_{12}g⁺_y (see equation 10), because it saves an inversion
We should make benchmarks between the 2 formulas, because Ondra thinks that for performance reasons, the first method is better, even though this is not obvious.
In dr.pdf, at the end of section 4.1, we have:
g^-_y = Z'_11 T^{-1}_11 S_{11} (Z'_{11})^{-1}
But dr1.m used to contain the following formula:
g^-_y = (T^{-1}_11 X)^{-1} S_{11} X
which is probably more efficient given that X=Z_{11}+Z_{12}g⁺_y (see equation 10), because it saves an inversion
We should make benchmarks between the 2 formulas, because Ondra thinks that for performance reasons, the first method is better, even though this is not obvious.
Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/7In dr.tex, add a concrete example on a model (by expliciting the matrices)2019-11-21T08:36:42ZSébastien VillemotIn dr.tex, add a concrete example on a model (by expliciting the matrices)https://git.dynare.org/Dynare/dynare/issues/4Integrate algorithm for TBC by Holden and Paetz (2012)2019-06-19T15:37:43ZSébastien VillemotIntegrate algorithm for TBC by Holden and Paetz (2012)Request by Stéphane Moyen.
Paper at http://www.tholden.org/files/zlb.pdf?attredirects=0
Apparently the code has been posted on the Dynare forums. It's therefore a matter of dealing with copyright/license issues and integrating it.
Request by Stéphane Moyen.
Paper at http://www.tholden.org/files/zlb.pdf?attredirects=0
Apparently the code has been posted on the Dynare forums. It's therefore a matter of dealing with copyright/license issues and integrating it.
https://git.dynare.org/Dynare/dynare/issues/1477Allow calling calib_smoother with parameter_set option2019-06-19T15:37:43ZJohannes Pfeifer Allow calling calib_smoother with parameter_set optionCurrently, the `calib_smoother` calls `evaluate_smoother` with the first input argument being `calibration`. We should allow for a `parameter_set`-like option to select the parameter set at which to compute the smoother. Default should be `calibration`.
Related to http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=24518 Currently, the `calib_smoother` calls `evaluate_smoother` with the first input argument being `calibration`. We should allow for a `parameter_set`-like option to select the parameter set at which to compute the smoother. Default should be `calibration`.
Related to http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=24518 4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1454Make dynare_version and ver_less_than work with Master2019-06-19T15:37:43ZJohannes Pfeifer Make dynare_version and ver_less_than work with Master`dynare_version.m` on the unstable version returns strings like `master-2017-05-18-95da783`. This way of providing a version number is not compatible with our functions like `ver_greater_than`, which rely on purely numeric output. But MacroModelBase relies on `dynare_version.m``dynare_version.m` on the unstable version returns strings like `master-2017-05-18-95da783`. This way of providing a version number is not compatible with our functions like `ver_greater_than`, which rely on purely numeric output. But MacroModelBase relies on `dynare_version.m`Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1453Fix bug introduced in issue 13362019-06-19T15:37:44ZJohannes Pfeifer Fix bug introduced in issue 1336In 7829a252387d6da559b37b37797bf5fa4330f6ad related to https://github.com/DynareTeam/dynare/issues/1336 we set `order=1` locally in `stochastic_solvers`. While that speeds up the solution, the subsequent functions do not know that `order` was locally changed. That crashes e.g. `disp_dr` and `th_autocovariances`, because they are looking for `dr.ghs2` which would be there at `order=2`In 7829a252387d6da559b37b37797bf5fa4330f6ad related to https://github.com/DynareTeam/dynare/issues/1336 we set `order=1` locally in `stochastic_solvers`. While that speeds up the solution, the subsequent functions do not know that `order` was locally changed. That crashes e.g. `disp_dr` and `th_autocovariances`, because they are looking for `dr.ghs2` which would be there at `order=2`https://git.dynare.org/Dynare/dynare/issues/1452Update info for building from source2019-06-19T15:37:44ZJohannes Pfeifer Update info for building from sourceParticularly on Mac when not using homebrew (e.g. for own branches), some package versions may be too new. For example, Bison 3 does not work. Instead one needs 2.7 or so. According to @houtanb one can use
```
brew tap homebrew/versions
brew install homebrew/versions/bison27
brew link --force bison27
```
But the `readme.md` only states one needs `Bison, version 2.5 or later`, which is not correct. A similar issue may be true for `Flex`
Particularly on Mac when not using homebrew (e.g. for own branches), some package versions may be too new. For example, Bison 3 does not work. Instead one needs 2.7 or so. According to @houtanb one can use
```
brew tap homebrew/versions
brew install homebrew/versions/bison27
brew link --force bison27
```
But the `readme.md` only states one needs `Bison, version 2.5 or later`, which is not correct. A similar issue may be true for `Flex`
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1439Fix bytecode memory problem introduced in #14202019-06-19T15:37:44ZJohannes Pfeifer Fix bytecode memory problem introduced in #1420#1420 changed the memory allocation. Since then `ramst_normcdf_and_friends_static` fails with
```
Fatal error in bytecode: mxMalloc: out of memory 352 bytes required at line 1915 in function Init_GE (file ../../../sources/bytecode/SparseMatrix.cc
```#1420 changed the memory allocation. Since then `ramst_normcdf_and_friends_static` fails with
```
Fatal error in bytecode: mxMalloc: out of memory 352 bytes required at line 1915 in function Init_GE (file ../../../sources/bytecode/SparseMatrix.cc
```FerhatMihoubiFerhatMihoubihttps://git.dynare.org/Dynare/dynare/issues/1437Speed of Kalman filter in unstable vs 4.4.32019-06-19T15:37:44ZJohannes Pfeifer Speed of Kalman filter in unstable vs 4.4.3Joris reports at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=6373&start=15#p37426 that 4.4.3 runs Bayesian estimation a lot faster than the current master. Profiling `fs2000.mod`, the culprit seems to be https://github.com/DynareTeam/dynare/pull/1088/commits/05fc096569e15e89d8d13b08799321c0313b168d where we made the Kalman filter more robust against ill-conditioned matrices. This seems to have considerable computational costs, because the function is called so often. I wonder if switching to the univariate filter if problems appear is not the better default.
Joris reports at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=6373&start=15#p37426 that 4.4.3 runs Bayesian estimation a lot faster than the current master. Profiling `fs2000.mod`, the culprit seems to be https://github.com/DynareTeam/dynare/pull/1088/commits/05fc096569e15e89d8d13b08799321c0313b168d where we made the Kalman filter more robust against ill-conditioned matrices. This seems to have considerable computational costs, because the function is called so often. I wonder if switching to the univariate filter if problems appear is not the better default.
Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1434Check ksstat option of sensitivity2019-06-19T15:37:44ZJohannes Pfeifer Check ksstat option of sensitivityIt seems to be superseded by e.g. `pvalue_ks`. See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=17952
While it appears in `stab_map_.m` is seems to not be used at all.It seems to be superseded by e.g. `pvalue_ks`. See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=17952
While it appears in `stab_map_.m` is seems to not be used at all.https://git.dynare.org/Dynare/dynare/issues/1431Port write_equation_tags to write_latex_static_model and write_latex_original...2019-06-19T15:37:44ZJohannes Pfeifer Port write_equation_tags to write_latex_static_model and write_latex_original_modelSee https://github.com/DynareTeam/dynare/commit/14f4544a29eac182ff1f5840e5f9cc78b9efa7e0#commitcomment-21632978See https://github.com/DynareTeam/dynare/commit/14f4544a29eac182ff1f5840e5f9cc78b9efa7e0#commitcomment-216329784.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1425create interface for initial_condition_decomposition2019-06-19T15:37:44ZHoutan Bastanicreate interface for initial_condition_decompositionSee #1421See #14214.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1415rewrite dyn_saveas, dyn_figure to take the options they need as arguments2019-06-19T15:37:44ZHoutan Bastanirewrite dyn_saveas, dyn_figure to take the options they need as argumentsThis is a first step in the long road to completing #1414This is a first step in the long road to completing #14144.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1409Add an interface for setting initial condition of the Kalman filter2019-06-19T15:37:44ZStéphane Adjemianstepan@dynare.orgAdd an interface for setting initial condition of the Kalman filterSee discussion in #1395.See discussion in #1395.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1410Make master mex-files compatible with Matlab R2017a and adjust installer for ...2019-06-19T15:37:44ZJohannes Pfeifer Make master mex-files compatible with Matlab R2017a and adjust installer for WindowsFollowing the discussion in #1225, Matlab R2017a seems to require a change in mex-file compilation.
This also implies that the commit https://github.com/DynareTeam/dynare/commit/4f3b35acbaaa23ad81d5200f68eacbbd9c9b98b6 is not correct, because we need a different set of 64bit mex-files going forward, starting with version `9.2`.Following the discussion in #1225, Matlab R2017a seems to require a change in mex-file compilation.
This also implies that the commit https://github.com/DynareTeam/dynare/commit/4f3b35acbaaa23ad81d5200f68eacbbd9c9b98b6 is not correct, because we need a different set of 64bit mex-files going forward, starting with version `9.2`.https://git.dynare.org/Dynare/dynare/issues/1406Add interface for #13722019-06-19T15:37:44ZStéphane Adjemianstepan@dynare.orgAdd interface for #1372@houtanb To identify the needed modifications look at #1372 and the new entries in the reference manual.@houtanb To identify the needed modifications look at #1372 and the new entries in the reference manual.4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1403Decide on changing prior in fs2000.mod2019-06-19T15:37:44ZJohannes Pfeifer Decide on changing prior in fs2000.modhttps://github.com/DynareTeam/dynare/commit/b14cf33c8ffe936c3c3ad79846335e918be7fb77 changed the prior for `rho` in the integration tests to not have an asymptote. But this change was not ported to the `fs2000.mod` in the Dynare `examples`-folder. Following the discussion in #1401, we warn users against using such a prior. Therefore, I would propose to change the prior in the `examples`mod-file as well. After all, it is an example, not a replication file.https://github.com/DynareTeam/dynare/commit/b14cf33c8ffe936c3c3ad79846335e918be7fb77 changed the prior for `rho` in the integration tests to not have an asymptote. But this change was not ported to the `fs2000.mod` in the Dynare `examples`-folder. Following the discussion in #1401, we warn users against using such a prior. Therefore, I would propose to change the prior in the `examples`mod-file as well. After all, it is an example, not a replication file.https://git.dynare.org/Dynare/dynare/issues/1398replace equation cross references with those done for json2019-06-19T15:37:44ZHoutan Bastanireplace equation cross references with those done for jsonReplace original version done in 4976b2b3359688e9b1d000bdf05f95d5b6071ac3, f546368252 with those done in 0ccc82300c3046d159554c24027ded09a93b687e
The changes in 0ccc82300c3046d159554c24027ded09a93b687e contain information on lags whereas the original ones don'tReplace original version done in 4976b2b3359688e9b1d000bdf05f95d5b6071ac3, f546368252 with those done in 0ccc82300c3046d159554c24027ded09a93b687e
The changes in 0ccc82300c3046d159554c24027ded09a93b687e contain information on lags whereas the original ones don't4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1397preprocessor: static params derivatives don't use temporary terms2019-06-19T15:37:44ZHoutan Bastanipreprocessor: static params derivatives don't use temporary termssee `kim2_static_params_derivs.m` produced by `identification/kim/kim2.mod`see `kim2_static_params_derivs.m` produced by `identification/kim/kim2.mod`Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1394JSON: incorrect printing of expressions for parameter initializations.2019-06-19T15:37:44ZStéphane Adjemianstepan@dynare.orgJSON: incorrect printing of expressions for parameter initializations.*Created by: albop*
When parameter initializations contains expressions, symbols are replaced by references to `M_.params` instead of symbol name.
For instance, in `example1.mod` if we replace line `rho = 0.95;` by `rho = 0.95+alpha*0.00001;` we currently get:
```
{"statementName": "param_init", "name": "rho", "value": "0.95+M_.params(3)*0.00001"}
```
instead of:
```
{"statementName": "param_init", "name": "rho", "value": "0.95+alpha*0.00001"}
```
It works correctly for variable initializations.*Created by: albop*
When parameter initializations contains expressions, symbols are replaced by references to `M_.params` instead of symbol name.
For instance, in `example1.mod` if we replace line `rho = 0.95;` by `rho = 0.95+alpha*0.00001;` we currently get:
```
{"statementName": "param_init", "name": "rho", "value": "0.95+M_.params(3)*0.00001"}
```
instead of:
```
{"statementName": "param_init", "name": "rho", "value": "0.95+alpha*0.00001"}
```
It works correctly for variable initializations.Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1392fix ramsey_model syntax2019-06-19T15:37:44ZHoutan Bastanifix ramsey_model syntax@MichelJuillard Currently `ramsey_model` accepts a list of symbols in the syntax and the `RamseyModelStatement` accepts a `symbol_list` but nothing is done with it. Furthermore, there's no reference to the `symbol_list` form in the manual. Is there a reason you added support for `symbol_list` to `ramsey_model` in d945395a15, e90859ba524abfcb570d6cf09394ce86b4405090, and 17477ab095bb4f9b24d0da5ec5cf747f41988bb4@MichelJuillard Currently `ramsey_model` accepts a list of symbols in the syntax and the `RamseyModelStatement` accepts a `symbol_list` but nothing is done with it. Furthermore, there's no reference to the `symbol_list` form in the manual. Is there a reason you added support for `symbol_list` to `ramsey_model` in d945395a15, e90859ba524abfcb570d6cf09394ce86b4405090, and 17477ab095bb4f9b24d0da5ec5cf747f41988bb44.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1390create option to suppress preprocessor output to stdout2019-06-19T15:37:44ZHoutan Bastanicreate option to suppress preprocessor output to stdoutSuppress this:
```
Configuring Dynare ...
[mex] Generalized QZ.
[mex] Sylvester equation solution.
[mex] Kronecker products.
[mex] Sparse kronecker products.
[mex] Local state space iteration (second order).
[mex] Bytecode evaluation.
[mex] k-order perturbation solver.
[mex] k-order solution simulation.
[mex] Quasi Monte-Carlo sequence (Sobol).
[mex] Markov Switching SBVAR.
Using 64-bit preprocessor
Starting Dynare (version 4.5-unstable).
Starting preprocessing of the model file ...
```
and stuff like this....
```
Found 6 equation(s).
Evaluating expressions...done
Computing static model derivatives:
- order 1
Computing dynamic model derivatives:
- order 1
- order 2
Processing outputs ...
done
Preprocessing completed.
```
This would make it easier to read json output when the `jsonstdout` option is passed.Suppress this:
```
Configuring Dynare ...
[mex] Generalized QZ.
[mex] Sylvester equation solution.
[mex] Kronecker products.
[mex] Sparse kronecker products.
[mex] Local state space iteration (second order).
[mex] Bytecode evaluation.
[mex] k-order perturbation solver.
[mex] k-order solution simulation.
[mex] Quasi Monte-Carlo sequence (Sobol).
[mex] Markov Switching SBVAR.
Using 64-bit preprocessor
Starting Dynare (version 4.5-unstable).
Starting preprocessing of the model file ...
```
and stuff like this....
```
Found 6 equation(s).
Evaluating expressions...done
Computing static model derivatives:
- order 1
Computing dynamic model derivatives:
- order 1
- order 2
Processing outputs ...
done
Preprocessing completed.
```
This would make it easier to read json output when the `jsonstdout` option is passed.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1387create JSON output after every step of the preprocessor2019-06-19T15:37:44ZHoutan Bastanicreate JSON output after every step of the preprocessor4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1386implement syntax to declare model variables on the fly2019-06-19T15:37:45ZHoutan Bastaniimplement syntax to declare model variables on the fly4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1384do not automatically create *_set_auxiliary_variables.m on preprocessor run2019-06-19T15:37:45ZHoutan Bastanido not automatically create *_set_auxiliary_variables.m on preprocessor runAs `*_set_auxiliary_variables.m` is sometimes empty, it does not make sense to create it on every run. Only create it if something will be written to it.
This change requires either a flag in `M_` to be tested every time the function is called in the code or to test `exist('./*set_auxiliary_variables.m') == 2` and take the appropriate action in the code.As `*_set_auxiliary_variables.m` is sometimes empty, it does not make sense to create it on every run. Only create it if something will be written to it.
This change requires either a flag in `M_` to be tested every time the function is called in the code or to test `exist('./*set_auxiliary_variables.m') == 2` and take the appropriate action in the code.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1380stop storing index for symbols in SymbolTable2019-06-19T15:37:45ZHoutan Bastanistop storing index for symbols in SymbolTableWe store the variable `size` in `SymbolTable` when we can have access to this info by changing `symbol_table` into a vector and use the size method when we need to know how many symbols are presentWe store the variable `size` in `SymbolTable` when we can have access to this info by changing `symbol_table` into a vector and use the size method when we need to know how many symbols are present4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1377Decide on treatment of qz_criterium in estimation with particle filter2019-06-19T15:37:45ZJohannes Pfeifer Decide on treatment of qz_criterium in estimation with particle filterCurrently, if a unit root is present, estimation with `order=2` will result in an error. Using `diffuse_filter` will disable the check, but obviously makes no sense for particle filtering. See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=13126Currently, if a unit root is present, estimation with `order=2` will result in an error. Using `diffuse_filter` will disable the check, but obviously makes no sense for particle filtering. See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=131264.6https://git.dynare.org/Dynare/dynare/issues/1373Decide on whether evalute_smoother (and others) should set M_.params2019-06-19T15:37:45ZJohannes Pfeifer Decide on whether evalute_smoother (and others) should set M_.paramsThis picks up the discussion in https://github.com/DynareTeam/dynare/pull/1372#issuecomment-271336355
I agree with @MichelJuillard that changing `M_.params` in various functions is a bad idea as it makes it hard to trace what was going on in the mod-file. At the same time, I agree with @rattoma that keeping `M_.params` unchanged when calling `evaluate_smoother` would imply a break with previous versions and therefore mean a loss in backward compatibility. I could live with that, but usually @MichelJuillard prefers to be cautious in the regard. If we want to preserve backward compatibility, we need to make sure that `shock_decomposition` returns `M_` from `evaluate_smoother` to the base workspace, which was broken by https://github.com/DynareTeam/dynare/commit/2f717b5adc5a87f663c5c080f2963d1f65d1933eThis picks up the discussion in https://github.com/DynareTeam/dynare/pull/1372#issuecomment-271336355
I agree with @MichelJuillard that changing `M_.params` in various functions is a bad idea as it makes it hard to trace what was going on in the mod-file. At the same time, I agree with @rattoma that keeping `M_.params` unchanged when calling `evaluate_smoother` would imply a break with previous versions and therefore mean a loss in backward compatibility. I could live with that, but usually @MichelJuillard prefers to be cautious in the regard. If we want to preserve backward compatibility, we need to make sure that `shock_decomposition` returns `M_` from `evaluate_smoother` to the base workspace, which was broken by https://github.com/DynareTeam/dynare/commit/2f717b5adc5a87f663c5c080f2963d1f65d1933ehttps://git.dynare.org/Dynare/dynare/issues/1367Investigate issue with disp_dr>subst_auxvar (line 248)2019-06-19T15:37:45ZJohannes Pfeifer Investigate issue with disp_dr>subst_auxvar (line 248)When `M_.aux_vars(i).type = 0` (lead>1), a crash happens. But it is not clear in which case this happens as leads should not be present on the right-hand side of decision rules. See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=12593When `M_.aux_vars(i).type = 0` (lead>1), a crash happens. But it is not clear in which case this happens as leads should not be present on the right-hand side of decision rules. See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=12593https://git.dynare.org/Dynare/dynare/issues/1368Verify correctness of manual regarding unfolding of third order matrices2019-06-19T15:37:45ZJohannes Pfeifer Verify correctness of manual regarding unfolding of third order matricesSee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=12557See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=12557https://git.dynare.org/Dynare/dynare/issues/1366Decide on how to deal with mistake in manual regarding updated variables2019-06-19T15:37:45ZJohannes Pfeifer Decide on how to deal with mistake in manual regarding updated variablesAccording to the manual, `smoother` triggers the computation of `oo_.UpdatedVariables`. But one actually needs `filtered_vars`. We can either
1. Correct the description in the manual to reflect the code behavior
2. Flag this as a bug as the code deviates from the manual and output `oo_.UpdatedVariables` when only the `smoother` option is specifiedAccording to the manual, `smoother` triggers the computation of `oo_.UpdatedVariables`. But one actually needs `filtered_vars`. We can either
1. Correct the description in the manual to reflect the code behavior
2. Flag this as a bug as the code deviates from the manual and output `oo_.UpdatedVariables` when only the `smoother` option is specifiedhttps://git.dynare.org/Dynare/dynare/issues/1364Allow loading data from mat-files that contain other variables2019-06-19T15:37:45ZJohannes Pfeifer Allow loading data from mat-files that contain other variablesWe rely on `load_mat_file_data.m` from `dseries` to read in `mat`-files. There we use
```
for i=1:length(varlist)
try
tmp = getfield(datafile,varlist{i});
data = [data, tmp(:)];
catch
error(['load_mat_file:: All the vectors (variables) in ' inputname(1) ' must have the same number of rows (observations)!'])
end
end
```
to read _all_ variables and concatenate them in an array. If there is any other variable in the mat-file that does not have conformable dimensions, we abort with a crash. This deviates from earlier behavior and will result in many users reporting problems with backward compatibility if we release `4.5` this way. Is there a way to only load the specified `varobs`? Currently, it seems impossible to pass this through the `dseries`.We rely on `load_mat_file_data.m` from `dseries` to read in `mat`-files. There we use
```
for i=1:length(varlist)
try
tmp = getfield(datafile,varlist{i});
data = [data, tmp(:)];
catch
error(['load_mat_file:: All the vectors (variables) in ' inputname(1) ' must have the same number of rows (observations)!'])
end
end
```
to read _all_ variables and concatenate them in an array. If there is any other variable in the mat-file that does not have conformable dimensions, we abort with a crash. This deviates from earlier behavior and will result in many users reporting problems with backward compatibility if we release `4.5` this way. Is there a way to only load the specified `varobs`? Currently, it seems impossible to pass this through the `dseries`.4.6https://git.dynare.org/Dynare/dynare/issues/1356introduce posterior_nograph option2019-06-19T15:37:45ZMarco Rattointroduce posterior_nograph optionI think it would be useful to have an option like:
`options_.posterior_nograph`
with default value at 0 like standard nograph.
This option would allow performing all possible posterior subdraws for irfs, smoothed variables etc, but avoiding to produce thousands of useless graphs that are currently done [for large models at least].
I think it would also be useful to make a distinction w.r.t. `options_.nograph` since the latter would not trigger prior/posterior plots of parameter estimates which would be required in any case.
And by the way, `pm3` and `posterior_irf` do not seem to honor the nograph option: plots are made in any case. So at least we should make sure `nograph` would work properly?
If you agree, I would make the appropriate changes to the matlab `pm3` and `posterior_irf` routines with `posterior_nograph` [the preprocessor could be updated with this extra option, then].
I think it would be useful to have an option like:
`options_.posterior_nograph`
with default value at 0 like standard nograph.
This option would allow performing all possible posterior subdraws for irfs, smoothed variables etc, but avoiding to produce thousands of useless graphs that are currently done [for large models at least].
I think it would also be useful to make a distinction w.r.t. `options_.nograph` since the latter would not trigger prior/posterior plots of parameter estimates which would be required in any case.
And by the way, `pm3` and `posterior_irf` do not seem to honor the nograph option: plots are made in any case. So at least we should make sure `nograph` would work properly?
If you agree, I would make the appropriate changes to the matlab `pm3` and `posterior_irf` routines with `posterior_nograph` [the preprocessor could be updated with this extra option, then].
4.5https://git.dynare.org/Dynare/dynare/issues/1355Allow adding auxiliary variables like Ramsey multipliers to var_list_2019-06-19T15:37:45ZJohannes Pfeifer Allow adding auxiliary variables like Ramsey multipliers to var_list_The auxiliary variables are endogenous variables like every other variable. A call like
`ramsey_policy(instruments=(i),irf=13,planner_discount=betta,periods=200) x pi MULT_1;`
would be suficient to display IRFs for the multiplier 1. However, the preprocessor does not allow adding `MULT_1` to the variable list, because:
`Unknown symbol: MULT_1`
We should allow adding any variable present in `M_.endo_names` to the `var_list_`. @houtanb Could you do this, please?
Related to http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=12117The auxiliary variables are endogenous variables like every other variable. A call like
`ramsey_policy(instruments=(i),irf=13,planner_discount=betta,periods=200) x pi MULT_1;`
would be suficient to display IRFs for the multiplier 1. However, the preprocessor does not allow adding `MULT_1` to the variable list, because:
`Unknown symbol: MULT_1`
We should allow adding any variable present in `M_.endo_names` to the `var_list_`. @houtanb Could you do this, please?
Related to http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=121174.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1349set number of threads per job in parallel execution2019-06-19T15:37:45ZMarco Rattoset number of threads per job in parallel executionGiven the large number of CPU's being made available on desktop pc's, the current node option `singleCompThread` looks rather limited.
I would propose the following changes to the parallel configuration:
- set the default for `singleCompThread` to 0;
- add a node option in dynare.ini `numberOfThreadsPerJob`, which allows to set the number of cpu's assigned to each job. So, for example, for a node with 8 CPU's and `numberOfThreadsPerJob=2`, the parallel engine will split the work into 4 parallel instances, each using 2 cpu's.
would this be possible?Given the large number of CPU's being made available on desktop pc's, the current node option `singleCompThread` looks rather limited.
I would propose the following changes to the parallel configuration:
- set the default for `singleCompThread` to 0;
- add a node option in dynare.ini `numberOfThreadsPerJob`, which allows to set the number of cpu's assigned to each job. So, for example, for a node with 8 CPU's and `numberOfThreadsPerJob=2`, the parallel engine will split the work into 4 parallel instances, each using 2 cpu's.
would this be possible?4.5Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/1350Fix shock_decomposition when selected_variables_only is specified2019-06-19T15:37:45ZJohannes Pfeifer Fix shock_decomposition when selected_variables_only is specifiedThe option `selected_variables_only` is currently incompatible with `shock_decomposition ` as can be seen in the mod-file
```
var y ${y}$ (long_name='output')
y_nat ${y^{nat}}$ (long_name='natural output')
y_gap ${\tilde y}$ (long_name='output gap')
pi ${\pi}$ (long_name='inflation')
c ${c}$ (long_name='consumption')
lam ${\lambda}$ (long_name='Lagrange multiplier')
n ${n}$ (long_name='hours worked')
w ${w}$ (long_name='real wage')
r ${r}$ (long_name='nominal interest rate')
mc ${\tau}$ (long_name='Marginal cost')
e ${e}$ (long_name='demand elasticty')
x ${x}$ (long_name='Preference shock')
a ${a}$ (long_name='AR(1) technology shock process')
nu ${\nu}$ (long_name='monetary shock process')
y_fd ${\varepsilon_e}$ (long_name='markup shock')
w_fd ${\varepsilon_e}$ (long_name='markup shock')
r_obs ${\varepsilon_e}$ (long_name='markup shock')
pi_obs ${\varepsilon_e}$ (long_name='markup shock')
;
varexo eps_a ${\varepsilon_a}$ (long_name='technology shock')
eps_nu ${\varepsilon_\nu}$ (long_name='monetary policy shock')
eps_x ${\varepsilon_x}$ (long_name='preference shock')
eps_e ${\varepsilon_e}$ (long_name='markup shock')
;
parameters
alppha ${\alpha}$ (long_name='capital share')
betta ${\beta}$ (long_name='discount factor')
h ${h}$ (long_name='Parameter habit consumption')
phi ${\phi}$ (long_name='unitary Frisch elasticity')
chix ${\chi}$ (long_name='price indexation')
rho_pi ${\phi_{\pi}}$ (long_name='inflation feedback Taylor Rule')
rho_y ${\phi_{y}}$ (long_name='output feedback Taylor Rule')
rho_r ${\phi_{y}}$ (long_name='degree of smoothing Taylor rule')
epsilon ${\epsilon}$ (long_name='steady state demand elasticity')
theta ${\theta}$ (long_name='Calvo parameter')
rho_a ${\rho_{x}}$ (long_name='autocorrelation technology shock')
rho_x ${\rho_{x}}$ (long_name='autocorrelation preference shock')
rho_nu ${\rho_{x}}$ (long_name='autocorrelation monetary shock')
;
%---------------------------------------------------------------
% Parametrization, p. 52
%---------------------------------------------------------------
alppha = 0.3;
betta = 0.99;
h = 0.7;
phi = 1;
chix = 0.6;
rho_pi = 1.5;
rho_y = 0.2;
rho_r = 0.8;
epsilon = 6;
theta = 0.6;
rho_a = 0.8;
rho_x = 0.5;
rho_nu = 0.4;
%---------------------------------------------------------------
% First Order Conditions
%---------------------------------------------------------------
model(linear);
//1. F.O.C. consumption for Households
lam*(1-(h*betta)) = x-((c-(h*c(-1)))*(1/(1-h)))-(h*betta*x(+1))+((c(+1)-(h*c))*((h*betta)/(1-h)));
//2. F.O.C. leisure for Households
phi*n=lam+w;
//3. F.O.C. bonds for Households
0=lam(+1)-lam+r-pi(+1);
//4. Average marginal cost
mc=w+(y*(alppha/(1-alppha)))-(a*(1/(1-alppha)));
//5. First auxiliary variable
pi=((betta/(1+(betta*chix)))*pi(+1))+((chix/(1+(betta*chix)))*pi(-1))+((mc-(e*(1/(epsilon-1))))*(((1-theta*betta)*(1-theta)*(1-alppha))/((1+betta*chix)*(1-alppha+alppha*epsilon)*theta)));
//8. Natural output
alppha*y_nat=a-((1-alppha)*w)+(((1-alppha)/(epsilon-1))*e);
//9. Taylor Rule
r=(r(-1)*rho_r)+((1-rho_r)*((rho_pi*pi)+(rho_y*y_gap)))+nu;
//10. Definition output gap
y_gap = y-y_nat;
//12. Equilibrium
y=c;
//13. Production function
y=(n*(1-alppha))+a;
//14. TFP shock
a=(rho_a*a(-1))+eps_a;
//15. Preference shock
x=(rho_x*x(-1))+eps_x;
//16. Markup shock
e=((1-epsilon)/epsilon)*eps_e;
//17. Monetary shock
nu=(rho_nu*nu(-1))+eps_nu;
//// Observation equations
//18. Output
y_fd = y;
//19. Wage
w_fd = w;
//20. Interes Rate
r_obs=r;
//21. Inflation
pi_obs=pi;
end;
shocks;
var eps_a= 0.02^2 ;
var eps_nu= 0.04^2;
var eps_x= 0.02^2;
var eps_e= 0.2^2;
end;
stoch_simul(order=1,periods=200,irf=0) y_fd w_fd r_obs pi_obs;
datatomfile('observables_gali2_filt_119',char('y_fd','w_fd','r_obs','pi_obs'));
varobs y_fd w_fd r_obs pi_obs;
estimated_params;
alppha, 0.3, 0, 1,beta_pdf, 0.3, 0.05;
h, 0.7, 0, 1,beta_pdf, 0.33, 0.15;
phi, 1, , ,gamma_pdf, 1.17, 0.351;
chix, 0.6, 0, 1, beta_pdf, 0.61, 0.112;
rho_pi, 1.5, 0, 10, normal_pdf, 1.5, 0.2;
rho_y, 0.2, 0, 10, normal_pdf, 0.2, 0.1;
theta, 0.6, 0, 1, beta_pdf, 0.61, 0.112;
rho_a, 0.7, 0, 1, beta_pdf, 0.61, 0.112;
rho_x, 0.5, 0, 1, beta_pdf, 0.61, 0.112;
rho_nu, 0.4, 0, 1, beta_pdf, 0.61, 0.112;
stderr eps_a, inv_gamma_pdf, 0.1, 2;
stderr eps_nu, inv_gamma_pdf, 0.1, 2;
stderr eps_x, inv_gamma_pdf, 0.1, 2;
stderr eps_e, inv_gamma_pdf, 0.1, 2;
end;
estimated_params_init;
alppha, 0.3;
h, 0.7;
phi, 1;
chix, 0.6;
rho_pi, 1.5;
rho_y, 0.2;
theta, 0.6;
rho_a, 0.7;
rho_x, 0.5;
rho_nu, 0.4;
stderr eps_a, 0.02;
stderr eps_nu, 0.04;
stderr eps_x, 0.02;
stderr eps_e, 0.2;
end;
%identification;
estimation(datafile=observables_gali2_filt_119,mh_replic=2000,mh_nblocks=1, mode_compute=4) y_fd w_fd y;
save temp;
// options_.selected_variables_only=0;
shock_decomposition(parameter_set=posterior_mean) y y_fd;
```
The best solution seems to be making the `options_` structure local to `evaluate_smoother` (related to #1197 ) and then set `options_.selected_variables_only=0` in `shock_decomposition.m`The option `selected_variables_only` is currently incompatible with `shock_decomposition ` as can be seen in the mod-file
```
var y ${y}$ (long_name='output')
y_nat ${y^{nat}}$ (long_name='natural output')
y_gap ${\tilde y}$ (long_name='output gap')
pi ${\pi}$ (long_name='inflation')
c ${c}$ (long_name='consumption')
lam ${\lambda}$ (long_name='Lagrange multiplier')
n ${n}$ (long_name='hours worked')
w ${w}$ (long_name='real wage')
r ${r}$ (long_name='nominal interest rate')
mc ${\tau}$ (long_name='Marginal cost')
e ${e}$ (long_name='demand elasticty')
x ${x}$ (long_name='Preference shock')
a ${a}$ (long_name='AR(1) technology shock process')
nu ${\nu}$ (long_name='monetary shock process')
y_fd ${\varepsilon_e}$ (long_name='markup shock')
w_fd ${\varepsilon_e}$ (long_name='markup shock')
r_obs ${\varepsilon_e}$ (long_name='markup shock')
pi_obs ${\varepsilon_e}$ (long_name='markup shock')
;
varexo eps_a ${\varepsilon_a}$ (long_name='technology shock')
eps_nu ${\varepsilon_\nu}$ (long_name='monetary policy shock')
eps_x ${\varepsilon_x}$ (long_name='preference shock')
eps_e ${\varepsilon_e}$ (long_name='markup shock')
;
parameters
alppha ${\alpha}$ (long_name='capital share')
betta ${\beta}$ (long_name='discount factor')
h ${h}$ (long_name='Parameter habit consumption')
phi ${\phi}$ (long_name='unitary Frisch elasticity')
chix ${\chi}$ (long_name='price indexation')
rho_pi ${\phi_{\pi}}$ (long_name='inflation feedback Taylor Rule')
rho_y ${\phi_{y}}$ (long_name='output feedback Taylor Rule')
rho_r ${\phi_{y}}$ (long_name='degree of smoothing Taylor rule')
epsilon ${\epsilon}$ (long_name='steady state demand elasticity')
theta ${\theta}$ (long_name='Calvo parameter')
rho_a ${\rho_{x}}$ (long_name='autocorrelation technology shock')
rho_x ${\rho_{x}}$ (long_name='autocorrelation preference shock')
rho_nu ${\rho_{x}}$ (long_name='autocorrelation monetary shock')
;
%---------------------------------------------------------------
% Parametrization, p. 52
%---------------------------------------------------------------
alppha = 0.3;
betta = 0.99;
h = 0.7;
phi = 1;
chix = 0.6;
rho_pi = 1.5;
rho_y = 0.2;
rho_r = 0.8;
epsilon = 6;
theta = 0.6;
rho_a = 0.8;
rho_x = 0.5;
rho_nu = 0.4;
%---------------------------------------------------------------
% First Order Conditions
%---------------------------------------------------------------
model(linear);
//1. F.O.C. consumption for Households
lam*(1-(h*betta)) = x-((c-(h*c(-1)))*(1/(1-h)))-(h*betta*x(+1))+((c(+1)-(h*c))*((h*betta)/(1-h)));
//2. F.O.C. leisure for Households
phi*n=lam+w;
//3. F.O.C. bonds for Households
0=lam(+1)-lam+r-pi(+1);
//4. Average marginal cost
mc=w+(y*(alppha/(1-alppha)))-(a*(1/(1-alppha)));
//5. First auxiliary variable
pi=((betta/(1+(betta*chix)))*pi(+1))+((chix/(1+(betta*chix)))*pi(-1))+((mc-(e*(1/(epsilon-1))))*(((1-theta*betta)*(1-theta)*(1-alppha))/((1+betta*chix)*(1-alppha+alppha*epsilon)*theta)));
//8. Natural output
alppha*y_nat=a-((1-alppha)*w)+(((1-alppha)/(epsilon-1))*e);
//9. Taylor Rule
r=(r(-1)*rho_r)+((1-rho_r)*((rho_pi*pi)+(rho_y*y_gap)))+nu;
//10. Definition output gap
y_gap = y-y_nat;
//12. Equilibrium
y=c;
//13. Production function
y=(n*(1-alppha))+a;
//14. TFP shock
a=(rho_a*a(-1))+eps_a;
//15. Preference shock
x=(rho_x*x(-1))+eps_x;
//16. Markup shock
e=((1-epsilon)/epsilon)*eps_e;
//17. Monetary shock
nu=(rho_nu*nu(-1))+eps_nu;
//// Observation equations
//18. Output
y_fd = y;
//19. Wage
w_fd = w;
//20. Interes Rate
r_obs=r;
//21. Inflation
pi_obs=pi;
end;
shocks;
var eps_a= 0.02^2 ;
var eps_nu= 0.04^2;
var eps_x= 0.02^2;
var eps_e= 0.2^2;
end;
stoch_simul(order=1,periods=200,irf=0) y_fd w_fd r_obs pi_obs;
datatomfile('observables_gali2_filt_119',char('y_fd','w_fd','r_obs','pi_obs'));
varobs y_fd w_fd r_obs pi_obs;
estimated_params;
alppha, 0.3, 0, 1,beta_pdf, 0.3, 0.05;
h, 0.7, 0, 1,beta_pdf, 0.33, 0.15;
phi, 1, , ,gamma_pdf, 1.17, 0.351;
chix, 0.6, 0, 1, beta_pdf, 0.61, 0.112;
rho_pi, 1.5, 0, 10, normal_pdf, 1.5, 0.2;
rho_y, 0.2, 0, 10, normal_pdf, 0.2, 0.1;
theta, 0.6, 0, 1, beta_pdf, 0.61, 0.112;
rho_a, 0.7, 0, 1, beta_pdf, 0.61, 0.112;
rho_x, 0.5, 0, 1, beta_pdf, 0.61, 0.112;
rho_nu, 0.4, 0, 1, beta_pdf, 0.61, 0.112;
stderr eps_a, inv_gamma_pdf, 0.1, 2;
stderr eps_nu, inv_gamma_pdf, 0.1, 2;
stderr eps_x, inv_gamma_pdf, 0.1, 2;
stderr eps_e, inv_gamma_pdf, 0.1, 2;
end;
estimated_params_init;
alppha, 0.3;
h, 0.7;
phi, 1;
chix, 0.6;
rho_pi, 1.5;
rho_y, 0.2;
theta, 0.6;
rho_a, 0.7;
rho_x, 0.5;
rho_nu, 0.4;
stderr eps_a, 0.02;
stderr eps_nu, 0.04;
stderr eps_x, 0.02;
stderr eps_e, 0.2;
end;
%identification;
estimation(datafile=observables_gali2_filt_119,mh_replic=2000,mh_nblocks=1, mode_compute=4) y_fd w_fd y;
save temp;
// options_.selected_variables_only=0;
shock_decomposition(parameter_set=posterior_mean) y y_fd;
```
The best solution seems to be making the `options_` structure local to `evaluate_smoother` (related to #1197 ) and then set `options_.selected_variables_only=0` in `shock_decomposition.m`https://git.dynare.org/Dynare/dynare/issues/1344Investigate whether recent mex-changes broke backward compatibility with olde...2019-06-19T15:37:45ZJohannes Pfeifer Investigate whether recent mex-changes broke backward compatibility with older Matlab versionsGiovanni Lombardo reports a compilation error under Ubuntu with Matlab 2010a:
```
error: unknown type name ‘char16_t’
typedef char16_t mxChar;
```
(see http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=11556).
The post at http://stackoverflow.com/questions/22367516/mex-compile-error-unknown-type-name-char16-t
suggests that one might need to add
`typedef uint16_t char16_t;`
before
`#include "mex.h"`
Giovanni Lombardo reports a compilation error under Ubuntu with Matlab 2010a:
```
error: unknown type name ‘char16_t’
typedef char16_t mxChar;
```
(see http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=11556).
The post at http://stackoverflow.com/questions/22367516/mex-compile-error-unknown-type-name-char16-t
suggests that one might need to add
`typedef uint16_t char16_t;`
before
`#include "mex.h"`
https://git.dynare.org/Dynare/dynare/issues/1339bug in missing_DiffuseKalmanSmootherH3_Z.m?2019-06-19T15:37:45ZMichelJuillardbug in missing_DiffuseKalmanSmootherH3_Z.m?@JohannesPfeifer I don't see how line 302
```
Linf = eye(mm) - Kinf(:,i,t)'/Finf(i,t);
```
can be correct. The term before - is a square matrix and the term after, a row vector@JohannesPfeifer I don't see how line 302
```
Linf = eye(mm) - Kinf(:,i,t)'/Finf(i,t);
```
can be correct. The term before - is a square matrix and the term after, a row vector4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/1337A linear model with options_.risky_steadystate = 1; and k_order_solver causes...2019-06-19T15:37:45ZHoutan BastaniA linear model with options_.risky_steadystate = 1; and k_order_solver causes a crashShould stop with error if a linear model is used.
See the mod file: https://gist.github.com/houtanb/d2eaa90121e26bdace138bf477c631eeShould stop with error if a linear model is used.
See the mod file: https://gist.github.com/houtanb/d2eaa90121e26bdace138bf477c631ee4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1335add field to M_ when 2nd derivative is equal to zero2019-06-19T15:37:45ZHoutan Bastaniadd field to M_ when 2nd derivative is equal to zero4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1336make stoch_simul more efficient: solve at `order=1` when `M_.hessian_eq_zero==1`2019-06-19T15:37:45ZHoutan Bastanimake stoch_simul more efficient: solve at `order=1` when `M_.hessian_eq_zero==1`To avoid the error in `matlab/stochastic_solvers.m` line 64, when `M_.hessian_eq_zero` is true solve at `order = 1` instead of `2` or `3`.
Work to be done on a branchTo avoid the error in `matlab/stochastic_solvers.m` line 64, when `M_.hessian_eq_zero` is true solve at `order = 1` instead of `2` or `3`.
Work to be done on a branch4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1332Decide on how to deal with mh_recover on Octave2019-06-19T15:37:45ZJohannes Pfeifer Decide on how to deal with mh_recover on OctaveVarious unit test fail on Octave, because the `mh_recover` option does not work properly under Octave as there are differences in setting the random number generator. We can either
- disable the check in the unit test and accept that the behavior of `mh_recover` is different under Octave and Matlab (and then document this)
- or provide an error under Octave when someone tries to use this optionVarious unit test fail on Octave, because the `mh_recover` option does not work properly under Octave as there are differences in setting the random number generator. We can either
- disable the check in the unit test and accept that the behavior of `mh_recover` is different under Octave and Matlab (and then document this)
- or provide an error under Octave when someone tries to use this option4.5https://git.dynare.org/Dynare/dynare/issues/1328Find out why pr#1323 fails with older versions of matlab2019-06-19T15:37:45ZStéphane Adjemianstepan@dynare.orgFind out why pr#1323 fails with older versions of matlabSee the mod file [here](https://gist.github.com/stepan-a/260eabd535efa7c38d1197cad04a581a) and discussion [here](https://github.com/DynareTeam/dynare/pull/1323).See the mod file [here](https://gist.github.com/stepan-a/260eabd535efa7c38d1197cad04a581a) and discussion [here](https://github.com/DynareTeam/dynare/pull/1323).4.5Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1318Improve documentation of endogenous prior restrictions2019-06-19T15:37:47ZJohannes Pfeifer Improve documentation of endogenous prior restrictionsSee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=10433
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=10433
https://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` appropriately.
See discussion here: https://github.com/DynareTeam/dynare/commit/accd70a4c79c3e8dffb8ab367e1879680bd20606#commitcomment-19427662
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/1312Investigate problem with schur_state_space_transformation2019-06-19T15:37:47ZJohannes Pfeifer Investigate problem with schur_state_space_transformationThere is a problem with the initialization of the diffuse filter and smoother via `schur_statespace_transformation.m`. The mod-file `Local_trend_3.mod` (sent via email on 11/10/16) by a user contains three independent local trend models as in Durbin/Koopman (2012). Because the three processes are independent, all Kalman filter matrices should be block recursive. When using the Harvey initialization of the covariance `Pinf`, this is exactly what happens and results make sense. But when using the diffuse filter, in `dsge_likelihood.m` after
```
[Ztmp,Ttmp,Rtmp,QT,Pstar,Pinf]=schur_statespace_transformation(Z,T,R,Q,DynareOptions.qz_criterium,[1:length(T)]);
Pinf = QT*Pinf*QT';
Pstar = QT*Pstar*QT';
```
`Pinf` is not block diagonal anymore. Rather, there significant off-diagonal entries. This introduces a correlation between the independent local trend models that is very visible in the last graph. All observed trending variables are perfectly matched by the smoother, but the different trends interact in a way that is incompatible with the initial structure. Thus, there seems to be a problem with `schur_statespace_transformation.m`. Either there is a bug or there are numerical problems.
Weirdly, the same problem is not present when I run just two local trend models (`Local_trend_2.mod`). Here, `Pinf` is again block-recursive. So something happens when going from two to three local trend models.
There is a problem with the initialization of the diffuse filter and smoother via `schur_statespace_transformation.m`. The mod-file `Local_trend_3.mod` (sent via email on 11/10/16) by a user contains three independent local trend models as in Durbin/Koopman (2012). Because the three processes are independent, all Kalman filter matrices should be block recursive. When using the Harvey initialization of the covariance `Pinf`, this is exactly what happens and results make sense. But when using the diffuse filter, in `dsge_likelihood.m` after
```
[Ztmp,Ttmp,Rtmp,QT,Pstar,Pinf]=schur_statespace_transformation(Z,T,R,Q,DynareOptions.qz_criterium,[1:length(T)]);
Pinf = QT*Pinf*QT';
Pstar = QT*Pstar*QT';
```
`Pinf` is not block diagonal anymore. Rather, there significant off-diagonal entries. This introduces a correlation between the independent local trend models that is very visible in the last graph. All observed trending variables are perfectly matched by the smoother, but the different trends interact in a way that is incompatible with the initial structure. Thus, there seems to be a problem with `schur_statespace_transformation.m`. Either there is a bug or there are numerical problems.
Weirdly, the same problem is not present when I run just two local trend models (`Local_trend_2.mod`). Here, `Pinf` is again block-recursive. So something happens when going from two to three local trend models.
MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/1309improve documentation of datafile option2019-06-19T15:37:47ZMichelJuillardimprove documentation of datafile optionIn the manual add that if several files differ only by the extension, the filaname must include the extendsion and written between quotes
In the manual add that if several files differ only by the extension, the filaname must include the extendsion and written between quotes
4.5https://git.dynare.org/Dynare/dynare/issues/1307Provide 32 and 64 bit Octave mex-files2019-06-19T15:37:47ZJohannes Pfeifer Provide 32 and 64 bit Octave mex-filesAs indicated at http://savannah.gnu.org/bugs/index.php?49289, there will be a 64 bit version of Octave 4.2, which then also will allow to use the 64bit Dynare preprocessor (see #1306). This will hopefully also solve #1304. But this means we need to provide 64bit mex-files as well as the 32bit ones do not run.
As indicated at http://savannah.gnu.org/bugs/index.php?49289, there will be a 64 bit version of Octave 4.2, which then also will allow to use the 64bit Dynare preprocessor (see #1306). This will hopefully also solve #1304. But this means we need to provide 64bit mex-files as well as the 32bit ones do not run.
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1306Work around problem with identifying system architecture on Octave2019-06-19T15:37:47ZJohannes Pfeifer Work around problem with identifying system architecture on OctaveThe call to
`arch = getenv('PROCESSOR_ARCHITECTURE');`
used for PC in `dynare.m` does not work with Octave (see http://savannah.gnu.org/bugs/index.php?49289). Therefore, always the 32bit preprocessor is run.
The call to
`arch = getenv('PROCESSOR_ARCHITECTURE');`
used for PC in `dynare.m` does not work with Octave (see http://savannah.gnu.org/bugs/index.php?49289). Therefore, always the 32bit preprocessor is run.
https://git.dynare.org/Dynare/dynare/issues/1302calib_smoother doesn't recognize diffuse_filter2019-06-19T15:37:47ZMichelJuillardcalib_smoother doesn't recognize diffuse_filterIt should be possible to run the smoother with calibrated parameters for a model with non-stationary variables
It should be possible to run the smoother with calibrated parameters for a model with non-stationary variables
4.5MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/1300When using gnuplot on octave, most graphs titles are cut2019-06-19T15:37:47ZStéphane Adjemianstepan@dynare.orgWhen using gnuplot on octave, most graphs titles are cut*Created by: felipeboralli*
When using gnuplot on octave, most graphs titles are cut a bit.
It seems the titles are shifted upwards, because when there is a second row of graphs in the window, their titles seem to invade the upper row.
![2](https://cloud.githubusercontent.com/assets/22381123/19123477/32dd3916-8b05-11e6-8af1-172438cf9051.png)
![3](https://cloud.githubusercontent.com/assets/22381123/19123478/32de3348-8b05-11e6-958c-8d22213691d4.png)
![4](https://cloud.githubusercontent.com/assets/22381123/19123479/32e291ea-8b05-11e6-8edf-01b68f995c46.png)
*Created by: felipeboralli*
When using gnuplot on octave, most graphs titles are cut a bit.
It seems the titles are shifted upwards, because when there is a second row of graphs in the window, their titles seem to invade the upper row.
![2](https://cloud.githubusercontent.com/assets/22381123/19123477/32dd3916-8b05-11e6-8af1-172438cf9051.png)
![3](https://cloud.githubusercontent.com/assets/22381123/19123478/32de3348-8b05-11e6-958c-8d22213691d4.png)
![4](https://cloud.githubusercontent.com/assets/22381123/19123479/32e291ea-8b05-11e6-8edf-01b68f995c46.png)
https://git.dynare.org/Dynare/dynare/issues/1299The plot of recursive forecasts is wrong when prefilter=12019-06-19T15:37:47ZStéphane Adjemianstepan@dynare.orgThe plot of recursive forecasts is wrong when prefilter=1*Created by: felipeboralli*
GNU Octave, version 3.8.1 "i686-w64-mingw32".
Dynare unstable (version 2016-08-23).
When the variables are prefiltered, the plot of recursive forecast is made mixing a filtered realized variable with a defiltered forecasted variable.
In the window below, this is very visible in the juros variable, but happens in all of them.
What I woud expect is all of them to be in the defiltered mode.
![1](https://cloud.githubusercontent.com/assets/22381123/19122621/aface774-8b01-11e6-9a6e-5bc81023bd68.png)
*Created by: felipeboralli*
GNU Octave, version 3.8.1 "i686-w64-mingw32".
Dynare unstable (version 2016-08-23).
When the variables are prefiltered, the plot of recursive forecast is made mixing a filtered realized variable with a defiltered forecasted variable.
In the window below, this is very visible in the juros variable, but happens in all of them.
What I woud expect is all of them to be in the defiltered mode.
![1](https://cloud.githubusercontent.com/assets/22381123/19122621/aface774-8b01-11e6-9a6e-5bc81023bd68.png)
https://git.dynare.org/Dynare/dynare/issues/1296Decide on whether to save intermediate draws2019-06-19T15:37:47ZJohannes Pfeifer Decide on whether to save intermediate drawsWith the move to `posterior_sampling_core` we now by default save the MCMC draws every 50 draws into a temporary file, because we by default set
`posterior_sampler_options.save_tmp_file=1;`
I think this is very inefficient and therefore should be 0 by default (same behavior as before the move), with an interface provided to change the option.
@rattoma You added this behavior. Was the reason that `slice` should be treated differently?
With the move to `posterior_sampling_core` we now by default save the MCMC draws every 50 draws into a temporary file, because we by default set
`posterior_sampler_options.save_tmp_file=1;`
I think this is very inefficient and therefore should be 0 by default (same behavior as before the move), with an interface provided to change the option.
@rattoma You added this behavior. Was the reason that `slice` should be treated differently?
https://git.dynare.org/Dynare/dynare/issues/1293xlswrite and xlsopen on Octave no longer work on .xls files, only .xlsx files2019-06-19T15:37:47ZHoutan Bastanixlswrite and xlsopen on Octave no longer work on .xls files, only .xlsx filesSee: http://savannah.gnu.org/bugs/?44109
This causes `tests/data/mod1a.mod` to crash in the test suite on Octave
See: http://savannah.gnu.org/bugs/?44109
This causes `tests/data/mod1a.mod` to crash in the test suite on Octave
4.5Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1294Introduce proper check for stochastic singularity2019-06-19T15:37:47ZJohannes Pfeifer Introduce proper check for stochastic singularityIn `initial_estimation_checks` we should introduce a proper check for stochastic singularity by setting `options_.use_univariate_filters_if_singularity_is_detected=0` and then providing an informative error message when `info(1) == 50`.
This prevents user errors where the model has a fundamental stochastic singularity, because Dynare by default will resort to the univariate filter without warning.
In `initial_estimation_checks` we should introduce a proper check for stochastic singularity by setting `options_.use_univariate_filters_if_singularity_is_detected=0` and then providing an informative error message when `info(1) == 50`.
This prevents user errors where the model has a fundamental stochastic singularity, because Dynare by default will resort to the univariate filter without warning.
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/1290Provide local nograph option to shock_decomposition2019-06-19T15:37:47ZJohannes Pfeifer Provide local nograph option to shock_decompositionIt should translate `shock_decomposition(nograph)` to the last input of
`shock_decomposition(M_,oo_,options_,varlist,nograph)`
with the default being 0. Alternatively, only if the `nograph` option is specified, we call `shock_decomposition` with a fifth input. Related to #1280
It should translate `shock_decomposition(nograph)` to the last input of
`shock_decomposition(M_,oo_,options_,varlist,nograph)`
with the default being 0. Alternatively, only if the `nograph` option is specified, we call `shock_decomposition` with a fifth input. Related to #1280
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1288bug with use_dll, k_order_perturbation2019-06-19T15:37:47ZHoutan Bastanibug with use_dll, k_order_perturbationThe following tests fail:
```
| * k_order_perturbation/fs2000k2_use_dll.mod
| * k_order_perturbation/fs2000k_1_use_dll.mod
| * k_order_perturbation/fs2000k3_use_dll.mod
```
with the error:`dynare:k_order_perturbation: Caught KordDynare exception: ../../../sources/k_order_perturbation/dynamic_dll.cc:70: Error when loading ./fs2000k2_use_dll_dynamic.mexa64 (can't locate the 'Dynamic' symbol)`
We first found this on Matlab R2016a, though it may have existed earlier. This bug exists on OS X, Linux and Windows with MinGW (thanks @JohannesPfeifer ). This does not exist on Windows with MSVC.
Can possibly fix with `extern "C"` or by creating C++ mex files. Should see in which version of Matlab this problem started and why.
The following tests fail:
```
| * k_order_perturbation/fs2000k2_use_dll.mod
| * k_order_perturbation/fs2000k_1_use_dll.mod
| * k_order_perturbation/fs2000k3_use_dll.mod
```
with the error:`dynare:k_order_perturbation: Caught KordDynare exception: ../../../sources/k_order_perturbation/dynamic_dll.cc:70: Error when loading ./fs2000k2_use_dll_dynamic.mexa64 (can't locate the 'Dynamic' symbol)`
We first found this on Matlab R2016a, though it may have existed earlier. This bug exists on OS X, Linux and Windows with MinGW (thanks @JohannesPfeifer ). This does not exist on Windows with MSVC.
Can possibly fix with `extern "C"` or by creating C++ mex files. Should see in which version of Matlab this problem started and why.
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1287mex files not found by dynare_config2019-06-19T15:37:47ZHoutan Bastanimex files not found by dynare_configIn Matlab R2016b, `dynare_config` returns:
```
Configuring Dynare ...
[mex] Generalized QZ.
[mex] Sylvester equation solution.
[mex] Kronecker products.
[mex] Sparse kronecker products.
[mex] Local state space iteration (second order).
[mex] Bytecode evaluation.
[no] k-order perturbation solver.
[mex] k-order solution simulation.
[no] Quasi Monte-Carlo sequence (Sobol).
[mex] Markov Switching SBVAR.
```
Then, if you type `which k_order_perturbation; dynare_config` you get:
```
Configuring Dynare ...
[mex] Generalized QZ.
[mex] Sylvester equation solution.
[mex] Kronecker products.
[mex] Sparse kronecker products.
[mex] Local state space iteration (second order).
[mex] Bytecode evaluation.
[mex] k-order perturbation solver.
[mex] k-order solution simulation.
[mex] Quasi Monte-Carlo sequence (Sobol).
[mex] Markov Switching SBVAR.
```
Thanks to @JohannesPfeifer for pointing this out.
This problem exists on OS X, Windows, and Linux. Need to see with which version of Matlab this started
In Matlab R2016b, `dynare_config` returns:
```
Configuring Dynare ...
[mex] Generalized QZ.
[mex] Sylvester equation solution.
[mex] Kronecker products.
[mex] Sparse kronecker products.
[mex] Local state space iteration (second order).
[mex] Bytecode evaluation.
[no] k-order perturbation solver.
[mex] k-order solution simulation.
[no] Quasi Monte-Carlo sequence (Sobol).
[mex] Markov Switching SBVAR.
```
Then, if you type `which k_order_perturbation; dynare_config` you get:
```
Configuring Dynare ...
[mex] Generalized QZ.
[mex] Sylvester equation solution.
[mex] Kronecker products.
[mex] Sparse kronecker products.
[mex] Local state space iteration (second order).
[mex] Bytecode evaluation.
[mex] k-order perturbation solver.
[mex] k-order solution simulation.
[mex] Quasi Monte-Carlo sequence (Sobol).
[mex] Markov Switching SBVAR.
```
Thanks to @JohannesPfeifer for pointing this out.
This problem exists on OS X, Windows, and Linux. Need to see with which version of Matlab this started
4.5Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1286issue undeclared model variable errors at the end of model parsing2019-06-19T15:37:47ZHoutan Bastaniissue undeclared model variable errors at the end of model parsingCurrently, when a variable is in an equation but not declared, the preprocessor issues an error and stops parsing. This is a problem during model development as a user can potentially need to run dynare several times before catching all undeclared variables. To fix this, `preprocessor/ParsingDriver.cc` needs to be modified to check the existence of variables at the end of the `model` block.
Currently, when a variable is in an equation but not declared, the preprocessor issues an error and stops parsing. This is a problem during model development as a user can potentially need to run dynare several times before catching all undeclared variables. To fix this, `preprocessor/ParsingDriver.cc` needs to be modified to check the existence of variables at the end of the `model` block.
4.5Houtan BastaniHoutan Bastani