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.
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.
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. 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?
and the command I typed was (dynare++ is not on my path):
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…
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
