dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2016-05-17T11:03:52Zhttps://git.dynare.org/Dynare/dynare/-/issues/267design an interface for assigning moment/irf contraints (e.g. sign constraints)2016-05-17T11:03:52ZSébastien Villemotdesign an interface for assigning moment/irf contraints (e.g. sign constraints)Currently there is no way of setting a set of constraints to irfs or moments of DSGE model to feed to some calibration procedure like Monte Carlo filtering in the sensitivity analysis toolbox.
Indeed the threshold_redform option in sens...Currently there is no way of setting a set of constraints to irfs or moments of DSGE model to feed to some calibration procedure like Monte Carlo filtering in the sensitivity analysis toolbox.
Indeed the threshold_redform option in sensitivity analysis would only allow to set, e.g., the SAME sign constraint to a set of irfs, which is not very handy.
So, we may think to the following syntax for sign constraints in moments:
moment_calibration;
y, y(-1), +; [i.e. auto-correlation with 1 lag]
c, g(-3), +; [i.e. auto-correlation with generic lags]
i, g, -; [i.e. cross-correlation, contemporaneous]
end;
for irfs [y c i are endogenous, em eg are exogenous shocks]:
irf_calibration;
y, em, -;
c, eg, +;
i, eg, -;
end;
or the following for more detailed numeric boundaries, in principle mixed with simple sign constraints
moment_calibration;
y, y(-1), [0.5 1]; [auto-correlation with 1 lag]
c, g(-3), +; [auto-correlation with generic lags]
i, g, [-1, -0.5]; [cross-correlation, contemporaneous]
end;
irf_calibration;
y, em, [-0.01 0];
c, eg, [0 0.02];
i, eg, -;
end;
The sign constraint can also be defined using
[0 inf] for +
[-inf 0] for -
JRC-2014M3https://git.dynare.org/Dynare/dynare/-/issues/268In Dynare++, use libmatio instead of home-made routines for MAT files2013-02-21T14:55:30ZSébastien VillemotIn Dynare++, use libmatio instead of home-made routines for MAT fileshttps://git.dynare.org/Dynare/dynare/-/issues/269add dynare_version() to the manual2013-02-21T14:55:30ZSébastien Villemotadd dynare_version() to the manualhttps://git.dynare.org/Dynare/dynare/-/issues/270Determinant computation in marginal_density.m looks sub-optimal2015-08-06T13:33:30ZSébastien VillemotDeterminant computation in marginal_density.m looks sub-optimalIn marginal_density.m, the determinant is computed (at three places) using the det() function. This function is known to be less precise than a Cholesky-based determinant computation when the determinant is close to zero.
Stéphane think...In marginal_density.m, the determinant is computed (at three places) using the det() function. This function is known to be less precise than a Cholesky-based determinant computation when the determinant is close to zero.
Stéphane thinks that the Cholesky was used before, so we need to understand why this has changed, and therefore whether we can go back to the Cholesky.
Issue reported by Gilles Bélanger (Ministère des Finances du Québec)
https://git.dynare.org/Dynare/dynare/-/issues/271correct initialization of simulation variables2014-04-08T15:53:59ZSébastien Villemotcorrect initialization of simulation variables1) the current implementation process on the fly the initialization information provided by initval, endval and shocks, creating along the way oo_.endo_simul, oo_.exo_simul and oo_.exo_det_simul (information provided by histval is now co...1) the current implementation process on the fly the initialization information provided by initval, endval and shocks, creating along the way oo_.endo_simul, oo_.exo_simul and oo_.exo_det_simul (information provided by histval is now correctly stored in M_ before processing)
2) this implementation is prone to errors and forces users to respect a strict order of declaration. Simple checks of compliance with this order prevents users some legitimate usage such as macro loops
3) the solution is to record the initialization information in fields of M_ and to create/initialized oo_.endo_simul, oo_.exo_simul and oo_.exo_det_simul just before they are used.
4) set_shocks, make_y and make_ex should be rewritten and, for the last two, their name changed.
https://git.dynare.org/Dynare/dynare/-/issues/272graph_format with multiple formats2013-02-21T14:55:30ZSébastien Villemotgraph_format with multiple formatsCurrently the option graph_format only allows only one format at a time to be selected.
This can be a strong limitation (assume one wants both eps for latex and fig to handle and edit plots).
We should allow multiple entries with a prep...Currently the option graph_format only allows only one format at a time to be selected.
This can be a strong limitation (assume one wants both eps for latex and fig to handle and edit plots).
We should allow multiple entries with a preprocessor syntax
graph_format =(eps,fig)
The preprocessor would define the variable in options_ as:
options_.graph_format = char('eps', 'fig' );
which would properly be handled in dyn_saveas by changing strcmp with strmatch.
https://git.dynare.org/Dynare/dynare/-/issues/273improve the implementation of linsolve for Octave2013-02-21T14:54:08ZSébastien Villemotimprove the implementation of linsolve for OctaveCommit d32e076b77e4e8ad01d88b94b71a7c1a5763d7cd introduced a minimal implementation of linsolve for Octave. We should probably provide a better one (maybe through an Oct-file).
Commit d32e076b77e4e8ad01d88b94b71a7c1a5763d7cd introduced a minimal implementation of linsolve for Octave. We should probably provide a better one (maybe through an Oct-file).
https://git.dynare.org/Dynare/dynare/-/issues/274On Windows, nan and inf are incorrectly translated in <filename>.m2013-02-21T14:54:08ZSébastien VillemotOn Windows, nan and inf are incorrectly translated in <filename>.mUnder Windows 7 (and possibly Windows XP, need to check), the nan and inf values are respectively printed as 1.#IND and 1.#INF in the M-files generated by the preprocessor. This obviously leads to a crash.
Under Windows 7 (and possibly Windows XP, need to check), the nan and inf values are respectively printed as 1.#IND and 1.#INF in the M-files generated by the preprocessor. This obviously leads to a crash.
https://git.dynare.org/Dynare/dynare/-/issues/275Fix estimation to work with both matio 1.3 and 1.52013-02-21T14:54:08ZSébastien VillemotFix estimation to work with both matio 1.3 and 1.5Some function definitions have changed in the new matio library version.
Still need to support 1.3 because Debian takes years to update its software :)
Some function definitions have changed in the new matio library version.
Still need to support 1.3 because Debian takes years to update its software :)
https://git.dynare.org/Dynare/dynare/-/issues/276Add ar-option to estimation command2013-02-21T14:54:08ZSébastien VillemotAdd ar-option to estimation commandCurrently, the ar-option is only allowed in stoch_simul. Its value then also tranfers to the computation of moments in compute_moments_varendo.m. We should explicitly implement ar in estimation. If specified, it should also trigger the m...Currently, the ar-option is only allowed in stoch_simul. Its value then also tranfers to the computation of moments in compute_moments_varendo.m. We should explicitly implement ar in estimation. If specified, it should also trigger the moments_varendo option. This avoids setting options_.ar before the estimation command. Maybe we should split options_.ar into options_.ar for stoch_simul and options_.var_endo_ar for estimation in order for one command not to affect the computations from the other one as is currently the case.
https://git.dynare.org/Dynare/dynare/-/issues/277mex problem with Matlab 7.1 under Windows XP2013-02-21T14:54:08ZSébastien Villemotmex problem with Matlab 7.1 under Windows XPI have received the following error message
??? Invalid MEX-file 'C:\JIJI\Dynare\4.3.0\matlab..\mex\matlab\win32-7.1-7.4\mjdgges.mexw32': La procédure spécifiée est introuvable.
Windows XP
Matlab 7.1
the same problem exists with Dynare...I have received the following error message
??? Invalid MEX-file 'C:\JIJI\Dynare\4.3.0\matlab..\mex\matlab\win32-7.1-7.4\mjdgges.mexw32': La procédure spécifiée est introuvable.
Windows XP
Matlab 7.1
the same problem exists with Dynare unstable. Dynare version 4.2.4 used to work
https://git.dynare.org/Dynare/dynare/-/issues/278Improve documentation of conditional_variance_decomposition and moments2013-03-19T08:33:29ZSébastien VillemotImprove documentation of conditional_variance_decomposition and moments1. The option conditional_variance_decomposition in stoch_simul only triggers the decomposition, if theoretical moments are requested, i.e. periods=0. We should add a warning in the code and in the manual
2. Even if one specifies order=2...1. The option conditional_variance_decomposition in stoch_simul only triggers the decomposition, if theoretical moments are requested, i.e. periods=0. We should add a warning in the code and in the manual
2. Even if one specifies order=2 (with periods=0), Dynare still outputs a variance_decomposition, but the decomposition is based on the first order state-space system. We should add a warning for all second order moments as the same is true for variance, correlations, and autocorrelations
4.4https://git.dynare.org/Dynare/dynare/-/issues/279add --with-slicot and --with-matio options to configure2013-02-21T14:54:08ZSébastien Villemotadd --with-slicot and --with-matio options to configureAdd m4/ax_slicot.m4 and m4/ax_matio.m4 to conform with --with-gsl.
Add m4/ax_slicot.m4 and m4/ax_matio.m4 to conform with --with-gsl.
https://git.dynare.org/Dynare/dynare/-/issues/280Implement @#ifndef2013-02-21T14:54:08ZSébastien VillemotImplement @#ifndefhttps://git.dynare.org/Dynare/dynare/-/issues/281Fix Bug in random_walk_metropolis_hastings_core2013-02-21T14:54:08ZSébastien VillemotFix Bug in random_walk_metropolis_hastings_coreCurrently, mode_compute=0 only allows for providing a mode_file from mode_compute=6 and automatically loading optimal_mh_scale_parameter.mat from a former run of mode_compute=6.
We need to implement a more flexible version that allows fo...Currently, mode_compute=0 only allows for providing a mode_file from mode_compute=6 and automatically loading optimal_mh_scale_parameter.mat from a former run of mode_compute=6.
We need to implement a more flexible version that allows for
i) loading mode-files from other optimizers and
ii) in the case of using a mode-file from mode_compute=6 to provide a different mh_jscale than contained in the optimal_mh_scale_parameter.mat
This most probably requires changes in the preprocessor to detect if mh_jscale was specified by the user (or just set by default in global_initialization). Moreover, we need mode_compute=0 to be able to detect which optimizer created the mode-file so it knows when the file was generated by mode_compute =6 and should thus load optimal_mh_scale_parameter.mat (unless mh_jscale was explicitly specified)
Alternatively, one could force users to provide a "mh_scale_parameter_file"-option in the estimation command. In this case, Dynare will load the file if specified and otherwise use either the default or the specified mh_jscale. However, this solution would break backward-compatibility.
https://git.dynare.org/Dynare/dynare/-/issues/282change console mode so that no figures are displayed2013-02-21T14:54:08ZSébastien Villemotchange console mode so that no figures are displayedCurrently, under console mode, Dynare does not display graphical wait bars in Matlab (see http://www.dynare.org/manual/index_9.html#Dynare-invocation ). Change this Dynare not display any figures either, the way you would expect console ...Currently, under console mode, Dynare does not display graphical wait bars in Matlab (see http://www.dynare.org/manual/index_9.html#Dynare-invocation ). Change this Dynare not display any figures either, the way you would expect console mode to work.
https://git.dynare.org/Dynare/dynare/-/issues/283In Matlab, check whether nojvm or nodisplay were passed2013-02-21T14:54:08ZSébastien VillemotIn Matlab, check whether nojvm or nodisplay were passedIf nodisplay was passed, change to console mode as default
If nojvm was passed, potentially do the same or, perhaps, don't create figures at all....
If nodisplay was passed, change to console mode as default
If nojvm was passed, potentially do the same or, perhaps, don't create figures at all....
https://git.dynare.org/Dynare/dynare/-/issues/286Add treatment of missing values to manual2014-01-30T16:58:08ZSébastien VillemotAdd treatment of missing values to manualCurrently, there is no information in the manual on how missing data values are treated. See also [http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=4178]
Currently, there is no information in the manual on how missing data values are treated. See also [http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=4178]
4.5Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/287Test System: Support test we expect to fail2013-02-21T14:54:09ZSébastien VillemotTest System: Support test we expect to failShould report in a different category from regular tests: XFAIL and XPASS. XFAIL will show the tests that were expected to fail and failed. XPASS will show the tests that were expected to fail and passed.
Should report in a different category from regular tests: XFAIL and XPASS. XFAIL will show the tests that were expected to fail and failed. XPASS will show the tests that were expected to fail and passed.
https://git.dynare.org/Dynare/dynare/-/issues/288Expand information stored about model variables in preprocessor2016-06-10T12:45:14ZSébastien VillemotExpand information stored about model variables in preprocessorFrom Michel:
In the preprocessor, we need the full analysis of the dynamic structure of the model. Lists of lagged variables, forward variables, variables that are both lagged and forward, static variables.
Currently, this analysis is ...From Michel:
In the preprocessor, we need the full analysis of the dynamic structure of the model. Lists of lagged variables, forward variables, variables that are both lagged and forward, static variables.
Currently, this analysis is done in `set_state_space.m` except when `block` option is used, then @FerhatMihoubi does it in the preprocessor.
We need to think about the structure in which to store this information, so it requires a little planning.
The goal is to remove `set_state_space.m`.
4.5https://git.dynare.org/Dynare/dynare/-/issues/289make -j doesn't work in clean work directory2013-02-21T14:54:09ZSébastien Villemotmake -j doesn't work in clean work directoryfor make -j to work for dynare++, it is necessary to check that the code files and headers are ctangle BEFORE being used in compilation
for make -j to work for dynare++, it is necessary to check that the code files and headers are ctangle BEFORE being used in compilation
https://git.dynare.org/Dynare/dynare/-/issues/290Estimation+moments_varendo does not always deliver autocorrelation function2013-03-27T13:12:56ZSébastien VillemotEstimation+moments_varendo does not always deliver autocorrelation functionEven when option ar > 1, oo_.PosteriorTheoreticalMoments.mean.var1.var2 seems to be a scalar.
Even when option ar > 1, oo_.PosteriorTheoreticalMoments.mean.var1.var2 seems to be a scalar.
4.4Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/292model_diagnostics and lead/lag on exogenous variables2013-02-21T14:54:09ZSébastien Villemotmodel_diagnostics and lead/lag on exogenous variablesmodel_diagnostics breaks when there are longer lead/lag on exogenous variables than endogenous ones
model_diagnostics breaks when there are longer lead/lag on exogenous variables than endogenous ones
https://git.dynare.org/Dynare/dynare/-/issues/296add preprocessor check to report an error if the same parameter appears twice...2013-02-26T11:37:44ZSébastien Villemotadd preprocessor check to report an error if the same parameter appears twice in estimated_parameters block4.4https://git.dynare.org/Dynare/dynare/-/issues/297Dynare (stable) and Slicot packages for RHEL 62015-09-07T09:59:40ZSébastien VillemotDynare (stable) and Slicot packages for RHEL 6Request from Gianni Lombardo and Petr Man from ECB.
Request from Gianni Lombardo and Petr Man from ECB.
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/298make check: add timing information of tests2015-11-24T17:34:21ZSébastien Villemotmake check: add timing information of testsAdd information to each .trs file about how long the test took to run
In the make check summary, list the 10 tests that took the longest
Add information to each .trs file about how long the test took to run
In the make check summary, list the 10 tests that took the longest
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/299make check: automatically run tests on matlab/*.m files using internals command2014-01-28T16:57:13ZSébastien Villemotmake check: automatically run tests on matlab/*.m files using internals command- read all matlab/*.m files
- if there are tests in it, create the .m files using internals.m (need to modify)
- run these new test.m files, creating a .trs file for each one
- read all matlab/*.m files
- if there are tests in it, create the .m files using internals.m (need to modify)
- run these new test.m files, creating a .trs file for each one
https://git.dynare.org/Dynare/dynare/-/issues/301Provide a way to disable warnings2013-02-28T10:31:14ZSébastien VillemotProvide a way to disable warningsFor the moment Dynare reports many warning after preprocessing step.
Add a quiet Dynare option to avoid to printout all the warnings (IMF request for GIMF).
For the moment Dynare reports many warning after preprocessing step.
Add a quiet Dynare option to avoid to printout all the warnings (IMF request for GIMF).
4.4https://git.dynare.org/Dynare/dynare/-/issues/302dynSeries: enable excel files to be read in2013-11-12T09:14:03ZSébastien VillemotdynSeries: enable excel files to be read increate load_xls_file_data.m like load_csv_file_data.m
create load_xls_file_data.m like load_csv_file_data.m
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/303Improve Forecast Documentation2013-06-10T08:01:58ZJohannes PfeiferImprove Forecast DocumentationJudging from the number of questions relating to forecasting, the documentation is insufficient. In particular, the recursive forecasting option and the fields it creates (e.g. oo_.RecursiveForecast) are undocumented.
Judging from the number of questions relating to forecasting, the documentation is insufficient. In particular, the recursive forecasting option and the fields it creates (e.g. oo_.RecursiveForecast) are undocumented.
4.4https://git.dynare.org/Dynare/dynare/-/issues/304Add the possibility of interrupting MEX files during computation with Ctrl-C2014-10-24T14:35:57ZSébastien VillemotAdd the possibility of interrupting MEX files during computation with Ctrl-CEspecially useful for bytecode and estimation DLLs.
The natural way would be to intercept the SIGINT signal within the MEX, but this is not possible with MATLAB. Maybe this is possible under Octave, we must check.
For MATLAB, there is ...Especially useful for bytecode and estimation DLLs.
The natural way would be to intercept the SIGINT signal within the MEX, but this is not possible with MATLAB. Maybe this is possible under Octave, we must check.
For MATLAB, there is an undocumented function `utIsInterrupt()` in `libut`, which must be polled at regular intervals. This seems to be working under Windows. Need to check under GNU/Linux and MacOSX.
4.5https://git.dynare.org/Dynare/dynare/-/issues/306Add preprocessor messages (stdout, stderr) to the logfile2013-03-18T12:45:30ZSébastien VillemotAdd preprocessor messages (stdout, stderr) to the logfileCurrently these messages are not in the logfile, and can be lost if MATLAB creates too much output.
Currently these messages are not in the logfile, and can be lost if MATLAB creates too much output.
4.4Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/308add reporting routines for creating PDF reports2013-05-30T13:46:36ZSébastien Villemotadd reporting routines for creating PDF reports4.4Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/309improve automatic detrending engine2013-04-05T13:27:21ZSébastien Villemotimprove automatic detrending engineThe goal is to be able to automatically detrend the new GPM6C model.
The missing features are:
- removing additive trends (for variables expressed in logs)
- dealing with unit roots
The goal is to be able to automatically detrend the new GPM6C model.
The missing features are:
- removing additive trends (for variables expressed in logs)
- dealing with unit roots
4.4Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/310conditional forecasting within deterministic simulations2013-03-08T15:27:28ZSébastien Villemotconditional forecasting within deterministic simulationsThese are forecasts conditional to a given path for some endogenous variables in the future. This is equivalent to the "hard tunes" done by the GPM team.
For the IMF.
These are forecasts conditional to a given path for some endogenous variables in the future. This is equivalent to the "hard tunes" done by the GPM team.
For the IMF.
4.4https://git.dynare.org/Dynare/dynare/-/issues/313shock decomposition crashes after an estimation restricted to some endogenous...2013-09-18T10:05:38ZSébastien Villemotshock decomposition crashes after an estimation restricted to some endogenous variablesThe following code crashes:
```
estimation(...) y W R;
shock_decomposition y W R;
```
This is because the `shock_decomposition` command makes the assumption that all endogenous have their smoothed values in `oo_.SmoothedVariables`.
Th...The following code crashes:
```
estimation(...) y W R;
shock_decomposition y W R;
```
This is because the `shock_decomposition` command makes the assumption that all endogenous have their smoothed values in `oo_.SmoothedVariables`.
This should be fixed either by giving a more explicit error message or, better, by doing the right thing™.
4.4MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/314Should correlation field of oo_.PosteriorTheoreticalMoments be renamed to aut...2013-03-27T13:13:12ZSébastien VillemotShould correlation field of oo_.PosteriorTheoreticalMoments be renamed to autocorrelation?The current naming is confusing…
The current naming is confusing…
4.4https://git.dynare.org/Dynare/dynare/-/issues/315Saving of Metropolis Information2013-03-18T08:56:21ZJohannes PfeiferSaving of Metropolis InformationCurrently, dynare_estimation_1 calls the metropolis routines as:
`feval(options_.posterior_sampling_method,objective_function,options_.proposal_distribution,xparam1,invhess,bounds,dataset_,options_,M_,estim_params_,bayestopt_,...Currently, dynare_estimation_1 calls the metropolis routines as:
`feval(options_.posterior_sampling_method,objective_function,options_.proposal_distribution,xparam1,invhess,bounds,dataset_,options_,M_,estim_params_,bayestopt_,oo_);`
and takes no output arguments. Thus, information of the record-structure of random_walk_metropolis_hastings is not saved. We might want to store that information in the future, see http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=4462
https://git.dynare.org/Dynare/dynare/-/issues/317Terminology: Updated Variables2013-04-10T09:22:49ZJohannes PfeiferTerminology: Updated VariablesI find the term "updated variables" currently used in the figure description and the manual very nonstandard. Googling it delivered mostly Dynare results. I would suggest to rename it to the more standard "filtered variables". However, a...I find the term "updated variables" currently used in the figure description and the manual very nonstandard. Googling it delivered mostly Dynare results. I would suggest to rename it to the more standard "filtered variables". However, at the same time the variable "FilteredVariables" contains, as far as I can see it, not the filtered variables, i.e. E(y_t|t), but rather the one-step ahead forecast E(y_t+1|t) (which is also the plot title).
https://git.dynare.org/Dynare/dynare/-/issues/318Add more information about auxiliary variables to M_.aux_vars2015-07-23T14:15:41ZJohannes PfeiferAdd more information about auxiliary variables to M_.aux_varsFor auxiliary variables, the Dynare preprocessor appends the new equations after the ones provided by the user. Currently, the easiest way to see what they contain is to use the `write_latex_{static,dynamic}_model' commands. This will al...For auxiliary variables, the Dynare preprocessor appends the new equations after the ones provided by the user. Currently, the easiest way to see what they contain is to use the `write_latex_{static,dynamic}_model' commands. This will also reveal the match between auxiliary variables and what they replace. But accessing this information is rather cumbersome.
I would suggest to add the string of the substituted variable (which can already be written to TeX-code) as a field in M_.aux_vars, which together with the type stored there should be sufficient for full identification.
This would also allow for better dealing with lead variables, because an auxiliary variable can correspond to a more complex expression like E_t(x_{t+2}*y_{t+2}), which can only be replaced by a single variable (because of the expectancy operator).
https://git.dynare.org/Dynare/dynare/-/issues/320mode check2013-05-24T10:14:16ZMarco Rattomode checkI would like to allow the check plots routine to plot asymmetric plots around the mean. This would fix a couple of issues:
1) when the posterior mode goes near or at the boundary, currently the plots display the objective function for ve...I would like to allow the check plots routine to plot asymmetric plots around the mean. This would fix a couple of issues:
1) when the posterior mode goes near or at the boundary, currently the plots display the objective function for very narrow or null intervals;
2) using very large (or inf) values for mode_check_neighborhood_size, would allow to plot the objective function for the entire domain, which may possibly allow to visualize alternative local optima faraway from the current one;
https://git.dynare.org/Dynare/dynare/-/issues/321Add preprocessor option for endogenous priors2013-03-18T12:45:30ZJohannes PfeiferAdd preprocessor option for endogenous priorsRequired is a token `endogenous prior` in the `estimation` command that sets `options_.endogenous_prior` to 1
Required is a token `endogenous prior` in the `estimation` command that sets `options_.endogenous_prior` to 1
4.4Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/323Use of relative filenames creates problems in Windows in pathological cases2013-04-30T12:59:22ZJohannes PfeiferUse of relative filenames creates problems in Windows in pathological casesI have a very long pathname for one mod-file. When using a purely relative filename in check_`posterior_analysis_data.m` like
``` matlab
name_of_the_last_post_data_file = ...
[ './' M_.dname ...
'/metropolis/' ...
...I have a very long pathname for one mod-file. When using a purely relative filename in check_`posterior_analysis_data.m` like
``` matlab
name_of_the_last_post_data_file = ...
[ './' M_.dname ...
'/metropolis/' ...
M_.fname '_' ...
generic_post_data_file_name ...
int2str(number_of_the_last_post_data_file) ...
'.mat' ];
pdfdate = get_date_of_a_file(name_of_the_last_post_data_file);
```
I get an error that the file cannot be found, although it is there. Matlab's help says
> If you get unexpected results when working with long path names, use absolute instead >of relative path names.
Hence, I added a `pwd` instead of the dot to the path-name and the above code runs without problems. Is there a particular reason for using relative names?
Transitioning to absolute names using `pwd` seems more robust and is recommended by Matlab. Thus, I would suggest to use absolute path names in the future and adding a `pwd` to existing relative path names. Such a change could be done gradually without disrupting any functionality and coexistence of old and new code is also no problem.
However, I can't speak for Linux/Mac and Octave. What do you think?
https://git.dynare.org/Dynare/dynare/-/issues/330ReshapeMatFiles2016-06-14T20:57:38ZMarco RattoReshapeMatFilesReshapeMatFiles is currently used only for posterior IRF's. For large models it is a huge bottle-neck which is probably useless. The approach followed in prior_posterior_statistics.m is to use the pm3 utility that takes the data needed f...ReshapeMatFiles is currently used only for posterior IRF's. For large models it is a huge bottle-neck which is probably useless. The approach followed in prior_posterior_statistics.m is to use the pm3 utility that takes the data needed for plots from the non-reshaped files. Such a procedure is in the end much less time consuming than the ReshapeMatFile.
The current pm3 utility is not easily extended for irfs (matrices are 4-dimensional for irf's).
However I tried to write a pm4 utility for 4-D matrices which looks interesting.
How about removing the call in posteriorIRF to:
ReshapeMatFile
posteriorIRF_core2 (the plot utility for bayesian irf's which uses the reshaped files)
add making a new call to a pm4.m utility that replicates the behaviour of pm3 to 4-D matrices?
Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/-/issues/331Add reset option to shocks-block2015-09-07T10:08:50ZJohannes PfeiferAdd reset option to shocks-blockCurrently the only way to set a different covariance matrix of structural shocks and measurement errors is to manually set all elements that differ from the previous shocks-statement. It would be nice to have something like
```
shocks(r...Currently the only way to set a different covariance matrix of structural shocks and measurement errors is to manually set all elements that differ from the previous shocks-statement. It would be nice to have something like
```
shocks(reset);
var e; stderr 0.9;
end;
```
that sets all elements of the M_.Sigma_e and M_.H to 0 before filling it again with the entries of the shocks-block.
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/332Add functionality to compute function on posterior2015-10-12T05:18:33ZJohannes PfeiferAdd functionality to compute function on posteriorCurrently, it is very hard to compute a user defined function on the posterior draws. A user asked me if we could add a functionality where the user specifies a function name which is executed on each posterior draw when we compute poste...Currently, it is very hard to compute a user defined function on the posterior draws. A user asked me if we could add a functionality where the user specifies a function name which is executed on each posterior draw when we compute posterior moments. For such a function call, we would need to clearly specify the interface. We might want to provide M_, oo_, bayestopt_, estim_params_ and the current parameter draw as generic inputs (and nothing else). The tricky part consists of specifying the output arguments and making sure we can save them. One way would be to only accept one output argument and save it to the ii element of a cell array. By putting multiple outputs into a structure, the user could still effectively save multiple outputs while keeping a clearly specified interface for us.
Upon going over all draws, we would just save the cell array to the disk. It would be up to the user to make sense of the saved stuff.
4.5https://git.dynare.org/Dynare/dynare/-/issues/333Add regular expressions in @dynSeries/subsagn2013-03-28T11:31:43ZStéphane Adjemianstepan@adjemian.euAdd regular expressions in @dynSeries/subsagnWe already have the possibility to use regular expressions in @dynSeries/subsref. The code should be factorized and reused in @dynSeries/subsagn. This would allow syntax like:
ts{GROWTH_GDP_@US,JP,FR,GB@} = ts{GDP_@US,JP,FR,GB@}.ygrowth...We already have the possibility to use regular expressions in @dynSeries/subsref. The code should be factorized and reused in @dynSeries/subsagn. This would allow syntax like:
ts{GROWTH_GDP_@US,JP,FR,GB@} = ts{GDP_@US,JP,FR,GB@}.ygrowth
where ts is a dynSeries object.
4.4Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/334allow for nonzero exogenous variables in steady_state_model2013-04-05T13:24:10ZMichelJuillardallow for nonzero exogenous variables in steady_state_modelThis is necessary for using steady_state_model with deterministic models.
One possibility is add exogenous variables to the output arguments of the Matlab function. Another is to directly set oo_.exo_steady_state (and exo_det_steady_state)
This is necessary for using steady_state_model with deterministic models.
One possibility is add exogenous variables to the output arguments of the Matlab function. Another is to directly set oo_.exo_steady_state (and exo_det_steady_state)
4.4Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/335allow functions returning several values in steady_state_model2013-04-05T09:52:02ZMichelJuillardallow functions returning several values in steady_state_modelThis is necessary when one must solve more than a single equation numerically. The current syntax permits to return a variable being a vector, but there is no syntax to access a single element of this vector. An alternative would be to a...This is necessary when one must solve more than a single equation numerically. The current syntax permits to return a variable being a vector, but there is no syntax to access a single element of this vector. An alternative would be to allow a function to return a list of argument between [ ]as in Matlab syntax
4.4Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/336Add option for easy selection of all endogeneous variables and all observable...2014-02-04T13:49:11ZJohannes PfeiferAdd option for easy selection of all endogeneous variables and all observables to estimation.See http://www.dynare.org/phpBB3/viewtopic.php?f=2&t=2026&start=0
See http://www.dynare.org/phpBB3/viewtopic.php?f=2&t=2026&start=0
https://git.dynare.org/Dynare/dynare/-/issues/337Update manual section 5: The Configuration File2016-05-30T17:58:15ZJohannes PfeiferUpdate manual section 5: The Configuration FileThe manual is highly confusing and seems outdated compared to the Wiki
http://www.dynare.org/DynareWiki/ParallelDynare
For example, the configuration file is case sensitive, but the manual uses the wrong COMPUTER NAME instead of the co...The manual is highly confusing and seems outdated compared to the Wiki
http://www.dynare.org/DynareWiki/ParallelDynare
For example, the configuration file is case sensitive, but the manual uses the wrong COMPUTER NAME instead of the correct ComputerName as indicate by the Wiki. Moreover, a link to the Wiki might be helpful.
4.5Johannes PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/338Clarify and potentially disentangle role played by conf_sig2019-11-21T08:36:43ZJohannes PfeiferClarify and potentially disentangle role played by conf_sigAccording to the manual, conf_sig by default is 0.9 for forecast, but after global_initialization, it is 0.6. conditional_forecast has an option with the same name and default 0.8 according to the manual.
According to the manual, conf_sig by default is 0.9 for forecast, but after global_initialization, it is 0.6. conditional_forecast has an option with the same name and default 0.8 according to the manual.
https://git.dynare.org/Dynare/dynare/-/issues/341Block certain user-specified names in the preprocessor2015-07-27T19:51:38ZJohannes PfeiferBlock certain user-specified names in the preprocessorAllowing for a variable names like i may generate spurious crashes, particularly when used in conjunction with a steady state file as i is both the imaginary number and often the index variable of a loop.
A similar case happens when some...Allowing for a variable names like i may generate spurious crashes, particularly when used in conjunction with a steady state file as i is both the imaginary number and often the index variable of a loop.
A similar case happens when someone names his data-file data or when he uses the mod-file name for the data-file. If the datafile for bkk.mod is named bkk.xls and the user only specifies data_file=bkk, Dynare will enter an infinite loop by calling bkk.m over and over again.
https://git.dynare.org/Dynare/dynare/-/issues/346Overload numel function in dynSeries and dynDates classes2013-03-28T11:31:43ZStéphane Adjemianstepan@adjemian.euOverload numel function in dynSeries and dynDates classesIf ts is a dynSeries object then numel(ts) should return the number of variables (ts.vobs). If dd is a dynDates object then numel(dd) should return the number of dates (dd.ndat).
If ts is a dynSeries object then numel(ts) should return the number of variables (ts.vobs). If dd is a dynDates object then numel(dd) should return the number of dates (dd.ndat).
4.4Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/347Use dynSeries in Dynare.2016-06-10T12:44:33ZStéphane Adjemianstepan@adjemian.euUse dynSeries in Dynare.Use dynSeries objects for the dataset considered for estimation and for some of the outputs (IRFs, forecasts, ...) stored in oo_. See branch [use-dynSeries](https://github.com/DynareTeam/dynare/tree/use-dynSeries).
Use dynSeries objects for the dataset considered for estimation and for some of the outputs (IRFs, forecasts, ...) stored in oo_. See branch [use-dynSeries](https://github.com/DynareTeam/dynare/tree/use-dynSeries).
4.5Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/348Add the possibility to instantiate dynSeries objects from an xls file.2013-09-11T15:26:00ZStéphane Adjemianstepan@adjemian.euAdd the possibility to instantiate dynSeries objects from an xls file.This feature is necessary to replace all the existing code related to the datasets by the dynSeries class.
This feature is necessary to replace all the existing code related to the datasets by the dynSeries class.
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/351Transformation of variables for imposing terminal condition in terms of growt...2013-06-12T15:57:48ZSébastien VillemotTransformation of variables for imposing terminal condition in terms of growth ratesThe object of the task will be to define a new option for the Dynare preprocessor for deterministic simulations. The convergence of deterministic simulations is sometimes hindered by sub-optimal use of terminal conditions. Especially for...The object of the task will be to define a new option for the Dynare preprocessor for deterministic simulations. The convergence of deterministic simulations is sometimes hindered by sub-optimal use of terminal conditions. Especially for level variables and Lagrange multipliers, bad values for terminal conditions in the case of very persistent dynamics or permanent shocks can hinder correct solutions or any convergence. To this end, it will be useful to consider an option for the Dynare preprocessor that defines auxiliary forward looking variables expressed in first differences or growth rates of the actual forward looking variables defined in the model. These new variables have obvious zero terminal conditions whatever the simulation context and this in many cases helps convergence of simulations. Allowing the preprocessor to automatically define these auxiliary variables would avoid modelers to modify/edit the model for simulation purposes.
The specific objectives for the deliverables will be:
1. define the specifications and preprocessor options that trigger the definition of auxiliary forward looking variables with zero terminal conditions;
2. the default behavior of this new option will be to transform all forward looking variables in the model: a further option will be to allow the modeler to explicitly define the list of variables to be transformed. This may be useful in the case some forward looking variables in the model (like inflation in Phillips curve) have already the trivial zero terminal condition, thus reducing the number of new variables defined by the preprocessor (namely only Lagrange multipliers and level variables).
4.4Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/353Document markowitz option of steady2013-04-11T15:23:37ZSébastien VillemotDocument markowitz option of steady4.4https://git.dynare.org/Dynare/dynare/-/issues/357testsuite: modify prior for rho in fs2000XX.mod2015-08-12T07:37:39ZMichelJuillardtestsuite: modify prior for rho in fs2000XX.modThe current prior implies a vertical asymptot at 0. This becomes indeed the theoretical posterior mode. This unwanted result is now found in one case at least by mode_compute=5. More importantly, we warn users agains using such priors.
The current prior implies a vertical asymptot at 0. This becomes indeed the theoretical posterior mode. This unwanted result is now found in one case at least by mode_compute=5. More importantly, we warn users agains using such priors.
4.5MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/361Document the fact that MCMC is deterministic and what are the possible conseq...2013-12-04T09:12:12ZSébastien VillemotDocument the fact that MCMC is deterministic and what are the possible consequences of thatSee the discussion in #85
See the discussion in #85
4.4Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/362Add an option for making the stochastic draws truly pseudo-random (for exampl...2013-05-31T14:36:00ZSébastien VillemotAdd an option for making the stochastic draws truly pseudo-random (for example setting the seed with the clock)4.4Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/363Save the seed when saving the MCMC draws, and restore it with load_mh_file2014-07-02T13:25:13ZSébastien VillemotSave the seed when saving the MCMC draws, and restore it with load_mh_fileOtherwise if a user runs a mod file with load_mh_file several times in a row to retry convergence, the MAT file with the draws is modified but the proposals remain the same.
Otherwise if a user runs a mod file with load_mh_file several times in a row to retry convergence, the MAT file with the draws is modified but the proposals remain the same.
4.5Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/364Potentially make PosteriorIRF obey irf_shocks2016-03-22T15:06:04ZJohannes PfeiferPotentially make PosteriorIRF obey irf_shocksThe `irf_shocks` option of estimation restricts the generation of IRFs in `PosteriorIRF_core1`, but has no effect on `PosteriorIRF_core2` and `PosteriorIRF`, which always iterate over `M_.exo_nbr`. While this does not affect the numb...The `irf_shocks` option of estimation restricts the generation of IRFs in `PosteriorIRF_core1`, but has no effect on `PosteriorIRF_core2` and `PosteriorIRF`, which always iterate over `M_.exo_nbr`. While this does not affect the number of plots as only IRFs>10^(-6) are plotted and they were initialized to 0, there may be a computational gain in not computing posterior IRF moments for those shocks.
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/367parallel preprocessor for hybrid clusters2013-05-30T13:36:10ZMarco Rattoparallel preprocessor for hybrid clustersCurrently the pre-processor does not allow to define unix nodes from a windows master, without entering dummy entries for the drive and password fields, which could be empty for the unix machine.
I would suggest that the pre-processor ...Currently the pre-processor does not allow to define unix nodes from a windows master, without entering dummy entries for the drive and password fields, which could be empty for the unix machine.
I would suggest that the pre-processor checks for the field OperatingSystem and issue the error only
if OperatingSistem= windows
or
if OperatingSistem is empty and we are in windows environment (master is windows)
thanks
4.4Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/370Add (preprocessor) option for Fernandez-Villaverde et al (2012) type of IRFs ...2013-05-11T11:44:55ZJohannes PfeiferAdd (preprocessor) option for Fernandez-Villaverde et al (2012) type of IRFs in stoch_simulA frequent question is how to generate IRFs at order=3 that look like the ones in Fernandez-Villaverde et al (2012) "Risk matters". I will add a corresponding code over the next two weeks. But a preprocessor option would still be needed....A frequent question is how to generate IRFs at order=3 that look like the ones in Fernandez-Villaverde et al (2012) "Risk matters". I will add a corresponding code over the next two weeks. But a preprocessor option would still be needed. There are two issues that need to be discussed.
1. What should be the naming of the option? I would suggest something like `ergodic_mean_irf` as the IRFs are computed relative to the ergodic mean.
2. Should we allow for flexibility in the number of periods over which to compute the ergodic mean? If yes, we would need another option `ergodic_mean_periods`
https://git.dynare.org/Dynare/dynare/-/issues/375Support optional features of MatIO on Windows and Mac2016-06-10T12:43:17ZSébastien VillemotSupport optional features of MatIO on Windows and MacThe Windows binary currently comes with a matio compiled without zlib and HDF5, which means that it cannot read/write compressed MAT files nor 7.3 MAT-files.
The Mac binary is in the same situation.
Fixing this would first require comp...The Windows binary currently comes with a matio compiled without zlib and HDF5, which means that it cannot read/write compressed MAT files nor 7.3 MAT-files.
The Mac binary is in the same situation.
Fixing this would first require compiling static versions of zlib and HDF5 for the 2 platforms.
Then `-lhdf5 -lz` would have to be added to `LIBADD_MATIO` or, better, we could use `pkg-config` in ax_matio.m4 to detect the proper link flags (but the latter may be difficult in a cross-compiler environment).
4.5https://git.dynare.org/Dynare/dynare/-/issues/378Make estimation set the mode-file-option to empty unless specified otherwise2015-07-23T15:22:48ZJohannes PfeiferMake estimation set the mode-file-option to empty unless specified otherwiseIf a mode-file has been specified once, it will always be reloaded in all subsequent calls to estimation, thereby overwriting the MCMC results set with set_all_parameters(xparam,estim_params_,M_) and will conflict with the estimation of ...If a mode-file has been specified once, it will always be reloaded in all subsequent calls to estimation, thereby overwriting the MCMC results set with set_all_parameters(xparam,estim_params_,M_) and will conflict with the estimation of other specifications where e.g. the parameters to be estimated have changed.
The check currently always is
`isempty(options_.mode_file)`
Also, setting mode_file=[] creates an error. Thus, the only way of deleting the mode-file options currently is manually setting options_.mode_file=[];
https://git.dynare.org/Dynare/dynare/-/issues/387Decide on design of errors vs. exceptions and the use of info(2) for storing ...2013-05-03T14:05:52ZJohannes PfeiferDecide on design of errors vs. exceptions and the use of info(2) for storing informationLe jeudi 02 mai 2013 à 15:19 +0200, Michel Juillard a écrit :
When we use a Newton type numerical optimizer to find the mode of the posterior or of the likelihood or when we are searching for optimal parameters in OSR, using stiff penal...Le jeudi 02 mai 2013 à 15:19 +0200, Michel Juillard a écrit :
When we use a Newton type numerical optimizer to find the mode of the posterior or of the likelihood or when we are searching for optimal parameters in OSR, using stiff penalties creates "cliffs" that the optimizer has difficulties to overcome.
To alleviate the problem, we have tried, whenever possible, to compute penalties commensurate with the violation (sum of square residuals when one can't find the steady state, norm of eigenvalues on the "wrong" side of one for BK violations, ...). These endogenous penalties have been put in info(2). Of course, it is not always possible to compute a commensurate penalty and we still have a few cliffs.
However, we have also used info(2), in a few cases (info(1)==8) to provide additional details about the nature of the error.
I think that we should refrain from using info(2) that way and probably change the handling of the cases that do that, because it leads to confusions. But, I would like to have your advice on that.
It may be the occasion of having a more general discussion on the handling of errors in Dynare. If I remember correclty, some of you would prefer using exceptions. We could also decide that we want to redesign the handling of errors in Dynare.
https://git.dynare.org/Dynare/dynare/-/issues/389parallel option for user defined files needed by the DYNARE project2013-05-31T13:09:43ZMarco Rattoparallel option for user defined files needed by the DYNARE projectWe should allow users to declare non standard files needed to run the projects, e.g. subroutines possibly called within the _steadystate file.
In these cases, remote threads crash since the steady state cannot be run (only threads run lo...We should allow users to declare non standard files needed to run the projects, e.g. subroutines possibly called within the _steadystate file.
In these cases, remote threads crash since the steady state cannot be run (only threads run locally would work).
I have already written a fix to this in masterParallel.m which uses a new field local_files of parallel_info
options_.parallel_info.local_files
we need an interface to fill this field.
We have some options:
1)use the configuration file, but I do not think this would be a great idea since those cases are specific for individual dynare projects and not for general configurations of dynare.
2) use a new option local_files of the dynare command, triggered as follows, assuming a dynare project called mymodel.mod, where the files file1.m, file2.mat, myfolder/file3.txt in the project directory are needed by, e.g., the steady state file:
dynare mymodel parallel local_files=(file1.m)
this would trigger the following entry in options_.parallel_info:
options_.parallel_info.local_files = {'', 'file1.m'};
where the empty element indicates that the file is in the project directory and not in a subdirectory.
Another example:
dynare mymodel parallel local_files=(file1.m, file2.mat, myfolder/file3.txt)
this would trigger the following entry in options_.parallel_info (we need to parse and separate the subfolder from the name of the file)
options_.parallel_info.local_files = {
'', 'file1.m';
'', 'file2.mat';
'myfolder/', 'file3.txt'
};
3) use the option local_files inside, e.g., the estimation command:
estimation(datafile=mydata,mode_compute=0, ..., local_files=(file1.m, file2.mat, myfolder/file3.txt))
which would trigger in the same way the entry in options_.parallel_info.local_files
Which option would be best for you?
4.4Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/-/issues/390Check treatment of mh_load in MCMC Diagnostics2013-05-27T12:51:16ZJohannes PfeiferCheck treatment of mh_load in MCMC DiagnosticsSee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=4643
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=4643
https://git.dynare.org/Dynare/dynare/-/issues/1747bug in macro-processor2020-12-07T11:32:37ZMarco Rattobug in macro-processorwhen using `@#ifndef`, anything after `@#else` is never reached by macro-processor.
See attached test file [test.mod](/uploads/dac7995c3684f9b6a3a935071d05bac6/test.mod) where command in line 6 is never reached by macro-processor when t...when using `@#ifndef`, anything after `@#else` is never reached by macro-processor.
See attached test file [test.mod](/uploads/dac7995c3684f9b6a3a935071d05bac6/test.mod) where command in line 6 is never reached by macro-processor when the macro variable is defined (`@#else` works properly with `@#ifdef`, instead)5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1748bug in preprocessor for configuration file for parallel2020-11-18T14:31:45ZMarco Rattobug in preprocessor for configuration file for parallelCurrently, the preprocessor reads the `DynarePath` field in the configuration file, but it stores it into the `ProgramPath` field of `options_.parallel`. It should be ported into a `DynarePath` field, obviously.
note: `ProgramPath` woul...Currently, the preprocessor reads the `DynarePath` field in the configuration file, but it stores it into the `ProgramPath` field of `options_.parallel`. It should be ported into a `DynarePath` field, obviously.
note: `ProgramPath` would be the ultimate notation once I finish the merge with `DragonFly` ..., but for the time being the usual behaviour should be preserved.Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1749Fix testsuite for Octave2021-09-21T15:58:35ZWilli Mutschlerwilli@mutschler.euFix testsuite for OctaveOn master, some mod files do not yet run with Octave due to e.g. missing functions and other small bugs. Here is an (updated) list, when I push fixes I'll update the list:
- [x] analytic_derivatives/BrockMirman_PertParamsDerivs (on RHEL...On master, some mod files do not yet run with Octave due to e.g. missing functions and other small bugs. Here is an (updated) list, when I push fixes I'll update the list:
- [x] analytic_derivatives/BrockMirman_PertParamsDerivs (on RHEL/CentOS, but not Fedora, with KRONFLAG=-1)
- [x] estimation/method_of_moments/* (use nanmean instead of mean(x,'omitnan'; randstream not implemented in Octave;maybe other errors)
- [ ] bgp/* (many problems, probably numerical imprecision, also due to incompatibilities from and differences in toolboxes such as optim)5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1750Fix Octave mex-files on Windows2020-12-07T11:32:40ZJohannes PfeiferFix Octave mex-files on WindowsOn Windows 10 64bit with Octave 5.2 I am getting the error message
```
error: k_order_pert: could not find library or dependencies: C:\dynare\4.6.2\matlab../mex/octave/win64\k_order_perturbation.mex
```
when using `k_order_solver`. Most...On Windows 10 64bit with Octave 5.2 I am getting the error message
```
error: k_order_pert: could not find library or dependencies: C:\dynare\4.6.2\matlab../mex/octave/win64\k_order_perturbation.mex
```
when using `k_order_solver`. Most likely `libmatio` or `libwinpthread` are the culprits.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1751Fix encoding of jnl-files2020-11-20T14:54:49ZJohannes PfeiferFix encoding of jnl-filesIt seems the date/time string given by the operating system needs to be converted to UTF-8 [example1.jnl](/uploads/65e2ab3a669e03f39e16ae8dad6fcd53/example1.jnl)It seems the date/time string given by the operating system needs to be converted to UTF-8 [example1.jnl](/uploads/65e2ab3a669e03f39e16ae8dad6fcd53/example1.jnl)5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1752Fix identification error with unit root observables and diffuse_filter set2020-11-26T15:41:44ZJohannes PfeiferFix identification error with unit root observables and diffuse_filter setSee [LW_NIC.mod](/uploads/79897cc6c15966c2177cda0cbad032fc/LW_NIC.mod) where the option is correctly set, but we still ask the user to set it.See [LW_NIC.mod](/uploads/79897cc6c15966c2177cda0cbad032fc/LW_NIC.mod) where the option is correctly set, but we still ask the user to set it.5.xWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1753Build failure with clang C++ compiler (on macOS 10.15 and 11.0)2020-12-01T09:27:35ZFX CoudertBuild failure with clang C++ compiler (on macOS 10.15 and 11.0)Trying to build dynare 4.6.3 on macOS 10.15 and 11.0 fails with:
```
clang++ -std=gnu++17 -Wall -Wno-parentheses -Wold-style-cast -g -O2 -L/usr/local/opt/boost/lib -o dynare_m dynare_m-DynareFlex.o dynare_m-DynareBison.o dynare_m-Comp...Trying to build dynare 4.6.3 on macOS 10.15 and 11.0 fails with:
```
clang++ -std=gnu++17 -Wall -Wno-parentheses -Wold-style-cast -g -O2 -L/usr/local/opt/boost/lib -o dynare_m dynare_m-DynareFlex.o dynare_m-DynareBison.o dynare_m-ComputingTasks.o dynare_m-ModelTree.o dynare_m-StaticModel.o dynare_m-DynamicModel.o dynare_m-NumericalConstants.o dynare_m-NumericalInitialization.o dynare_m-Shocks.o dynare_m-SigmaeInitialization.o dynare_m-SymbolTable.o dynare_m-SymbolList.o dynare_m-ParsingDriver.o dynare_m-DataTree.o dynare_m-ModFile.o dynare_m-ConfigFile.o dynare_m-Statement.o dynare_m-ExprNode.o dynare_m-MinimumFeedbackSet.o dynare_m-DynareMain.o dynare_m-DynareMain1.o dynare_m-DynareMain2.o dynare_m-ExternalFunctionsTable.o dynare_m-ModelEquationBlock.o dynare_m-WarningConsolidation.o dynare_m-SubModel.o macro/libmacro.a -lstdc++fs
ld: library not found for -lstdc++fs
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
The C/C++ compiler is clang 12, the system compiler. The Fortran compiler is gfortran 10. We configure with:
./configure --disable-debug --disable-dependency-tracking --disable-silent-rules --prefix=/usr/local/Cellar/dynare/4.6.3 --disable-matlab --with-slicot=/private/tmp/dynare-20201123-18116-o8kpbx/dynare-4.6.3/slicot --with-boost=/usr/local/opt/boost --disable-doc
This is part of Homebrew building for distribution: https://github.com/Homebrew/homebrew-core/pull/65956https://git.dynare.org/Dynare/dynare/-/issues/1754Add model_info for non-block models2021-09-15T16:36:15ZJohannes PfeiferAdd model_info for non-block modelsSee https://forum.dynare.org/t/perfect-foresight-model-what-variables-predetermined-and-forward-looking/17028/2 for a starting point. The main issue is auxiliary variablesSee https://forum.dynare.org/t/perfect-foresight-model-what-variables-predetermined-and-forward-looking/17028/2 for a starting point. The main issue is auxiliary variables5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1755bug in variable_mapping for Ramsey optimal policy2020-12-09T17:44:43ZMichelJuillardbug in variable_mapping for Ramsey optimal policyIn the preprocessor, for a model using ramsey_model(), variableMapping is empty and in JSON file the field variable_mapping is incomplete. I attach an example generating the problem when run with
```
dynare_m cgg_ramsey.mod json=compute
...In the preprocessor, for a model using ramsey_model(), variableMapping is empty and in JSON file the field variable_mapping is incomplete. I attach an example generating the problem when run with
```
dynare_m cgg_ramsey.mod json=compute
```
[cgg_ramsey.mod](/uploads/a2f584ba20aa90e661a476ee1273a546/cgg_ramsey.mod)5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1757Fix dynare_estimation_1 for order>12021-01-25T18:34:24ZJohannes PfeiferFix dynare_estimation_1 for order>1Particle filter estimation was simply plugged into `dynare_estimation_1`. Many routines can be recycled, but we need to be more careful to check that outputs are really correct at `order>1`. For example, we will return smoother results b...Particle filter estimation was simply plugged into `dynare_estimation_1`. Many routines can be recycled, but we need to be more careful to check that outputs are really correct at `order>1`. For example, we will return smoother results based on a Kalman smoother instead of a particle smoother.5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1759Decide whether to drop Windows 7 support2021-11-16T16:29:57ZSébastien VillemotDecide whether to drop Windows 7 supportCurrently, we officially support three versions of Windows: 7, 8.1 and 10.
Mainstream support for Windows 7 expired on 2015, and extended support expired on January 2020.
Until January 2023, Microsoft still provides so-called “Extended...Currently, we officially support three versions of Windows: 7, 8.1 and 10.
Mainstream support for Windows 7 expired on 2015, and extended support expired on January 2020.
Until January 2023, Microsoft still provides so-called “Extended Security Updates”, but this requires a paid subscription (which is probably quite expensive, and thus only accessible to large institutions).
The decision to drop official Dynare support for Windows 7 therefore mostly depends on whether our institutional users have already moved away from Windows 7, or are still postponing the inevitable upgrade.
Note that dropping support for Windows 7 does not mean that Dynare would stop working on that platform (at least until we introduce some breaking change). It simply means that there would be no testing and no guarantee of functionality on that platform.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1760issue on dynare.jl repo is tracked?2021-01-05T21:22:58ZFlorian Oswaldissue on dynare.jl repo is tracked?hi all,
sorry for cross posting this here but i [left an issue](https://git.dynare.org/Dynare/Dynare.jl/-/issues/5) on the julia version repo and I'm a bit worried it won't get picked up (I had trouble finding it again myself from the D...hi all,
sorry for cross posting this here but i [left an issue](https://git.dynare.org/Dynare/Dynare.jl/-/issues/5) on the julia version repo and I'm a bit worried it won't get picked up (I had trouble finding it again myself from the Dynare.jl dashboard, so...)https://git.dynare.org/Dynare/dynare/-/issues/1761Method of Moments mode_compute 11 and 122021-01-13T14:59:36ZWilli Mutschlerwilli@mutschler.euMethod of Moments mode_compute 11 and 12In merge request !1799 I added a test mod file RBC_MoM_optimizer.mod which runs through all optimizers to check whether the call to the optimizers succeeds. For mode_compute=11 and mode_compute=12, at least for me, there is an error.In merge request !1799 I added a test mod file RBC_MoM_optimizer.mod which runs through all optimizers to check whether the call to the optimizers succeeds. For mode_compute=11 and mode_compute=12, at least for me, there is an error.5.xWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1762set_auxiliary_variables function doesn't handle exogenous variables correctly2021-01-11T14:41:53ZMichelJuillardset_auxiliary_variables function doesn't handle exogenous variables correctlyCurrently the signature of ``set_auxiliary_variables`` function is
```
y = <modname>_set_auxiliary_variables(y, x, params).
```
When there are auxiliary exogenous variables the updated value of ``x`` isn't returned.
1. return [y, x]
2. m...Currently the signature of ``set_auxiliary_variables`` function is
```
y = <modname>_set_auxiliary_variables(y, x, params).
```
When there are auxiliary exogenous variables the updated value of ``x`` isn't returned.
1. return [y, x]
2. modify existing Matlab code calling the function
3. The Julia version of the this function should modify ``y`` and ``x`` in place and not return anythinghttps://git.dynare.org/Dynare/dynare/-/issues/1763Ramsey: document potential problems with auxiliary variables for timeless per...2021-08-17T10:24:37ZJohannes PfeiferRamsey: document potential problems with auxiliary variables for timeless perspectiveSee https://forum.dynare.org/t/timing-perfect-foresight-ramsey/17157/16See https://forum.dynare.org/t/timing-perfect-foresight-ramsey/17157/165.xhttps://git.dynare.org/Dynare/dynare/-/issues/1764Document storage of decision rules at order ≥ 42021-03-12T14:00:54ZSébastien VillemotDocument storage of decision rules at order ≥ 4The reference manual documents the matrix storage of decision rules up to order 3. We should give a short description of the storage for higher order (simply the generalisation of order 3, which already uses Dynare++ storage).The reference manual documents the matrix storage of decision rules up to order 3. We should give a short description of the storage for higher order (simply the generalisation of order 3, which already uses Dynare++ storage).5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1765Decide what to do with exogenous deterministic with lead or lag2021-01-22T13:19:33ZSébastien VillemotDecide what to do with exogenous deterministic with lead or lagEndogenous with a lead/lag > 1 and exogenous with a lead/lag are now replaced by auxiliary variables in both stochastic and deterministic mode (see #1112).
However, no such transformation is performed for exogenous deterministic (`varex...Endogenous with a lead/lag > 1 and exogenous with a lead/lag are now replaced by auxiliary variables in both stochastic and deterministic mode (see #1112).
However, no such transformation is performed for exogenous deterministic (`varexo_det`) with lead/lag.
First, we should verify that the current code is not buggy when an exo det is used with a lead/lag (see also #1603).
In any case, it is probably better to homogeneize the treatment across the various types of variables. There are basically two options:
- forbid exo det with lead/lag
- perform the same substitution for those as for “regular” exogenous variables
The first option is of course easier to implement. The second option has the advantage of making things more symmetric, but it’s unclear whether it’s worth it.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1767Deal with stale fields in oo_.dr2021-01-29T14:38:54ZJohannes PfeiferDeal with stale fields in oo_.dr`resol.m` contains
```
if isfield(oo,'dr');
dr = oo.dr;
end
```
which will create problems with stale fields if the order in a mod-file decreases. It will also throw off `size_of_the_reduced_form_model``resol.m` contains
```
if isfield(oo,'dr');
dr = oo.dr;
end
```
which will create problems with stale fields if the order in a mod-file decreases. It will also throw off `size_of_the_reduced_form_model`https://git.dynare.org/Dynare/dynare/-/issues/1768Harmonize output of local_state_space_iteration_k and local_state_space_itera...2021-03-12T14:00:54ZJohannes PfeiferHarmonize output of local_state_space_iteration_k and local_state_space_iteration_2`local_state_space_iteration_k` has all endogenous variables as its output, while `local_state_space_iteration_2` has only `restrict_var_list` (i.e. drops static variables that are not observed). Nevertheless in pretty much all particle ...`local_state_space_iteration_k` has all endogenous variables as its output, while `local_state_space_iteration_2` has only `restrict_var_list` (i.e. drops static variables that are not observed). Nevertheless in pretty much all particle filters we have code like
```
if ReducedForm.use_k_order_solver
tmp = local_state_space_iteration_k(yhat, epsilon, dr, Model, DynareOptions);
else
tmp = local_state_space_iteration_2(yhat,epsilon,ghx,ghu,constant,ghxx,ghuu,ghxu,ThreadsOptions.local_state_space_iteration_2);
end
PredictionError = bsxfun(@minus,Y(:,t),tmp(mf1,:));
```
where `mf1` is the position of the observables in `restrict_var_list`. Consequently, the use of `k_order_solver` will generally return wrong result as we are reading out the wrong variables. There are two ways of fixing this:
1. Change indexing for reading out to `restrict_var_list(mf1)` in various subfunctions
2. Make the output of `local_state_space_iteration_k` and `local_state_space_iteration_2` consistent to output only `restrict_var_list`
I would prefer option 2 as it makes the code faster and we do not need to introduce additional case distinctions that make the code hard to parse.
Relatedly, `local_state_space_iteration_2` is about 60 times faster than `local_state_space_iteration_k` at the same `order=2`, see https://git.dynare.org/Dynare/dynare/-/blob/master/tests/particle/local_state_space_iteration_k_test.mod so any changes should keep this in mind.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1769Discuss merging dsge_simulated_theoretical_correlation and dsge_simulated_the...2021-07-22T16:25:02ZJohannes PfeiferDiscuss merging dsge_simulated_theoretical_correlation and dsge_simulated_theoretical_covariance`dsge_simulated_theoretical_covariance` sets `options_.ar = 0` before calling `th_autocovariances`. `dsge_simulated_theoretical_correlation` again calls `th_autocovariances` and therefore recomputes the variance. One call with `options_....`dsge_simulated_theoretical_covariance` sets `options_.ar = 0` before calling `th_autocovariances`. `dsge_simulated_theoretical_correlation` again calls `th_autocovariances` and therefore recomputes the variance. One call with `options_.nar` would suffice. This inefficiency is even more pronounced at higher order with `pruning` where we need to call `pruned_state_space_system`.
We should either
1. Merge the two functions.
2. Have `dsge_simulated_theoretical_covariance` compute and store everything and only use `dsge_simulated_theoretical_correlation` to fill the fields.5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1770Document optimizers allowing analytic_derivation and fix bugs2021-02-18T15:39:35ZJohannes PfeiferDocument optimizers allowing analytic_derivation and fix bugs- [x] The manual does not state which optimizers employ the analytic gradient. It should be at least `fmincon` (1), `csminwel` (4), `newrat` (5).
- [x] `csminwel` and `newrat` are the two optimizers not shipped with e.g. Matlab. They re...- [x] The manual does not state which optimizers employ the analytic gradient. It should be at least `fmincon` (1), `csminwel` (4), `newrat` (5).
- [x] `csminwel` and `newrat` are the two optimizers not shipped with e.g. Matlab. They rely on calls to
```[~,cost_flag,g1] = penalty_objective_function(x1,fcn,penalty,varargin{:});```
where the third output argument is the gradient. Within `penalty_objective_function` we then have
```
[fval, info, exit_flag, arg1, arg2] = fcn(x, varargin{:});
```
where the gradient `arg1` is the fourth and the Hessian `arg2` the fifth output argument of the underlying objective function. For example
```
function [fval,info,exit_flag,DLIK,Hess,SteadyState,trend_coeff,Model,DynareOptions,BayesInfo,DynareResults] = dsge_likelihood(xparam1,DynareDataset,DatasetInfo,DynareOptions,Model,EstimatedParameters,BayesInfo,BoundsInfo,DynareResults,derivatives_info)
```
This interface creates a problem for Matlab optimizers like `fmincon`, which expect the Jacobian as second and the Hessian as the third function output. Neither the underlying objective nor `penalty_objective_function` conform to this convention. The question is how to address this issue. There are two ways:
1. Add a wrapper function along the line of `penalty_objective_function`, which introduces another layer but would be quite easy to implement.
2. Change the output order of the objective function. This would be cleaner and more efficient, but would require quite massive changes in the code-base
- [x] The current implementation of `analytic_derivation` for `fmincon` in `dynare_minimize_objective` is buggy as it considers the second output `info` to be the gradient.
- [ ] It's not clear whether the treatment of the analytic Jacobian in case of the penalty approach is correct as the Jacobian does not take the penalty into account. We need to check whether these cases are filtered out via `cost_flag`5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1771preprocessor crash @#ifndef with ||2021-01-22T13:21:42ZMarco Rattopreprocessor crash @#ifndef with ||the following macro-processor syntax is obviously wrong
```
@#ifndef blabla || something
```
but preprocessor crashes without echoing an error.the following macro-processor syntax is obviously wrong
```
@#ifndef blabla || something
```
but preprocessor crashes without echoing an error.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1772Document method of moments toolbox2021-08-17T10:51:11ZSébastien VillemotDocument method of moments toolbox5.xWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1773Improve performance of local_state_space_iteration_*2022-02-01T09:54:22ZSébastien VillemotImprove performance of local_state_space_iteration_*The `local_state_space_iteration_2` MEX is much faster than `local_state_space_iteration_k` at order 2.
The solution is to fully rewrite it without using Dynare++ codebase (and by the way, do that in Fortran). This will be done via http...The `local_state_space_iteration_2` MEX is much faster than `local_state_space_iteration_k` at order 2.
The solution is to fully rewrite it without using Dynare++ codebase (and by the way, do that in Fortran). This will be done via https://git.dynare.org/Dynare/dynare/-/issues/1802
Related to #1768 and #1643.6.xhttps://git.dynare.org/Dynare/dynare/-/issues/1775Fix behavior of smoother2histval2021-09-17T16:07:34ZJohannes PfeiferFix behavior of smoother2histval- [x] The `smoother` will only store the `M_.orig_endo_nbr` variables for Bayesian estimation. So calling
`smoother2histval` will "forget" about the auxiliary variables we introduce. Thus, by convention they will be
initialized...- [x] The `smoother` will only store the `M_.orig_endo_nbr` variables for Bayesian estimation. So calling
`smoother2histval` will "forget" about the auxiliary variables we introduce. Thus, by convention they will be
initialized at their steady state - which differs from the description in the manual that it
>will use these values to construct initial conditions (as if they had been manually entered through histval).
In case of `histval`, the non-mentioned variables would be set to 0.
In contrast, for ML it will work.
- [ ] @MichelJuillard In https://git.dynare.org/Dynare/dynare/-/commit/b70d99d1b4af4e6799858902868300a246e3b492 the
code was refactored. But the treatment of lags seems inconsistent. Initialization assumes one lag via
```
M_.endo_histval = repmat(oo_.steady_state, 1, M_.maximum_lag);
```
but later we have
```
k = M_.orig_maximum_endo_lag - M_.maximum_endo_lag + 1: M_.orig_maximum_lag;
v = s((period-M_.orig_maximum_endo_lag+1):period);% + steady_state(j);
M_.endo_histval(j, :) = v(k);
```
which relies on `orig_maximum_endo_lag` and may have more than one lag. Using grep, it seems most other files
expect `M_.endo_histval` to be a vector not a matrix.
- [ ] Depending on whether output is to a file or `M_.endo_histval`, non-requested variables will be set to 0 or the steady state. We must be consistent.5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1776Consistency in variable names2023-10-25T13:56:19ZWilli Mutschlerwilli@mutschler.euConsistency in variable namesI would propose to keep the names of common input and output arguments like `M_`, `options_`, `oo_`, `estim_params_`, `bayestopt_`, `dataset_`, `dataset_info`, `estimation_info` consistent throughout the code base. For instance in `dsge_...I would propose to keep the names of common input and output arguments like `M_`, `options_`, `oo_`, `estim_params_`, `bayestopt_`, `dataset_`, `dataset_info`, `estimation_info` consistent throughout the code base. For instance in `dsge_likelihood.m`, `dsge_var_likelihood.m`, `non_linear_dsge_likelihood` or in the functions of the identification toolbox we use names like `DynareOptions`, or `options` (without underscore). So maybe, right before we release 6.x, we could make the names consistent? This would be a simple text search and replace, but everyone would then need to rebase local branches to this.
I think these are the most important variables (feel free to add to this list):
- `M_`
- `options_`
- `oo_`
- `estim_params_`
- `bayestopt_`
- `dataset_`
- `dataset_info`
- `estimation_info`6.xWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1779Fix detection of Command Line Tools in macOS installer2021-06-28T19:04:06ZSébastien VillemotFix detection of Command Line Tools in macOS installerIn some circumstances (to be determined), the Dynare installer thinks that CLT are installed, while they are not. The typical error message in this case (in `install.log`) is that `git` is not in the path.
Some instances of this:
- http...In some circumstances (to be determined), the Dynare installer thinks that CLT are installed, while they are not. The typical error message in this case (in `install.log`) is that `git` is not in the path.
Some instances of this:
- https://forum.dynare.org/t/i-can-t-download-dynare-4-6-3-in-macos/17296/
- https://forum.dynare.org/t/error-while-installing-dynare-4-6-3-mac-os-big-sur/17131/
- https://forum.dynare.org/t/problem-installing-4-6-0-on-macos-catalina/15247/20 (second poster)
- https://forum.dynare.org/t/installation-problems-of-4-6-0-on-macos/15345/20 (second poster)5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1780Compile from source on Mac M1 Apple Silicon architecture2022-01-05T08:31:39ZWilli Mutschlerwilli@mutschler.euCompile from source on Mac M1 Apple Silicon architectureI got hold of a Mac M1 and cannot compile from source following the instructions in the README.md
I will investigate this further and change the instructions accordingly.I got hold of a Mac M1 and cannot compile from source following the instructions in the README.md
I will investigate this further and change the instructions accordingly.Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1781Check correctness of optimal policy with linear model2021-05-31T13:30:20ZJohannes PfeiferCheck correctness of optimal policy with linear model`stoch_simul` locally sets
if options_.order~=1 && M_.hessian_eq_zero
options_.order = 1;
However, `M_.hessian_eq_zero` only seems to apply to the original model, not the nonlinear one resulting from e.g. `ramsey_model`.
On top o...`stoch_simul` locally sets
if options_.order~=1 && M_.hessian_eq_zero
options_.order = 1;
However, `M_.hessian_eq_zero` only seems to apply to the original model, not the nonlinear one resulting from e.g. `ramsey_model`.
On top of that, the change is local, so `evaluate_planner_objective` will crash, because it expects `order=2`.
The same will happen when declaring `model(linear)`. Note that an additional check is in `stochastic_solvers`.
An example is
[ramsey_test.mod](/uploads/452ae65f88b2dde038ab7a844ec429ed/ramsey_test.mod)5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1782Fix model_local_variable command2021-04-20T12:06:37ZJohannes PfeiferFix model_local_variable commandThe file [SW2007_4Forum.mod](/uploads/331476d7971f9497341297d7ee97f238/SW2007_4Forum.mod)
returns
`terminate called after throwing an instance of 'DataTree::UnknownLocalVariableException'`
See also https://forum.dynare.org/t/tex-output...The file [SW2007_4Forum.mod](/uploads/331476d7971f9497341297d7ee97f238/SW2007_4Forum.mod)
returns
`terminate called after throwing an instance of 'DataTree::UnknownLocalVariableException'`
See also https://forum.dynare.org/t/tex-output-unwanted-subscript-t/160725.xSébastien VillemotSébastien Villemot