UseParallel feature of fmincon

Hello,

Using dynare 4.4.3 and matlab 2016b, I’m trying to use the “UseParallel” feature of fmincon in order to estimate a SW-type of DSGE with mode_compute = 1. Unfortunately the estimation stops after 1 iteration (whatever the model/ the initial point).

I found on the internet that the issue might be linked to the use of global variables (post of Sep 3 2015 here github.com/DynareTeam/dynare/issues/1051). Did you manage to circumvent the issue? Did someone test the “UseParallel” feature of fmincon?

Thanks in advance,

Kind regards,

Thomas

Please try the unstable version of Dynare and report back.

Thanks for your quick reply.

Testing with the unstable version “master-2017-03-07-7341ca4”, I encounter the following error (log file and mod file are in attachments) when using the ‘UseParallel’ feature of fmincon:

Error using dsge_likelihood (line 326)
Reference to non-existent field ‘vobs’.

Without the parallel feature, the estimation works fine with the unstable version.

Regards,

Thomas
usmodel_est_70_13.txt (5.32 KB)
usmodel_est_70_13.mod (7.44 KB)

We are investigating the issue: github.com/DynareTeam/dynare/issues/1400

I am also having trouble running fmincon through MultiStart with the option ‘UseParallel’, true. The idea is to implement simple GMM through fmincon. The procedure runs fine without parallel computing, but otherwise gives the following error message:

Starting parallel pool (parpool) using the ‘local’ profile … connected to 4 workers.
Running the local solvers in parallel.

Run       Local       Local      Local    Local   First-order

Index exitflag f(x) # iter F-count optimality
Warning: Element(s) of class ‘dates’ do not match the current constructor definition. The element(s) have been converted to structures.
4 -10 0
Warning: Element(s) of class ‘dates’ do not match the current constructor definition. The element(s) have been converted to structures.
3 -10 0
Warning: Element(s) of class ‘dates’ do not match the current constructor definition. The element(s) have been converted to structures.
2 -10 0
Warning: Element(s) of class ‘dates’ do not match the current constructor definition. The element(s) have been converted to structures.
1 -10 0
5 -10 0

MultiStart encountered failures in the user provided functions.

All 5 local solver runs failed in a user supplied function.

This problem seems to be connected to the elements of class ‘dates’ being converted to structures. I can’t follow how this issue has been addressed in the GitHub topic… Is there a workaround for that or I better wait for a fix in Dynare? I’m using Dynare 4.5.4 version.
Also, the function that is optimized makes use of the two functions
resol()
disp_th_moments()
which do not use any global variables. Instead, M_,oo_,options_ are passed as arguments and used locally, right? That is not the case for stoch_simul(), which does use global variables.
Thanks for your help.

I was able to get rid of the warnings by substituting two files, “dates.m” and “dseries”, from GitHub into my dynare version. Yet, MultiStart error “MultiStart encountered failures in the user provided functions.” persists. Obviously the function resol() I am using is not appropriate for a paralelled loop (for whatever reason…). I try different function.

resol should work in parallel without any issues. Could you please provide me with the codes to replicate the issue?

Thanks for writing, Johannes. Maybe I have found the reason for the error “MultiStart encountered failures in the user provided functions.” in my case. I have a steadystate.m file that uses global variables, such as M_ and resol() obviously recalculates the steady state using these global variables in the parallel loop, which causes the error. I can tackle this by either getting rid of the _steadystate.m file or by using a function different from resol(). I am more inclined to keep the _steadystate.m file for my convenience - I’m more used to this method. Would you suggest otherwize, or any third approach?
Thanks again,
Ivan

If you could use a steady_state_model-block that would solve the issue.

1 Like

That seems to work. Thanks a lot, Johannes. I may still try to use another function in Dynare later on. So far so good!

There is no other way. You always need to solve the model, which involves computing the steady state. Even relying on the more low-level functions like stochastic_solvers.m would not get around this issue.

P.S.: In your context you want to use the steady_state_model-block, because it is a lot faster than a normal steady state file.