Dev April 2009

dev@dynare.org

7 participants
16 discussions

model derivatives with respect to parameters
by Michel Juillard 19 Aug '09

19 Aug '09

Dear Nikolay, we have started to work on producing the derivatives with respect to parameters. We are planing to create a new function, that will return a 3-dimensional array, by equation, variable and parameter. You could then select one parameter and squeeze the array in the parameter dimension to obtain a matrix of Jacobian derivatives with respect to a given parameter. Do you see any problem with this implementation? We should be able to provide in about two weeks. All the best, Michel

4 6

Boost libraries
by Sébastien Villemot 29 Apr '09

29 Apr '09

Hi all, Concerning the Boost libraries that are now needed to recompile the preprocessor: - the 1.33 version distributed with Cygwin is too old: it doesn't contain the boost/graph/max_cardinality_matching.hpp header which is needed for model normalization. Stéphane: could you tell me which version of Boost is present in Ubuntu Intrepid (in Debian we have several possible choices: 1.34, 1.37 and 1.38). Maybe the version in Ubuntu Intrepid contains that header, in which case it should be fine - installing the boost library normally consists of simply unpacking the archive. Since Boost is mainly made of C++ headers, there is normally no need to recompile anything Best, -- Sébastien Villemot

1 1

Re: [DynareDev] reordering algorithm
by Michel Juillard 28 Apr '09

28 Apr '09

Dear George, we need to rethink the organization of dr1.m and friends: we should factorize common code, move away initialization that should take place only once and probably split 1st and second order approximation (except for k_order_perturbation.DLL). We need also to plan for resolution by block along the line developed by Ferhat. We don't need to implement all functionalities in all versions of the solver. In my opinion, k_order_perturbation should be used for regular stoch_simul and for estimation of forward looking models only. For backward models, only checking eigenvalues and mixing with deterministic shocks (varexo_det) we can rely on existing code. As long as k_order_perturbation.DLL is in testing stage, we can leave the alternative dr1.m function in korderpert subdirectoy and call it for testing with appropriate addpath command I would suggest to modify resol only when the reorganization of dr1.m has taken place. For partial information, we need to pass additional information from the preprocessor and the exact requirements of that still need to be discussed with Joe and you. All the best, Michel Quoting "G. Perendia" <george(a)perendia.orangehome.co.uk>: > Dear Michel > > 1) I am not sure we should have two version of dr1.m. My current design for > k_order (and partial info I started working on for Joe) assumes existence of > two (or more) dr1_xx.m, all called from resol.m according to the option > settings, on the line of how dr1_sparse.m is called whilst dr1.m will still > be called if check_flag == 1, i.e.: > > if(options_.model_mode==1) > [dr,info,M_,options_,oo_] = dr1_sparse(dr,check_flag,M_,options_,oo_); > elseif(options_.usePartInfo==1)&& (check_flag == 0) > [dr,info,M_,options_,oo_] = dr1_PI(dr,check_flag,M_,options_,oo_); > elseif(options_.use_k_order==1)&& (check_flag == 0) > [dr,info,M_,options_,oo_] = dr1_k_order(dr,check_flag,M_,options_,oo_); > else > [dr,info,M_,options_,oo_] = dr1(dr,check_flag,M_,options_,oo_); > end > > dr1_k_order.m is not complete dr1 and by switching the option setting in the > code (i.e. in case of any problem with the primary solver) we can make > system switch from one solver to another in a smoother, more transparent way > (like I did for AIM). > > If you agree, I will upload resol.m which has switch for dr1_k_order on the > lines of above. > > PS: The new dr1_xx.m are prototypes and I should include check inside those > alternative dr1_xxx.m later too. > > 2) Re: Extracting rules for deterministic exogenous vars > I was not suggesting of porting of deterministic exogenous vars rule to C++ > but was suggesting using the existing dr1.m Matlab code to build that rule > inside dr1_kordp.m as it is done at the moment in dr1.m. > > However, I need hessian for those rules to be calculated and I will > initially call <model>_dynamic.m/.dll to calculate it again which is > straight forward to implement and does not require much more coding. Though > slower, it is used only rarely when we have to deal with deterministic > varexos, > > At a later stage, if performance become an issue, I may retrieve the already > pre-calculated hessian from the k_ordr_perturbation.dll which would then run > faster but requires more work on C++ coding (in part due to reordering > inside DLL). > > Best regards > > George > Mob. +44(0)7951415480 > artilogica(a)btconnect.com > > ----- Original Message ----- > From: "Michel Juillard" <michel.juillard(a)ens.fr> > To: "G. Perendia" <george(a)perendia.orangehome.co.uk> > Sent: Monday, April 27, 2009 8:19 PM > Subject: Re: reordering algorithm > > > > > > Thanks George, > > > > I fixed a few bugs and renamed the function kordpert/dr1.m so we can > > just access it by adding kordpert to Matlab path > > > > I'm still not completely sure of what I have done. I still have problem > > with the DLL. For Judd example, it doesn't seem to return the right g_2 > > on my machine. > > > > Best > > > > Michel > > > > > > G. Perendia wrote: > > > Dear Michel > > > > > > Sorry, I should have given you more details rather than assumed you will > > > understand. It is giving wrong results - I think it is to do with the > > > symmetry handling in your algorithm. > > > > > > While my results for Judd model (judd_gpdr.mat) match Dynare Matlab > results, > > > yours (judd_mjdr.mat) do not. > > > > > > It is similar for the fs2000k... and portfolio_2 models - all enclosed. > > > > > > ( the enclosed <model>.mat files give you g_2) > > > > > > Best regards > > > > > > George > > > Mob. +44(0)7951415480 > > > artilogica(a)btconnect.com > > > > > > > > > > > > > > --

