'onlymacro' option

Hi There

I’m using dynare (4.3.3) with option ‘onlymacro’ but it doesn’t seem to do what the manual suggests - i.e. rather than stopping after macro-processing, it continues to launch steady state computation, run stoch_simul, plot charts etc. (the ‘savemacro’ and ‘nolinemacro’ do work fine for me, btw.).

So just wondering whether I’m being thick and this is indeed what should happen, or whether there’s something funny going on with the implementation (of course, both could be true simultaneously…).

Thanks in advance for any help,
Pawel

Seems to be a bug. We will keep you updated. Thanks for reporting.

The behavior will change to the desired one starting with tomorrows snapshot.

The bug was fixed.

What was being run was a version of modfilename.m that had been created by a previous run of dynare. Just delete this file, run dynare with onlymacro, and processing will stop. You won’t need to do this step in the next release of Dynare. Thanks for reporting this bug.

Thanks a lot for your help Guys - much appreciated.

Houtan - is what you’re describing meant to run with the plain vanilla v.4.3.3 or with the latest snapshot? Because if it’s the former, then it doesn’t do the trick for me - i.e. when I delete the .m file and re-run with option onlymacro I get an ??? Error using ==> evalin Undefined function or variable 'xxx'. and more generally a new .m file is not created.

Either way, I’ve found a workaround to achieve what I wanted using *savemacro *and nolinemacro, so I can definitely wait till the next release for this to be 100%.

Thanks again
Pawel

It runs with 4.3.3. If you use the onlymacro command, the preprocessor will not run completely and hence the .m file will not be created. The evalin command is where dynare.m calls the modfilename.m file that is usually created by the preprocessor. As you have passed the onlymacro command, you don’t want this .m file because you only want to run the macroprocessor. The bug was that we were allowing processing to continue on the matlab end (not the C++ end, in which the preprocessor is coded). This was not a problem when the .m file didn’t exist in the directory, because you’d get the error you see now. But it was a problem in the case when someone had successfully run the preprocessor before.

As Johannes said, the correction will be in tomorrow’s snapshot.

In which case, I seem not to get what the option is meant to do…

So just to be clear: I have a *xxx.mod *file that uses the macro-processing language. Having read the manual, my understanding was that after running dynare xxx.mod onlymacro what I would end up with is either a new *xxx.mod * file in which all macro-processing commands have been parsed out, or a xxx.m file, corresponding to the parsed / macro-processed *xxx.mod * file. In the latter case, the xxx.m file would not be ran as everything would stop post macro-processing (though presumably, I should be able to do run it later - either by calling *dynare *on the post-processed .mod file or by directly invoking the *.m * file, in each of the two cases respectively).

Your answer seems to suggest you’d expect neither of those, right? So what is it that should happen?

Thanks again
Pawel

ps. Strictly speaking I guess I shouldn’t be confusing macro-processing - i.e. replacing macro-processor commands with whatever text they represent, with parsing, i.e. converting the .mod file into an .m file (again if my understanding is correct). In which case I’d probably expect to see a new .mod file without any macro-processing instructions… But again, that was one of the two cases above, so the question still stands, I think.

The manual states:

So, processing stops after the macroprocessor runs. For the .m file to be created, you need the preprocessor to finish running. So, your second case would not happen. Your first case would happen if you called dynare xxx.mod onlymacro savemacro.

Gotcha and it does do *exactly * what it says on the tin…

Thanks!
p