dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2013-02-21T14:57:07Zhttps://git.dynare.org/Dynare/dynare/-/issues/246finish ms-sbvar2013-02-21T14:57:07ZSébastien Villemotfinish ms-sbvar- Incorporate Tao's git
- in ms_estimation, return A0, A+, Zeta, Q without calling mex_ms_convert_free_parameters, which is just a copy of Dan's code (same reason we rewrote irf, forecast, vd)
- Incorporate Tao's git
- in ms_estimation, return A0, A+, Zeta, Q without calling mex_ms_convert_free_parameters, which is just a copy of Dan's code (same reason we rewrote irf, forecast, vd)
4.3https://git.dynare.org/Dynare/dynare/-/issues/247add a new option for replications in the computation of IRFs2013-02-21T14:57:00ZSébastien Villemotadd a new option for replications in the computation of IRFsCurrently options_.replic controls both the replications for IRF and for simulations. The needs are different and the defaults should be different.
When fixing this ticket attention must be paid to possible use in sensitivity toolbox.
Do...Currently options_.replic controls both the replications for IRF and for simulations. The needs are different and the defaults should be different.
When fixing this ticket attention must be paid to possible use in sensitivity toolbox.
Documentation must be clarified
4.3https://git.dynare.org/Dynare/dynare/-/issues/242Faster solvers for large scale Sylvester and Lyapunov equations2013-02-21T14:59:20ZSébastien VillemotFaster solvers for large scale Sylvester and Lyapunov equationsOn big models, a fixed point algorithm works faster for these equations that the current Dynare implementations.
These solvers need to be integrated into Dynare, with options to activate them.
On big models, a fixed point algorithm works faster for these equations that the current Dynare implementations.
These solvers need to be integrated into Dynare, with options to activate them.
4.3https://git.dynare.org/Dynare/dynare/-/issues/244Improve on the Dynare FAQ2014-01-28T16:54:11ZSébastien VillemotImprove on the Dynare FAQThere is already a FAQ on www.dynare.org, but it is outdated and incomplete.
Johannes Pfeifer has expressed interest in making a better FAQ.
It should probably become a wiki page, referenced to by a sticky post on the forum.
There is already a FAQ on www.dynare.org, but it is outdated and incomplete.
Johannes Pfeifer has expressed interest in making a better FAQ.
It should probably become a wiki page, referenced to by a sticky post on the forum.
https://git.dynare.org/Dynare/dynare/-/issues/243Publicly distribute the Dynare slides2019-09-09T12:34:39ZSébastien VillemotPublicly distribute the Dynare slidesWe already distribute the slides on the summerschool temporary website, but this is not very visible. We should probably have a more permanent location, and maybe also add them in the Dynare package.
Also, we may consider putting the La...We already distribute the slides on the summerschool temporary website, but this is not very visible. We should probably have a more permanent location, and maybe also add them in the Dynare package.
Also, we may consider putting the LaTeX source in git.
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/241Add a preprocessor option to suppress the log file2013-02-21T14:59:20ZSébastien VillemotAdd a preprocessor option to suppress the log fileThis should be an option to the "dynare" command itself, like "clearall".
Requested by Johannes Pfeifer.
May also be useful to avoid some crashes, see:
http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=3594
This should be an option to the "dynare" command itself, like "clearall".
Requested by Johannes Pfeifer.
May also be useful to avoid some crashes, see:
http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=3594
4.3https://git.dynare.org/Dynare/dynare/-/issues/239Add the possibility of having intermediate files elsewhere than in current di...2018-11-08T09:54:29ZSébastien VillemotAdd the possibility of having intermediate files elsewhere than in current directoryCurrently Dynare creates all its intermediate files (dynamic, static, ...) in the current directory.
It would be useful to have the possibility of choosing the directory where intermediate files are created.
Requested by Derek Anderson...Currently Dynare creates all its intermediate files (dynamic, static, ...) in the current directory.
It would be useful to have the possibility of choosing the directory where intermediate files are created.
Requested by Derek Anderson from IMF Modeling Unit.
https://git.dynare.org/Dynare/dynare/-/issues/240rewrite getPowerDeriv assignments in temporary terms2021-08-15T19:50:56ZSébastien Villemotrewrite getPowerDeriv assignments in temporary termsFrom Stephane:
In models with power functions of the form x**a (utility functions, production functions, agregation functions, quadratic costs, ...) the evaluation of the jacobian matrix (or higher order derivates) n...From Stephane:
In models with power functions of the form x**a (utility functions, production functions, agregation functions, quadratic costs, ...) the evaluation of the jacobian matrix (or higher order derivates) necessitate potentially a huge number of calls to the routine getPowerDeriv (the name of the routine is explicit enough). In my example (a real business cycle model with perfect foresight) most of the time is spent in this routine, while, if my understanding is correct, this is not necessary because x>0.
I wrote a mex file (see the new branch called mex-!GetPowerDeriv) as a replacement for the matlab routine, unfortunatly the overhead cost is so high that the use of the mex file increases the total time of execution!
In my case I resolved the issue by using option use_dll, but this is not a solution for the majority of our users (they would have to install cygwin/gcc and configure matlab/mex). So my question is: Do we really need to call this routine in all situations ? Would it not be possible to replace calls to this routine by something like:
if (abs(x)>1e-12)
tmp = ANALYTICAL_EXPRESSION_OF_THE_DERIVATIVEx,params;
else
tmp = 0;
end
https://git.dynare.org/Dynare/dynare/-/issues/238Add interface for convergence tolerance criterions (and maybe rename internal...2016-06-10T12:47:35ZSébastien VillemotAdd interface for convergence tolerance criterions (and maybe rename internal options)Currently we have 4 options for convergence criterions:
- options_.dynatol.f
- options_.dynatol.x
- options_.solve_tolf
- options_.solve_tolx
The first two are for the deterministic solution, the last two for the steady state.
We shoul...Currently we have 4 options for convergence criterions:
- options_.dynatol.f
- options_.dynatol.x
- options_.solve_tolf
- options_.solve_tolx
The first two are for the deterministic solution, the last two for the steady state.
We should add a preprocessor interface to these options.
Also, it would make sense to rename them for more homogeneity. I suggest the following renaming scheme:
- options_.dynatol.f => options_.simul_tolf
- options_.dynatol.x => options_.simul_tolx
- options_.solve_tolf => options_.steady_tolf
- options_.solve_tolx => options_.steady_tolx
4.5https://git.dynare.org/Dynare/dynare/-/issues/237Document sbvar command2021-08-17T11:22:57ZSébastien VillemotDocument sbvar commandMichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/236Add a user friendly frontend to simult_2015-08-06T13:27:23ZSébastien VillemotAdd a user friendly frontend to simult_The idea is to give an user-friendly way to perform simulations of a model using custom series of shocks; this is a recurring request.
The idea is to give an user-friendly way to perform simulations of a model using custom series of shocks; this is a recurring request.
4.5https://git.dynare.org/Dynare/dynare/-/issues/235passing MEXEXT to compile MEX files2013-02-21T14:59:20ZSébastien Villemotpassing MEXEXT to compile MEX filesIn Matlab, the extension name of the MEX file varies accross plateform. When we use USE_DLL and call the model file DLL in another DLL (it is the case for estimation, for example) we need to know this extension.
Currently, the Matlab cal...In Matlab, the extension name of the MEX file varies accross plateform. When we use USE_DLL and call the model file DLL in another DLL (it is the case for estimation, for example) we need to know this extension.
Currently, the Matlab calling program use mexext() to get a string and passes this string to the, say, estimation DLL. This is very roundabout, because mexext() makes a system call to evaluate a batch file to learn the name of the MEX extension of a given system.
I would prefer to know the extension name at the time of compilation of the DLL and hard code it in the DLL.
Currently, the build system already puts the extension name in environment variable MEXEXT. I suggest the following modification to the Makefile:
from
MATLAB_DEFS = -D_GNU_SOURCE -DNDEBUG -DMATLAB_VERSION=0x0713
to
MATLAB_DEFS = -DMEXEXT=$MEXEXT -D_GNU_SOURCE -DNDEBUG -DMATLAB_VERSION=0x0713
Then, we can just use macrovariable MEXEXT in the C++ code when necessary.
The same can be used for OCTAVE but I expect the name of the extension to be always the same.
4.3https://git.dynare.org/Dynare/dynare/-/issues/234add @#elseif to macroprocessor2019-08-19T15:05:51ZSébastien Villemotadd @#elseif to macroprocessorsaves users from:
if
else
if
else
endif
endif
saves users from:
if
else
if
else
endif
endif
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/232Create dummy M file for making clear some calling dependencies2014-01-28T16:52:47ZSébastien VillemotCreate dummy M file for making clear some calling dependenciesCurrently some M-functions are called from M-files using eval() instead of calling them directly.
As a result, these functions appear as orphaned in the M2HTML graph, and also do not necessarily appear when doing a grep on M-files.
The...Currently some M-functions are called from M-files using eval() instead of calling them directly.
As a result, these functions appear as orphaned in the M2HTML graph, and also do not necessarily appear when doing a grep on M-files.
The risk is that one may remove these functions, thinking they are unused.
The proposed solution is to create a dummy M-file that would directly call these functions (possibly with comments indicating the actual place of the real calls)
https://git.dynare.org/Dynare/dynare/-/issues/233Smoother on calibrated models2013-02-21T14:59:20ZSébastien VillemotSmoother on calibrated modelsAdd the possibility of running the smoother on a calibrated model.
It may be already possible to do so, by giving no estimated_params and then running estimation with mode_compute=0. If this indeed works, we need to add an interface by ...Add the possibility of running the smoother on a calibrated model.
It may be already possible to do so, by giving no estimated_params and then running estimation with mode_compute=0. If this indeed works, we need to add an interface by creating a new MOD-file command that would output the right call to estimation.
4.3https://git.dynare.org/Dynare/dynare/-/issues/231DsgeLikelihood_hh.m was removed when DsgeLikelihood.m was replaced by dsge_li...2013-02-21T14:59:20ZSébastien VillemotDsgeLikelihood_hh.m was removed when DsgeLikelihood.m was replaced by dsge_likelihood.mDsgeLikelihood_hh.m needs to be replaced by dsge_likelihood_hh.m that is needed by newrat.m and tests/fs2000/fs2000d.mod
All the Kalman filter routines needs also to return llik, the vector of loglikelihood per observation.
DsgeLikelihood_hh.m needs to be replaced by dsge_likelihood_hh.m that is needed by newrat.m and tests/fs2000/fs2000d.mod
All the Kalman filter routines needs also to return llik, the vector of loglikelihood per observation.
4.3https://git.dynare.org/Dynare/dynare/-/issues/230Parallelize the testsuite2013-02-21T14:59:20ZSébastien VillemotParallelize the testsuiteCurrently the testsuite only uses one processor.
We should paralellize it, probably using the -j option of make.
Some tests have to be run in sequential order (the 2nd test depends on the result of the 1st): those should probably lie i...Currently the testsuite only uses one processor.
We should paralellize it, probably using the -j option of make.
Some tests have to be run in sequential order (the 2nd test depends on the result of the 1st): those should probably lie in a separate list of tests which will not be (fully) parallelized.
Need to think about a way to aggregate the tests results into one report.
https://git.dynare.org/Dynare/dynare/-/issues/229update markov_switching statement2013-02-21T14:59:20ZSébastien Villemotupdate markov_switching statement- remove the regime option
- replace number_of_states with number_of_regimes
- add restrictions option
- allow duration to accept a vector of length number_of_regimes
- remove the passing of INF_CONSTANT to duration
See http://www.dynar...- remove the regime option
- replace number_of_states with number_of_regimes
- add restrictions option
- allow duration to accept a vector of length number_of_regimes
- remove the passing of INF_CONSTANT to duration
See http://www.dynare.org/DynareWiki/MarkovSwitchingInterface
4.3https://git.dynare.org/Dynare/dynare/-/issues/228document functions for which we have changed the calling sequence in unstable2013-02-21T14:59:20ZSébastien Villemotdocument functions for which we have changed the calling sequence in unstableThe changes that we have made to several functions in unstable will break the code of people who are calling these functions directly.
This will make a big mess when we release 4.3
We need to document those changes on the wiki
The changes that we have made to several functions in unstable will break the code of people who are calling these functions directly.
This will make a big mess when we release 4.3
We need to document those changes on the wiki
4.3https://git.dynare.org/Dynare/dynare/-/issues/227bug in 2nd order approximation if one variable is not present in the current ...2013-02-21T14:59:20ZSébastien Villemotbug in 2nd order approximation if one variable is not present in the current periodthis should be dealt with in the same time as #94
this should be dealt with in the same time as #94
4.3