1 0

Re: [DynareDev] Extracting rules for deterministic exogenous vars
by Michel Juillard 27 Apr '09

27 Apr '09

Hi George, I have completely forgotten about dr.fuu, I don't see at the moment what it is useful for. Porting the varexo_det stuff to C++ isn't a priority, far from it. I would rather that you clean-up existing k_order_perturbation code. When that is done, I would like you to turn to the Kalman filter, but we will need to do a careful analysis before starting to code. One question will be which matrix implementation to use in the Kalman filter code? Shall we keep using Ondra's TwoD matrices? Shall we build our own (doubtful)? Should we use something like Boost? Best Michel G. Perendia wrote: > Dear Michel > > I was thinking of re-using some of the existing 2nd order dr1.m code to > determine dr.fuu and the rules for, if any, deterministic exogenous vars > (dr.gh??d). > > Looking at the code in dr1.m, for both dr.fuu and deterministic exogenous > vars, we need hessian and, for the former, jacobian. Shall I retrieve them > from k-order-perturbation or is there a more elegant way to get those rules > that you can think of? Perhaps we can determine fuu from ghs2 (if not 0) > more elegantly but I can not see it as yet. > > I however could not find where dr.fuu is used other than internally within > dr1.m (and dr11_sparse.m). That could mean that we only need hessian and > only infrequently when if we have deterministic exogenous vars. > > Best regards > > George > Mob. +44(0)7951415480 > artilogica(a)btconnect.com > > >

1 0

mex options for *_dynamic.c
by Michel Juillard 25 Apr '09

25 Apr '09

Following a suggestion from George, I changed the mex option LDFLAGS for *_dynamic.c to make the Dynamic function public. This was necessary as a temporary fix for kordpert. This most likely restricts the use fof USE_DLL to gcc compilers, but as nobody seems to use the option .... The ultimate solution will be to use Ferhat's bytecode solution and to dispense the users to have to use a compiler Best Michel

1 0

Dynare in Debian
by Sébastien Villemot 25 Apr '09

25 Apr '09

Hi all, The Dynare package for Debian has been uploaded to Debian servers: http://ftp-master.debian.org/new/dynare_4.0.3-1.html For the moment it is in the waiting queue for new packages. If everything goes well, it should enter unstable within a week. Best, -- Sébastien Villemot

2 1

Graphs and preprocessor
by Sébastien Villemot 23 Apr '09

23 Apr '09

