'Long pathname' bug in Dynare++

[pawel]

Hi Ondra / Michel,

Just flagging an issue with dynare++ (I think) - which you might (or might not) be aware of and which you might (or might not) want to address at some point. Took me a few minutes to figure this out, so hopefully it will save people time if they get similar errors.

I have a mod file - runs like a beauty from my C:\drive. Problems start when I try running the exact same file from a network drive. I think the issue is that dynare++ has trouble processing the long pathname (in my case it was: N:\Div2\ResearchAndAnalysis\Macrofinance\TimeVaryingRiskPremium\Working_Paper\HumpShapedShockChecks\LevStatBase.mod).

The 'symptoms', appear to vary depending on the dynare++ version.

In 1.3.2 the program entered an infinite loop. When I stopped it (after an hour or so), the .jnl file was 180MB long and did not get to the simulation bit (from the C:\drive the same file takes about 5secs to run (including simulations), and the jnl file is 20KB long.

In version 1.3.5 the program got to the simulation bit (at least according to the .jnl file) but the last line in the jnl was:

0.35937:S00173:-1.:01384: : Performing 1114923380 stochastic simulations for 1400268108 periods

Now, I get this message even though I don't modify dynare++ defaults (and even when I specify '--sim' and '--per' it doesn't overwrite these values). Unsurprisingly, after some time the whole thing crashes with the following error:

This application has requested the Runtime to terminate it in an unusual way.

Hope this is of some use.

Best wishes,
Pawel

[OndraKamenik]

Pawel,

many thanks. I will look at it. It seems that some buffer overflows and makes a mess in the memory.

I am preparing a new distribution, I will fix it there.

thanks again

Ondra K.

[OndraKamenik]

Pawel,

what are you expecting from the following?:

dynare++ /some/directory/file.mod

There are two options: 1. files will be created in the current directory, 2. files will be created in the /some/directory/.

The second is what is happening now, the first is how it should be, files should be created in the current directory. The reason is that the second allows dynare++ to read mod file from a directory and store the results somewhere else. This provides additional flexibility, since the second case always creates files only where is the mod file. If one wants to create the files at the same place as mod file, he can change the current directory there. On the other hand, in the second case, if the /some/directory is read-only, then the user is forced to copy the mod file to some writable diretory. So 1 is good design, 2 is bad design. I am sorry, I overlooked it. I will fix it to 1.

Let me know if you strongly disagree.

Ondra K.

[pawel]

Hi Ondra,

To be honest, for me there's not much difference between 1) and 2) as I always run the files from the current directory. While I agree that 1) is more flexible, if implementing it creates a lot of extra work, then perhaps it's not worth it (after all one can always make a copy of the mod file in a new directory - it's not that complicated...)? So I guess I'd be happy either way, as long as dynare++ doesn't try to run a trillion simulations of a trillion periods each

Thanks again for looking into this.
Pawel

[OndraKamenik]

Pawel,

thanks. My point is that when I was programming I programmed 2 but meant 1. This sometimes happens and is called a bug.

What is confusing me is why you think the issue you describe is caused by the long path. If you now said that you always run files in the current directory, then why are you having any problem with the long path?

Did you run in some directory the following?:

Code: Select all

dynare++ N:\Div\ResearchAndAnalysis\Macrofinance\TimeVaryingRiskPremium\Working_Paper\HumpShapedShockChecks\LevStatBase.mod


or in the directory N:\Div\ResearchAndAnalysis\Macrofinance\TimeVaryingRiskPremium\Working_Paper\HumpShapedShockChecks you ran

Code: Select all

dynare++ LevStatBase.mod


If the second case, than the error is not probably caused by the long path name.

Ondra K.

[pawel]

A combination of the two actually

I was in

Code: Select all

N:\Div2\ResearchAndAnalysis\Macrofinance\TimeVaryingRiskPremium\Working_Paper\HumpShapedShockChecks

and the command I typed was (dynare++ is not on my path):

Code: Select all

c:\dynare++\dynare++.exe N:\Div2\ResearchAndAnalysis\Macrofinance\TimeVaryingRiskPremium\Working_Paper\HumpShapedShockChecks\LevStatBase.mod

While I realise that I don't have to specify the full path, it shouldn't do any harm should it? (I'm using a Matlab script that does all this for me in the background and I guess when writing it, I wasn't sure whether I needed to specify the full path or not - so I just did it).

It is this command that dynare++ seems to have trouble processing and because of that I suspect it might have something to do with the long file name...

Hope that clarifies
Pawel

[OndraKamenik]

Pawel,

thanks. You put the long pathname behind dynare++, this is what is important.

The handling of paths is easy. The model file is relative to the current directory. Your current directory can be /ondra/is/the/best and your mod file can be /ondra/is/always/wrong/exclamation.mark. So you can type

Code: Select all

dynare++ ../../always/wrong/exclamation.mark

I think I corrected the bug.

Ondra K.

[pawel]

Thanks for the info - might come in handy in the future.

Re:bug - cool, so that means there are only n more left

Best,
Pawel