- Dev - dynare.org

Fast steady state computation
by Sébastien Villemot 13 Jul '09

13 Jul '09

Hi everyone, I have added a new option to the "steady" command, called "block_mfs". This option does the following: * it performs a normalization and a block decomposition of the static model * then for each block it computes the minimum feedback set (MFS) of variables, in order to reduce the size of the steady-state sub-problem; in the current state of the code, variables which are not written in a normalized form (x=f(y) where x is not in y), are automatically included in the MFS The option is currently operational. Tested on EAGLE model, under Octave, it is 3 times faster than the traditional steady command. With MATLAB on Karaba, I hit a MATLAB crash which needs further investigation. The current performance bottle-neck is that we only exploit hand-written normalizations in the model. Ferhat has already added some code which tries linear transformations in order to put more equations in normalized form; I will incoporate this to the current code. Further improvements needs to be done: * adding temporary terms to the generated *_static.m file * improving the performance of the preprocessor (it is a bit slow on big models such as GIMF) I will be on vacations for about one month, but I will read my e-mail. All the best, -- Sébastien Villemot

1 0

Preprocessor and g++
by Sébastien Villemot 11 Jul '09

11 Jul '09

Hi, In my last commit, I use an extension of the C++ standard template library that is only implemented in g++ (and also in a few other compilers). Practically, that means that currently the preprocessor cannot be compiled with a compiler different from g++. Is this a problem for you? If it is, then I can provide an alternative implementation of this extension, for compilers other than g++. -- Sébastien Villemot

2 1

Re: [DynareDev] DiffuseLikelihod kalman routines
by G. Perendia 08 Jul '09

08 Jul '09