Hi all, Since graph theory is becoming increasingly important in the preprocessor, Ferhat and myself have agreed on reusing a standard library for graph manipulation. A good choice seems to be the Boost Graph Library: http://www.boost.org/doc/libs/1_38_0/libs/graph/doc/index.html It is written as C++ generic headers, and is distributed under a BSD-style license (i.e. very permissive), compatible with the GPL. It contains various reusable structures for storing graphs (as adjacency list, adjacency matrix) and various algorithms (in particular strongly connected components). The whole set of Boost libraries is distributed as Debian and Cygwin packages. This leads me to another point: if we use the BGL (boost graph library), the build system of the preprocessor needs to know where the BGL headers are. Under Debian it is /usr/include, under Cygwin /usr/include/boost-1_33_1/, and it may be somewhere else for other systems (MacOS for example). So I think that we should now have a "configure" script at the top level of the Dynare directory, which would autodetect the location of the BGL, and other stuff (such as those that are currently tested for in the preprocessor Makefile). This "configure" script could also be extended to facilitate the building of MEX files from the command line (as it seems to be necessary for k-order perturbation DLL). It could even enable us to replace the build_matlab.m script by a Makefile. With a single "make" at the top-level, we could build the preprocessor, the documentation and the MEX files. The only drawback of adding this is that our build system will be tightly linked to Cygwin for Windows users, but I think that many people that recompile things on Windows already use Cygwin. Any thoughts or suggestions on the Boost Graph Library and the "configure" script ? Best, -- Sébastien Villemot

2 3

Re: [DynareDev] some news on monfispol
by Michel Juillard 20 Apr '09

20 Apr '09

Thanks Marco, the Monfispol paper look perfect. trunk/matlab/thread contains code written by Stephane for multithreaded Kronecker product DLL I imagine that your code is relying on starting multiple instances of Matlab a very different approach and use from above. So I wouldn't put your code in the same directory. For now, put it in trunk/matlab and we will move it later when we have a better view of common functions that would be logical to regroup. Best Michel Marco Ratto wrote: > Dear Michel, > > we have drafted two documents for the state-of-the-art report. We > kept them rather short, with the idea to just place MONFISPOL in the > literature, avoiding a full dissertation on the topics which would > make the report extremely long. Please have a look if they look OK to > you. > > We also have coded a generic MATLAB engine for parallelizing MATLAB > loops. I would like to begin committing it in official dynare. I > would like to know if you agree in committing those routines and > where should I commit them: in trunk\matlab? in trunk\matlab\threads. > > Concerning the new trunk\matlab\threads folder, I have a question: in > our generic engine we have to code checks (error traps) for the number > of processors actually present in the computer and so on. Do you have > already coded them or we proceed autonomously on that? > > Please let us know, > All the best > Marco >

3 10

Hessian
by G. Perendia 10 Apr '09

10 Apr '09

HI Sebastien Can you please confirm how is the 2D matrix Hessian that is coming from <model>_dynamic.c/dll created and organised (and, similarly the sparse hessian from the matlab .m version), e.g. Is it organised as a series of 2nd order jcols*jcols matrix blocks, concatenated together next to each other in order of the variables and shocks by which the 1st order was differentiated, and, all those in one of the standard Dynare orders of the variables (and in which standard order of the variables, order_var or as they are defined or....) and each block containing all of its own set of : gxx, gxu/gux and guu's, or is the hessian organised in some other order, e.g. as all gxx's stacked first (in order of variables, and which) to be followed by all of gxu's and then by all of the guu's Best regards George artilogica(a)btconnect.com

4 3

Re: [DynareDev] dynare++ with MATLAB 2009a on amd64
by Michel Juillard 10 Apr '09

10 Apr '09

Dear Ryan, Mathworks has changed types in the calling sequences of the BLAS and LAPACK library that they distribute with MATLAB v7.8 for 64 bit envirionments and that we use to link against. We will need to modify our code to reflect this change, but it will take a few weeks until we turn to it. All the best, Michel Ryan Lovett wrote: > Hello, > We are attempting to help one of our users utilize dynare_simul_ with > matlab on Linux amd64. His code worked fine with MATLAB 2007a, but not with > 2009a. > I have attached his .mod and the .jnl output. The test.mat will not run > properly as it appears dynare++ exits before finishing. > > Thanks for your time, > Ryan >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev April 2009