dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2013-05-31T13:09:43Zhttps://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/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/386k_order_perturbation MEX: error messages are uninformative2022-09-07T12:37:59ZMichelJuillardk_order_perturbation MEX: error messages are uninformativeThe k_order_perturbation MEX doesn't return error information similar to the ones that we have in the MATLAB code for 1st and 2nd order solution. This will create a problem if we want to use the MEX for nonlinear estimation.The k_order_perturbation MEX doesn't return error information similar to the ones that we have in the MATLAB code for 1st and 2nd order solution. This will create a problem if we want to use the MEX for nonlinear estimation.https://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/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/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/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/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/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/355Clarify treatment of max,min,sign in stochastic simulations2019-02-08T08:31:00ZJohannes PfeiferClarify treatment of max,min,sign in stochastic simulationsSee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=4531
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=4531
4.4Sébastien VillemotSébastien Villemothttps://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/353Document markowitz option of steady2013-04-11T15:23:37ZSébastien VillemotDocument markowitz option of steady4.4https://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/349Use preprocessor for variable transformation (e.g. exp for doing approximatio...2023-09-27T15:19:08ZJohannes PfeiferUse preprocessor for variable transformation (e.g. exp for doing approximation in log variables instead of level variables)An often heard request is a way to loglinearize a model instead of a linearization. Currently, the way to go is to put all variables in exp(). This is mechanic and error-prone work.
If it is easily doable, I would like to propose to use...An often heard request is a way to loglinearize a model instead of a linearization. Currently, the way to go is to put all variables in exp(). This is mechanic and error-prone work.
If it is easily doable, I would like to propose to use the preprocessor to make this substitution, similar to the predetermined_variables-command substituting the lag of the current period.
We could then add a command like
`model(loglinearize)`
to tell the preprocessor to loglinearize.
At the same time, we need a command like `non_logarithmic_variables` similar to the `predetermined_variables` command to exclude already logarithmic variables (like e.g. technology) or variables with a negative steady state. I think this is a better option than specifying explicitly which variables to substitute.
If possible, a design issue we would need to discuss is the behavior in steady state computation. I would suggest that the `model(loglinearize)` automatically triggers taking the log of the corresponding initvals so that users can enter the model in nonlinear standard form and Dynare takes care of the rest.6.xhttps://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/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/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/342Better documentation of parser error messages (line and column numbers)2013-05-31T17:28:42ZJohannes PfeiferBetter documentation of parser error messages (line and column numbers)Currently, we have error messages like this:
`ERROR: final.mod:201.1-3: syntax error, unexpected NAME`
The reason usually is that a semicolon is missing in the previous line, but people only look in the current line. If the error starts...Currently, we have error messages like this:
`ERROR: final.mod:201.1-3: syntax error, unexpected NAME`
The reason usually is that a semicolon is missing in the previous line, but people only look in the current line. If the error starts at 1, we might want to change the error message to
`ERROR: final.mod:201.1-3: syntax error, unexpected NAME. Please also check whether the previous line was terminated correctly with a semicolon.`
Houtan BastaniHoutan Bastani