Hi Marco (et al) I uploaded the compatibility and consistency changes outlined below I made to the trunk and the branch versions of: DiffuseLikelihoodH3 DiffuseLikelihood3 DiffuseLikelihoodH3_Z DiffuseLikelihood3_Z DiffuseLikelihoodH3corr DsgeLikelihood_hh I also added lik to the output of both instances of DiffuseLikelihoodH3corr.m as it seem needed by DsgeLikelihood_hh.m and, removed the incompatible .5* in front of "lik" in the both instances of DsgeLikelihood_hh.m, i.e. llik=[-lnprior; lik(start:end)] instead llik=[-lnprior; .5*lik(start:end)] I did not however correct the call to the non-existent DiffuseLikelihoodH3corr_Z in the latest, trunk, version of DsgeLikelihood_hh.m as I am not yet fully sure of the intention. If the older versions need to be reinstated, that can be done from SVN archive (and I have kept copies too). Let me know if that is OK. Best regards George ----- Original Message ----- From: "G. Perendia" <george(a)perendia.orangehome.co.uk> To: "List for Dynare developers" <dev(a)dynare.org> Sent: Wednesday, July 08, 2009 2:30 PM Subject: Re: [DynareDev] DiffuseLikelihod kalman routines > Hi All (and Marco!) > > 1) I made and committed the changes to both the trunk and the branch > versions of DiffuseLikelihood1, H1, 1_Z and H1_Z.m routines and released > locked routines earlier today. > > 2) However, things are never so simple and the resulting chain reaction / > snowball goes on: > > Looking at the other DiffuseLikelihood* functions called within > DsgeLikilihood_hh that initially did not need the bug fix: > > DiffuseLikelihoodH3_Z > DiffuseLikelihood3_Z > DiffuseLikelihoodH3corr_Z > > The first two use inherently correct but in the context of DsgeLikilihood_hh > incompatible calculation of the lik array which contains all log(2*pi) in > the last (sample+1) element i.e. > lik(smpl+1) = smpl*pp*log(2*pi); > > so that LIK : > > LIK = .5*(sum(lik(start:end))-(start-1)*lik(smpl+1)/smpl); > > is correctly calculated within the functions but that yields probably > incorrect one for the llik returned from DsgeLikilihood_hh in its last line: > > llik=[-lnprior; .5*lik(start:end)] > > I.e. it will contain too many log(2*pi) 's when start>1. > > 3) Also, the new kalman_filter and corrected DiffuseLikelihood ones all have > > lik = (lik + pp*log(2*pi))/2 > > so the lik is already multiplied with 0.5! > and that is incompatible with the llik calculation in DsgeLikilihood_hh. > > I guess, for consistency, I should make some of the changes to the other > Diffuse functions now too, i.e. replace: > lik(smpl+1) = smpl*pp*log(2*pi); > with > lik = (lik + pp*log(2*pi))/2 > as in all other kalman_filter ones > > and , in DsgeLikilihood_hh, probably replace > > llik=[-lnprior; .5*lik(start:end)] > with > llik=[-lnprior; lik(start:end)] > > This is even more urgent since the new version of > kalman_filter.m, also called within DsgeLikilihood_hh, also pre- halves lik > array! > > 3) The third called function does not exist in the matlab directory but > DiffuseLikelihoodH3corr.m (without "_Z") does and that has the same > compatibility problem. > > Hence, DsgeLikilihood_hh also needs to be corrected to refer to an existing > function (I guess it was a typo in DsgeLikilihood_hh) and I can make that > correction too if that is OK. > > Best regards > > George > > ----- Original Message ----- > From: "G. Perendia" <george(a)perendia.orangehome.co.uk> > To: "List for Dynare developers" <dev(a)dynare.org> > Sent: Wednesday, July 08, 2009 12:24 PM > Subject: Re: [DynareDev] DiffuseLikelihod kalman routines > > > Hi > > The trunk ones are still being used by DsgeLikilihood_hh and will be needed > for 4.1 and the branch ones appear to be just their identical copies (e.g. > diff reports no differences), and so will they be fixed by mere copying - > just in case. > > If that is OK , I will lock them this afternoon and let you know when I > finish and unlock them. > > Regards > George > > > ----- Original Message ----- > From: "Michel Juillard" <michel.juillard(a)ens.fr> > To: "List for Dynare developers" <dev(a)dynare.org> > Sent: Wednesday, July 08, 2009 12:08 PM > Subject: Re: [DynareDev] DiffuseLikelihod kalman routines > > > I beg to disagree. It's not a good idea to leave bugs behind. I had > already forgotten these ones when we decided to release 4.0.4 > I don't think it is big changes either > > Best > > Michel > > Sébastien Villemot wrote: > > Le mercredi 08 juillet 2009 à 10:56 +0100, G. Perendia a écrit : > > > >> I am scheduling some bug fixing changes to both the trunk and the > >> branch DiffuseLikelihood1, H1, 1_Z and H1_Z.m routines and would like > >> to avoid any potential edit conflicts. > >> > > > > Just to mention that we have decided that there would be no more Dynare > > release in the 4.0.x. We are now focusing our energies on the next major > > release, 4.1, by the end of the summer if everything goes well. > > > > So it's not necessary to fix the 4.0 branch. > > > > Best, > > > > > > > _______________________________________________ > Dev mailing list > Dev(a)dynare.org > http://www.dynare.org/cgi-bin/mailman/listinfo/dev > > > > _______________________________________________ > Dev mailing list > Dev(a)dynare.org > http://www.dynare.org/cgi-bin/mailman/listinfo/dev >

1 0

DiffuseLikelihod kalman routines
by G. Perendia 08 Jul '09

08 Jul '09

Hi I am scheduling some bug fixing changes to both the trunk and the branch DiffuseLikelihood1, H1, 1_Z and H1_Z.m routines and would like to avoid any potential edit conflicts. Is anyone planning or doing work on those routines and is it ok to put a temporary Tortoise SVN lock on them, e.g. for today or tomorrow? Best regards George

4 6

Andrea's files
by Michel Juillard 07 Jul '09

07 Jul '09

Here are the files in a new message. Best Michel

1 0

[Fwd: Paralallel and adaptive MCMC]
by Michel Juillard 07 Jul '09

07 Jul '09

Here are Andrea's file again. I can read the PDF file on my (Windows) machine Best Michel -------- Original Message -------- Subject: Paralallel and adaptive MCMC Date: Mon, 6 Jul 2009 14:39:56 +0200 From: andrea pagano <pagano.andrea(a)gmail.com> To: Michel Juillard <Michel.Juillard(a)ens.fr> Dear Michel just before leaving for a week vacation I am sending you a short note and some rouitnes to do some adaptive and replica exchange MCMC. I have tried to use same input notation as in the metropolis code, Marco and Ivano are using in their work. There are many things to be adjusted, but maybe they can be a good starting point for this line of application. Best Andrea P.S. I have reply to Sebastien asking him top wait untill I return to give me the access to karaba. -- Andrea Pagano via Veratti VARESE tel. +3903321691261 cell.+393403804397

