ERROR: MethodError: no method matching Array{Optim.OptimizationState{DSGE.Csminwel,T},1} where T()

[BrianLeBlanc90]

I'm getting errors pulling in all the data and with running the estimate(m) function. I'm trying to run the run_default.jl script on a fresh 0.6.2 Julia install.

It's not able to grab the longinflation, longrate, and tfp series. When I fill those myself manually, I'm getting the error below when I get to estimate(m).

ERROR: MethodError: no method matching Array{Optim.OptimizationState{DSGE.Csminwel,T},1} where T()

I tried different optimation_method settings, and the only one that doesn't give an error is simulated_annealing, but I don't think it's actually converging, since the gradient norm is NaN at each iteration.

I also tried different versions of the Optim package, but that's doesn't seem to be fixing the problem.

EDIT: I also couldn't install the package using the standard Pkg.add("DSGE") method. I had to clone the git repo. The error had to do with Optim, which I think might be related to the above ^

[abhig94]

I wasn't able to replicate your issue on our machines, but we've put out a new release of the package that includes many Optim-related bug fixes and should address your problem. It might be a couple days before Metadata accepts our pull request so in the meantime you can grab the latest version of the package using Pkg.checkout("DSGE"). If Julia complains when you try to do that, just run git pull in the package directory directly.

For simulated annealing, there is no gradient to report so it'll always give NaN. Currently, we don't try to assess convergence when using simulated annealing and instead let it run until the maximum number of iterations is hit (as specified in the optimization_iterations setting). For a larger model like 990 I would recommend using at least 100,000 iterations.

[pkofod]

Are you using SimulatedAnnealing from Optim? If so, I'd just like to mention that if you have any idea about the parameter space, we recently added a new Simulated Annealing with bounds called SAMIN that you can try. It should be better in many cases.

It might be a couple days before Metadata accepts our pull request so in the meantime you can grab the latest version of the package using Pkg.checkout("DSGE").

Do you have something like a semi-regular release cycle ? Optim will tag a new version soon, so maybe it would make sense to coordinate a bit before you tag a new version.

[abhig94]

We are indeed using Optim's SimulatedAnnealing, but we'll look into the new SAMIN routine as well. We currently transform our parameters during optimization so as to avoid bounds issues (i.e. we map each parameter from its original domain into the whole real line), but we'll likely investigate doing optimization directly in the bounded, untransformed parameter space at some point in the future.

We're now aiming to release hotfixes/new features every 6-8 weeks (following FOMC meetings). These will also include changes needed to keep DSGE.jl up-to-date with its dependencies. In the meantime, we'll watch for the next release of Optim and update DSGE.jl prior to the next FOMC meeting if we get the chance.

[BrianLeBlanc90]

Thanks, Abhi. And the data-pull issue? I'm still trying to run the run_default.jl script. Before, it would just save the CSV with those series having all missing values. Now I get the error:

WARNING: THREEFYTP10: Bad Request. The series does not exist in ALFRED but may exist in FRED. Try
setting realtime_start and realtime_end to today's date or removing the realtime_start and realtime_
end variables. (400)
WARNING: FRED series THREEFYTP10 could not be fetched at vintage 151127.
Fetching FRED series THREEFYTP10 without vintage...
ERROR: MethodError: no method matching start(::Symbol)
Closest candidates are:
start(::SimpleVector) at essentials.jl:258
start(::Base.MethodList) at reflection.jl:560
start(::ExponentialBackOff) at error.jl:107

The problem is that now it doesn't save the CSV, and I don't know what the file naming convention of /observation names should be to bypass it pulling data from Fred.

[abhig94]

The warning about the THREEFYTP10 series is expected, as that series is never revised and therefore doesn't have historical vintages available through ALFRED. Unfortunately, this warning doesn't shed any light on the source of your error. Could you try calling load_data_levels(m) and see if that completes successfully?

If you wish to construct a dataset by hand in the meanwhile, take a look at the file here. This data file is for a newer, larger version of the model and as such has some slightly different series. All of the ones needed for model 990 are there with the exception of obs_spread, the difference between Moody's Baa corporate bond yield and the 10Y treasury expressed in quarterly terms. You can find these series on Fred under the mnemonics BAA and GS10, respectively.

[BrianLeBlanc90]

load_data_levels(m) produces the same error I wrote above.

I don't mind creating it by hand, I just don't know what to name the file to bypass the estimate(m) function pulling the data from Fred. Like I said, nothing gets saved after I get that error, and I can't find anything in the documentation describing what the naming convention should be.

Better yet.. is there another test or example script that works with a fresh v0.6.2 Julia install? I'm really just trying to learn how to use it.

[abhig94]

The sample data file created by running the example script should be named data_dsid=02_vint=151127.csv and should live in DSGE/save/input_data/data (where DSGE is the main package's repository). Since you've already (attempted to) run load_data before, the directory should exist already.

I've tried to replicate your issue with no success so far, unfortunately. I would suggest running Pkg.free("DSGE") in the Julia REPL to revert the package back to its previous state for now. If you'd like to work with a model for which all the data series can be found on FRED, I would suggest trying out the AnSchorfheide model, a small 3 equation New Keynesian DSGE model. You can do this by switching out the call to Model990() for AnSchorfheide() in the sample script. The data file that will get generated and saved for this model will be named data_dsid=02_vint=151127.csv. Let me know if you're able to run the sample script with this smaller model. I can also post sample data files if you continue to have issues.

[caimichael]

Hi Brian,

Abhi has left the NY Fed DSGE team since this issue was last bumped, so I'm assigning myself to see if we can get this resolved. We previously were not incredibly timely with updating our dependencies, so our the inability in exactly replicating your issue might be because of versioning.

We currently use v0.6.0, so if you want to give this another go on Julia v0.6.0, and let me know your package versions (just screenshot your Pkg.status() output), prior to trying to run estimate() again, that'd be great!

Hope we can figure this out.

Best,
Michael

[pkofod]

Given the original Optim mentions im happy to help of its related to that package, but reading through the thread, I think the optim errors were because op checked out incompatible package versions. Reach out here, via mail or gitter if you need my input.

[caimichael]

Thanks Patrick! I do think that is the case. After updating all of my packages and re-running our tests, there seems to be no issue on my end.