Slice sampler: how many chains and draws should I choose?

Dear all,
I was wondering where I can find guidance on the use of the slice sampler. The only paper I am aware of is the 2015 Planas/ Ratto/ Rossi paper
( ), which is incomplete and does not offer practical guidance.
My understanding from the attached presentation from a course that a colleague took at the JRC is that the basic principle is to have more chains but fewer draws (since the chains converge much faster than with the RWMH), and that you do it twice: Once to get a covariance matrix (with an even lower mh replic), and then again with the rotated option (slide 17).
Slice_GSA_Course_2019.pdf (2.1 MB)

But which combination of chains and draws is “okay”, is there rule of thumb? In the presentation there seems to be one example with 4 chains and 100 draws (slide 25, if I understand correctly). But then there is also one example suggested for parallel implementation, with mh blocks=250 (!!), and a much smaller mh_replic numbers for both runs of the sampler (see slide 27).

Finally, with the slice sampler, do I still need to care about the value of mh_jscale and the acceptance ratio?

Just to give some further background for my question (in case it is relevant): The reason I am interested in the slice sampler is that I ran into the problem that " (minus) the hessian matrix at the “mode” is not positive definite!=> posterior variance of the estimated parameters are not positive." (although all the posterior standard deviations are real values (not complex numbers)) when using the mode finder. I should mention that I am using the occbin estimation (with the piecewise Kalmann filter), I have already tried mode finders 1 and 5, and that for the standard estimation (without occbin), computing the hessian poses no problem. Also, the parameter estimates are very close to the estimation without Occbin. Unfortunately, I am not able to do the mode_check for the Occbin estimation properly since the machine runs out of memory after having produced the mode_check graphs for some of the parameters (for one of the parameters for which the graph is produced, the surface of the posterior is very rough).

Best wishes,

@rattoma should be able to answer most of the initial questions.

I am a bit puzzled by the mode_check-problems. Could you maybe provide me with the codes and the mode-file to see where the problems come from.

Hi Johannes,
sure I am attaching them. You need to type " dynare E_obc_e " The .mod files are a bit messy, I apologize. The estimation command is in the E_obc_e.mod files. Many thanks!
Best wishes,
Ansgar (2.0 MB)

I cannot reproduce the mode_check-problems you report in the unstable version. How much memory does your machine have?
The message

(minus) the hessian matrix at the “mode” is not positive definite!=> posterior variance of the estimated parameters are not positive.

is not about the estimated standard deviation of your shocks, but the estimated variances of all the parameter estimates. The fact that the Hessian at the mode is not positive definite means that it’s not a proper covariance matrix at the mode.

The message I am getting is

warning: Matrix is close to singular or badly scaled. Results may be inaccurate. RCOND = 7.022761e-17

in occbin.mkdatap_anticipated_dyn.m. This suggests your estimation ran to a pathological region of the parameter space.

Hi Johannes,
thank you, I have attached a screenshot from the system information. The installed physical memory is 32 GB. “Available physical memory” is 18,6 GB

Yes I got that error message as well during mode check, in the past I also sometimes got it during the mode-finding procedure with fmincon in combination with Occbin. What do you mean with pathological region of the parameter space? Is that a region where Occbin cannot find a solution?

I ran the code with the same memory and found no issues. With pathological I mean that OccBin has a hard time computing the solution and works with close to singular matrices.