1 0

Compiling korderpert
by Sébastien Villemot 07 Jul '09

07 Jul '09

Hi, I'm currently working on a more elaborate build system for the various MEX files. I've tried to compile korderpert, but it fails: it complains about a missing writeMMap() method on a object coming from Dynare++. I guess that you applied some modifications to Dynare++ original source code. Maybe could you create a patch (a diff file) to be applied to the original Dynare++ code, and send it to me? (I will incoporate it into the build system). Best, -- Sébastien Villemot

3 2

[Fwd: Paralallel and adaptive MCMC]
by Michel Juillard 07 Jul '09

07 Jul '09

Here is a contribution of Andrea on MCMC Best, Michel -------- Original Message -------- Subject: Paralallel and adaptive MCMC Date: Mon, 6 Jul 2009 14:39:56 +0200 From: andrea pagano <pagano.andrea(a)gmail.com> To: Michel Juillard <Michel.Juillard(a)ens.fr> Dear Michel just before leaving for a week vacation I am sending you a short note and some rouitnes to do some adaptive and replica exchange MCMC. I have tried to use same input notation as in the metropolis code, Marco and Ivano are using in their work. There are many things to be adjusted, but maybe they can be a good starting point for this line of application. Best Andrea P.S. I have reply to Sebastien asking him top wait untill I return to give me the access to karaba. -- Andrea Pagano via Veratti VARESE tel. +3903321691261 cell.+393403804397

1 0

C++ Kalman filter
by Michel Juillard 06 Jul '09

06 Jul '09

Dear Andrea and George, than you for your efforts on the Kalman filter. I would like to regroup efforts along the following lines: 1) Kalman filter C++: I would still like to be able to compare with an implementation that removes all object instantiation inside the loop: the lowest level object should be Kalman filter and all necessary work space should be allocated once for ever outside the main loop of the filter. The multiplications should be done using optimized Lapack DGEM. George should continue along this line. I'm suspicious of timings taken in Windows and we should double check them under Linux. For this reason as well, Makefile should also provide for building of tests under Linux. George and Andrea should have accounts on karaba. Sebastien, can you take care of that? 2) Unless I'm missing something, there are only two explanations for not being able to beat DGEMM a) our compilers don't optimize as well as the one used by Matlab b) there is a problem in the algorithm. In order to eliminate and be able to quantify the importance of (a), I would like Andrea to write a standalone test for both operations: - A*x - A*P*A' calling DGEMM (from Matlab's Lapack library) and compare it with his own routines. A minimum modification would be to take DGEMM as it is and modify the loops so as to accomodate a quasi-triangular matrix instead of a general matrix. In this exercise, all lower level BLAS functions should be linked with Matlab's BLAS library. We will make a new attempt to integrate Andrea's routines in the Kalman filter only when we obtain satisfactory standalone test results. I think it is important to spend more time on these tests, because we are evaluating how much speed improvement we can expect from using compiled code instead of Matlab. All the best, Michel

4 4

Re: [DynareDev] Fw: 2nd and 3rd model derivatives + k-order
by Sébastien Villemot 01 Jul '09

01 Jul '09

"G. Perendia" <george(a)perendia.orangehome.co.uk> a écrit : > What is the expected preprocessor mechanism to allow for k-ord-pert to be > used (i.e. by setting matlab/kordpert directory on the top of search path) > and when is it expected to be in place? > > If there is none in place yet, what would be the best place (i.e. which .m > file) to set path to kordpert/dr.1 when > options_.use_k_order=1; > is specified in the mod file, e.g. as per my earlier message below? I don't think it is good practice to override matlab/dr1.m with matlab/kordpert/dr1.m through path manipulations. I would rather dynamically select which version of dr1 to use. For example, dr1.m would be a dispatcher between the original dr1.m and the korder dr1.m (and possibly dr1_sparse.m added by Ferhat). Code that can be factorized would go in top-level dr1.m, and specific code would go into dr1_original.m, dr1_korder.m and dr1_sparse.m. Best, -- Sébastien Villemot

2 1