I ran into a similar problem, but I isolated a different problem than the version conflict noted above.
If you have residual tasks in FevalQueue in your pre-existing parallel pool, estimation will just get “stuck/hang” once it hits parfeval (line 167 of <matlab/estimation/posterior_sampler_core.m> file) because new parallel evals are queued behind those (potentially aborted) tasks. For example, this will happen if you abort a parallel estimation with the “stop” button (not the “x” in the dynare progress bar) or ctrl+c, and restart estimation.
This can be fixed in dynare with
- “cancelAll(pool.FevalQueue);” can be added right behind “run_with_pct=true;” (line 103 of <matlab/parallel/setup_parallel_execution.m>) to flush FevalQueue if parallel pool is being reused. This assumes that people do not want to wait for the queued tasks to finish before running dynare, but I consider this to be unlikely. The example above of stopping and restarting estimation runs is a more likely usage pattern.
- Alternately, a warning can be issue prior to parfeval. Something like “If the progress bar does not appear shortly, dynare is waiting for prior queued tasks to finish. If this is not intended, clear parallel eval queue prior to running dynare with cancelALL(gcp(‘nocreate’).FevalQueue)”
- Alternately, a warning can be issued for the most common case that “breaking/stopping” a parallel estimation run doesn’t clear the parallel evalution queue.
I prefer the first option. In the meantime, users can just
- add “cancelAll(gcp(‘nocreate’).FevalQueue);” before running dynare to clear the FevalQueue.
- close parallel pool “delete(gcp(‘nocreate’));” before running dynare (this will be slower)
- Unfortunately, “clear all” doesn’t seem to clear pool.FevalQueue, so you need that ugly(?) line even with clear all.