Dev October 2009

dev@dynare.org

8 participants
29 discussions

[Trac] #35: Putting "shocks" before "endval" leads to wrong results
by Trac Dynare 30 Jul '12

30 Jul '12

#35: Putting "shocks" before "endval" leads to wrong results --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: major | Milestone: 4.1 Component: Core M-files | Version: 4.0.4 Keywords: | --------------------------+------------------------------------------------- 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. -- Ticket URL: <https://www.dynare.org/trac/ticket/35> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #38: Create an entry point in bytecode interpreter for use by k-order DLL
by Trac Dynare 06 Jun '12

06 Jun '12

#38: Create an entry point in bytecode interpreter for use by k-order DLL --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: feature | Status: new Priority: major | Milestone: Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- First, support for k-order derivatives computation needs to be added to the preprocessor. Second, a storage mechanism for these needs to be added in the bytecode generation. Third, the bytecode interpreter should provide two C functions: * one for retrieving the number of non-zero elements (NNZE) in the k-order derivative (accross all equations) * one which would pass on the derivatives to the caller. Its arguments would be: * the order of derivation (k) * a (double*) vector, allocated by the caller, of length the NNZE * a (int*) matrix, of size NNZE times (k+1): the first column is the equation number, the others are the variables indices (ordered in non- decreasing order: the symmetric elements are not duplicated) -- Ticket URL: <https://www.dynare.org/trac/ticket/38> Dynare <http://www.dynare.org> The Dynare project

1 5

[Trac] #31: identification code
by Trac Dynare 29 Sep '11

29 Sep '11

#31: identification code --------------------------+------------------------------------------------- Reporter: michel | Owner: Marco Type: feature | Status: new Priority: major | Milestone: 4.2-alpha2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/31> Dynare <http://www.dynare.org> The Dynare project

1 4

[Trac] #37: Automatic generation of _steadystate.m file from initval block
by Trac Dynare 26 Jan '11

26 Jan '11

#37: Automatic generation of _steadystate.m file from initval block --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: feature | Status: new Priority: major | Milestone: Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- 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. -- Ticket URL: <https://www.dynare.org/trac/ticket/37> Dynare <http://www.dynare.org> The Dynare project

1 11

[Trac] #40: Test M_.params at the top of the main functions.
by Trac Dynare 17 Nov '10

17 Nov '10

#40: Test M_.params at the top of the main functions. --------------------------+------------------------------------------------- Reporter: stepan | Owner: Type: enhancement | Status: new Priority: major | Milestone: 4.1 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- 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). -- Ticket URL: <https://www.dynare.org/trac/ticket/40> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #45: Implement resid() with "block" option without "bytecode"
by Trac Dynare 17 Sep '10

17 Sep '10

#45: Implement resid() with "block" option without "bytecode" --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: major | Milestone: Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/45> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #46: Update examples on the website
by Trac Dynare 28 Apr '10

28 Apr '10

#46: Update examples on the website ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: Type: bug | Status: new Priority: minor | Milestone: Component: Documentation | Version: Keywords: | ---------------------------+------------------------------------------------ Most MOD files examples distributed on the website don't work with Dynare 4. They were designed for Dynare 3. We regularly get posts on the forum by newcomers to Dynare who don't understand why these examples fail. We should update them to Dynare 4. -- Ticket URL: <https://www.dynare.org/trac/ticket/46> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #32: Report MATLAB crashes on Linux/64 to Mathworks
by Trac Dynare 10 Mar '10

10 Mar '10

#32: Report MATLAB crashes on Linux/64 to Mathworks --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: major | Milestone: Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- 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. -- Ticket URL: <https://www.dynare.org/trac/ticket/32> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #44: The preprocessor can't normalize GIMF model with block+bytecode (but succeeds with only block)
by Trac Dynare 21 Dec '09

21 Dec '09

#44: The preprocessor can't normalize GIMF model with block+bytecode (but succeeds with only block) --------------------------+------------------------------------------------- Reporter: sebastien | Owner: ferhat Type: bug | Status: new Priority: major | Milestone: 4.1 Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/44> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #48: Incorrect treatment of log-linear transformation for purely backward looking models
by Trac Dynare 19 Dec '09

19 Dec '09

#48: Incorrect treatment of log-linear transformation for purely backward looking models --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: major | Milestone: 4.1 Component: Core M-files | Version: 4.0.4 Keywords: | --------------------------+------------------------------------------------- In dr1.m, log-linear test and the log-linear transformation of the model ghx and ghu matrices at line 449 are not reached for a purely backward looking model, because of a return statement at line 266 -- Ticket URL: <https://www.dynare.org/trac/ticket/48> Dynare <http://www.dynare.org> The Dynare project

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev October 2009