Dev March 2012

dev@dynare.org

7 participants
152 discussions

[Trac] #209: check use of set_default_option()
by Trac Dynare 06 Dec '12

06 Dec '12

#209: check use of set_default_option() --------------------------+------------------------------------------------- Reporter: michel | Owner: Type: bug | Status: new Priority: major | Milestone: 4.3 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- set_default_option takes an action only if the field name doesn't exist in options_. But, now, most options have a default value set in global_initialization.m, so most of the calls to set_default_option are useless and may, sometimes, not produce the desired results. -- Ticket URL: <https://www.dynare.org/trac/ticket/209> Dynare <http://www.dynare.org> The Dynare project

1 4

[Trac] #160: Add derivatives of static model w.r.t. parameters
by Trac Dynare 29 Nov '12

29 Nov '12

#160: Add derivatives of static model w.r.t. parameters --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: enhancement | Status: new Priority: minor | Milestone: 4.3 Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- Currently, the derivatives of the static model w.r.t. parameters are computed using the derivatives of the dynamic model w.r.t. parameters. It would be more convenient to provide directly these derivatives. -- Ticket URL: <https://www.dynare.org/trac/ticket/160> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #205: add interface and documentation to model_diagnostics
by Trac Dynare 16 Nov '12

16 Nov '12

#205: add interface and documentation to model_diagnostics --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: enhancement | Status: new Priority: major | Milestone: 4.3 Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/205> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #141: Replace strmatch which is a deprecated function in Matlab
by Trac Dynare 16 Nov '12

16 Nov '12

#141: Replace strmatch which is a deprecated function in Matlab --------------------------+------------------------------------------------- Reporter: houtanb | Owner: Type: bug | Status: new Priority: major | Milestone: Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- Use strncmp instead, which has a different return type http://www.mathworks.com/help/techdoc/ref/strmatch.html -- Ticket URL: <https://www.dynare.org/trac/ticket/141> Dynare <http://www.dynare.org> The Dynare project

1 7

[Trac] #240: rewrite getPowerDeriv assignments in temporary terms
by Trac Dynare 30 Oct '12

30 Oct '12

#240: rewrite getPowerDeriv assignments in temporary terms --------------------------+------------------------------------------------- Reporter: houtanb | Owner: houtanb Type: bug | Status: new Priority: major | Milestone: 4.3 Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- 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_DERIVATIVE{x,params}; else tmp = 0; end -- Ticket URL: <https://www.dynare.org/trac/ticket/240> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #239: Add the possibility of having intermediate files elsewhere than in current directory
by Trac Dynare 30 Oct '12

30 Oct '12

#239: Add the possibility of having intermediate files elsewhere than in current directory -------------------------+-------------------------------------------------- Reporter: sebastien | Owner: Type: enhancement | Status: new Priority: major | Milestone: 5.0 Component: General | Version: Keywords: | -------------------------+-------------------------------------------------- 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. -- Ticket URL: <https://www.dynare.org/trac/ticket/239> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #230: Parallelize the testsuite
by Trac Dynare 12 Oct '12

12 Oct '12

#230: Parallelize the testsuite --------------------------------------+------------------------------------- Reporter: sebastien | Owner: sebastien Type: enhancement | Status: new Priority: major | Milestone: Component: Build system / Packaging | Version: Keywords: | --------------------------------------+------------------------------------- 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. -- Ticket URL: <https://www.dynare.org/trac/ticket/230> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #222: Crash in estimation
by Trac Dynare 08 Oct '12

08 Oct '12

#222: Crash in estimation ---------------------------------+------------------------------------------ Reporter: sebastien | Owner: ferhat Type: bug | Status: new Priority: major | Milestone: Component: Block decomposition | Version: 4.2.2 Keywords: | ---------------------------------+------------------------------------------ I attach the MOD file and data. Reported on the forum: http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=3402 -- Ticket URL: <https://www.dynare.org/trac/ticket/222> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #237: Document sbvar command
by Trac Dynare 26 Sep '12

26 Sep '12

#237: Document sbvar command ---------------------------+------------------------------------------------ Reporter: houtanb | Owner: michel Type: bug | Status: new Priority: major | Milestone: 4.3 Component: Documentation | Version: Keywords: | ---------------------------+------------------------------------------------ -- Ticket URL: <https://www.dynare.org/trac/ticket/237> Dynare <http://www.dynare.org> The Dynare project

1 2

[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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev March 2012