dynare issueshttps://git.dynare.org/Dynare/dynare/issues2013-02-21T15:08:29Zhttps://git.dynare.org/Dynare/dynare/issues/44The preprocessor segfaults on GIMF model with "block" option2013-02-21T15:08:29ZSébastien VillemotThe preprocessor segfaults on GIMF model with "block" optionAs of r3244, the preprocessor is now able to normalize the static and dynamic models (for the static model it is a singular normalization, because of the presence of unit root shocks).
But after the normalization, the preprocessor segfaults.
I can't post the MOD file here, so ask for it.
As of r3244, the preprocessor is now able to normalize the static and dynamic models (for the static model it is a singular normalization, because of the presence of unit root shocks).
But after the normalization, the preprocessor segfaults.
I can't post the MOD file here, so ask for it.
4.1https://git.dynare.org/Dynare/dynare/issues/45Implement resid() with "block" option without "bytecode"2013-02-21T15:07:52ZSébastien VillemotImplement resid() with "block" option without "bytecode"https://git.dynare.org/Dynare/dynare/issues/43bug in 2nd order approximation2013-02-21T15:08:29ZSébastien Villemotbug in 2nd order approximationChange in the order of declaration of endogenous variables affects 2nd order approximation. Bug reported by Huixin 9/21
Change in the order of declaration of endogenous variables affects 2nd order approximation. Bug reported by Huixin 9/21
4.1https://git.dynare.org/Dynare/dynare/issues/42Fix problem of order 2 with leads of two or more2013-02-21T15:08:29ZSébastien VillemotFix problem of order 2 with leads of two or moreFixed by commits r3002 and r3026.
Fixed by commits r3002 and r3026.
4.1https://git.dynare.org/Dynare/dynare/issues/40Test M_.params at the top of the main functions.2013-02-21T15:08:28ZSébastien VillemotTest M_.params at the top of the main functions.simul, stoch_simul, steady, ... should display a warning when some of the parameters are not initialized (that is when some of the elements of M_.params are NaN).
simul, stoch_simul, steady, ... should display a warning when some of the parameters are not initialized (that is when some of the elements of M_.params are NaN).
4.2https://git.dynare.org/Dynare/dynare/issues/41bug in resid.m that reset initial values when used after ENDVAL2013-02-21T15:08:28ZSébastien Villemotbug in resid.m that reset initial values when used after ENDVALresid shouldn't modify oo_ or any global variables
Maybe it should check against <fname>_static rather than <fname>_dynamic
resid shouldn't modify oo_ or any global variables
Maybe it should check against <fname>_static rather than <fname>_dynamic
4.1https://git.dynare.org/Dynare/dynare/issues/39Make warnings about unitialized params/vars optional2014-05-05T18:52:01ZSébastien VillemotMake warnings about unitialized params/vars optional4.1https://git.dynare.org/Dynare/dynare/issues/37Automatic generation of _steadystate.m file2019-12-05T15:58:38ZSébastien VillemotAutomatic generation of _steadystate.m fileThe idea is that the preprocessor would create a _steadystate.m file, using the (symbolic) initializations given in the initval block.
This would be particularly useful for estimating models for which the analytical form of the steady state is known.
The idea is that the preprocessor would create a _steadystate.m file, using the (symbolic) initializations given in the initval block.
This would be particularly useful for estimating models for which the analytical form of the steady state is known.
4.2https://git.dynare.org/Dynare/dynare/issues/38Allow k-order and estimation DLL to use bytecode for the model evaluation2016-06-10T13:10:36ZSébastien VillemotAllow k-order and estimation DLL to use bytecode for the model evaluationCurrently, k-order DLL and estimation DLL only work with use_dll option.
This constraint could be easily relieved by calling the M-file of the model from within the DLL, using mexCallMATLAB().
For the bytecode, a similar trick could be done, provided that support is added for 2nd and 3rd order derivatives.
From the implementation side, the idea would be to create an super class of DynamicModelDll.
This change needs to be documented in the reference manual when implemented.
Currently, k-order DLL and estimation DLL only work with use_dll option.
This constraint could be easily relieved by calling the M-file of the model from within the DLL, using mexCallMATLAB().
For the bytecode, a similar trick could be done, provided that support is added for 2nd and 3rd order derivatives.
From the implementation side, the idea would be to create an super class of DynamicModelDll.
This change needs to be documented in the reference manual when implemented.
https://git.dynare.org/Dynare/dynare/issues/35Putting "shocks" before "endval" leads to wrong results2014-04-08T15:53:59ZSébastien VillemotPutting "shocks" before "endval" leads to wrong resultsIn a deterministic setup with both temporary and permanent shocks, the order of the shocks and endval blocks matter. Actually, putting shocks before endval leads to wrong results.
shocks uses set_shocks.m, which fills in oo_.exo_simul; the point is that, if endval has not been used, this structure is empty, so set_shocks fills it, at date of shocks, for ''all'' the exogenous, and using the ''initial'' steady state value.
When simul is finally called, it completes oo_.exo_simul with the ''final'' exogenous steady state, but only for those periods which have no temporary shocks. So at the dates with temporary shocks, the value of exogenous which are permanently shocked is wrong.
A quick fix is to forbid the use of shocks before endval.
A cleaner fix is to modify set_shocks.m so that it only sets values for the exogenous which are temporarily shocked, and leaves NaN for other exogenous. It would be simul's job to fill in the holes.
In a deterministic setup with both temporary and permanent shocks, the order of the shocks and endval blocks matter. Actually, putting shocks before endval leads to wrong results.
shocks uses set_shocks.m, which fills in oo_.exo_simul; the point is that, if endval has not been used, this structure is empty, so set_shocks fills it, at date of shocks, for ''all'' the exogenous, and using the ''initial'' steady state value.
When simul is finally called, it completes oo_.exo_simul with the ''final'' exogenous steady state, but only for those periods which have no temporary shocks. So at the dates with temporary shocks, the value of exogenous which are permanently shocked is wrong.
A quick fix is to forbid the use of shocks before endval.
A cleaner fix is to modify set_shocks.m so that it only sets values for the exogenous which are temporarily shocked, and leaves NaN for other exogenous. It would be simul's job to fill in the holes.
https://git.dynare.org/Dynare/dynare/issues/36Write a Wiki page on the various incompatibilities accross MATLAB versions2013-02-21T15:08:28ZSébastien VillemotWrite a Wiki page on the various incompatibilities accross MATLAB versionsThis wiki page should only document changes relevant to Dynare, in particular with respect to MEX files.
All MATLAB release notes since R14 are available on:
http://www.mathworks.com/access/helpdesk/help/techdoc/
This wiki page should only document changes relevant to Dynare, in particular with respect to MEX files.
All MATLAB release notes since R14 are available on:
http://www.mathworks.com/access/helpdesk/help/techdoc/
https://git.dynare.org/Dynare/dynare/issues/34Fix the dimension of oo_.mean.2013-02-21T15:08:28ZSébastien VillemotFix the dimension of oo_.mean.Depending on the situation (simulated moments or theoretical moments) oo_.mean is a column or a row vector.
Depending on the situation (simulated moments or theoretical moments) oo_.mean is a column or a row vector.
4.1https://git.dynare.org/Dynare/dynare/issues/33Correct bug in imcforecast.2013-02-21T15:08:28ZSébastien VillemotCorrect bug in imcforecast.The call to DsgeSmoother is buggy because of the missing observation new feature.
The call to DsgeSmoother is buggy because of the missing observation new feature.
4.1https://git.dynare.org/Dynare/dynare/issues/31identification code2013-02-21T15:08:28ZSébastien Villemotidentification code4.3https://git.dynare.org/Dynare/dynare/issues/30Correct buggy mh_recover mode2013-02-21T15:08:28ZSébastien VillemotCorrect buggy mh_recover modeThe initialization of the mcmc and the number of simulations are wrong when there is only one mcmc chain.
The initialization of the mcmc and the number of simulations are wrong when there is only one mcmc chain.
4.1https://git.dynare.org/Dynare/dynare/issues/32Report MATLAB crashes on Linux/64 to Mathworks2013-02-21T15:08:28ZSébastien VillemotReport MATLAB crashes on Linux/64 to MathworksOn Linux, the 64-bits version of MATLAB crashes on some models with Dynare. The crash seems to occur with rather big models. It is reproducible, in the sense that the same code will always trigger the bug; but a small change in the code can sometimes make the crash disappear. Note that the crash is only triggered by M-files (no MEX).
See the attached "plouf.m" and "plouf_static.m". They are derived from preprocessor-generated files with the EAGLE model. The script "plouf.m" calls the function "plouf_static.m". Attached is the crash dump of MATLAB.
The crash is reproducible on MATLAB Linux/64, versions 7.5, 7.6 and 7.8. But it does not occur on MATLAB for Linux/32, Windows/32 and Windows/64.
As can be seen from the displayed marks which I have inserted, MATLAB crashes around line 131 of "plouf_static.m". More precisely, it seems to crash just after having computed the expression there. I can't understand exactly what's going on.
We need to report this to Mathworks.
On Linux, the 64-bits version of MATLAB crashes on some models with Dynare. The crash seems to occur with rather big models. It is reproducible, in the sense that the same code will always trigger the bug; but a small change in the code can sometimes make the crash disappear. Note that the crash is only triggered by M-files (no MEX).
See the attached "plouf.m" and "plouf_static.m". They are derived from preprocessor-generated files with the EAGLE model. The script "plouf.m" calls the function "plouf_static.m". Attached is the crash dump of MATLAB.
The crash is reproducible on MATLAB Linux/64, versions 7.5, 7.6 and 7.8. But it does not occur on MATLAB for Linux/32, Windows/32 and Windows/64.
As can be seen from the displayed marks which I have inserted, MATLAB crashes around line 131 of "plouf_static.m". More precisely, it seems to crash just after having computed the expression there. I can't understand exactly what's going on.
We need to report this to Mathworks.
https://git.dynare.org/Dynare/dynare/issues/28Define a syntax for bytecode generation and the various Newton solvers (for s...2013-02-21T15:08:59ZSébastien VillemotDefine a syntax for bytecode generation and the various Newton solvers (for steady and simul)4.1https://git.dynare.org/Dynare/dynare/issues/29bug with varexo_det2013-02-21T15:08:28ZSébastien Villemotbug with varexo_detSee wiki entry
See wiki entry
4.1https://git.dynare.org/Dynare/dynare/issues/26Nonlinear estimation2013-02-21T15:08:59ZSébastien VillemotNonlinear estimationhttps://git.dynare.org/Dynare/dynare/issues/27Finite element solution method2016-06-10T13:10:09ZSébastien VillemotFinite element solution methodFor the IMF.
For the IMF.