What is this about?: step_methods/hmc/quadpotential.py:224:

The full error during inference is

/home/ubuntu/anaconda3/envs/bayesian/lib/python3.8/site-packages/pymc3/step_methods/hmc/quadpotential.py:224: RuntimeWarning: divide by zero encountered in true_divide
  np.divide(1, self._stds, out=self._inv_stds)
/home/ubuntu/anaconda3/envs/bayesian/lib/python3.8/site-packages/pymc3/step_methods/hmc/quadpotential.py:203: RuntimeWarning: invalid value encountered in multiply
  return np.multiply(self._var, x, out=out)
/home/ubuntu/anaconda3/envs/bayesian/lib/python3.8/site-packages/pymc3/step_methods/hmc/quadpotential.py:224: RuntimeWarning: divide by zero encountered in true_divide
  np.divide(1, self._stds, out=self._inv_stds)
/home/ubuntu/anaconda3/envs/bayesian/lib/python3.8/site-packages/pymc3/step_methods/hmc/quadpotential.py:203: RuntimeWarning: invalid value encountered in multiply
  return np.multiply(self._var, x, out=out)

Some Details:
I am estimating counts of store sales , given neighboring store sales. Its a simple linear model. There are a lot of neighboring stores, so I use a sparsity inducing prior - Laplace/ horseshoe. I model this both as a Poisson and and as linear model separately. I repeat this process for 50 stores and their neighbors. For some of them - no issues the model estimates like a champ. But for about a dozen this is the error after getting some distance on the sampler.

This happens when NUTS reaches about 14% on the progressbar. (So it is not the initialization itself.)
I checked the data, none of the variables have zeros variance. Any pointers would be most welcome.
If this is occurring in an MCMC estimation step (and not in the data itself), what can I do to avoid it?
Update:
It could be the initialization. Defaulting to alternative initializations sometimes appears to work. Is there a more principled approach to choosing initializations?

Thanks

You need to provide more details about your model / data

See edit.

What have you tried?

Here is my backoff scheme

‘jitter+adapt_diag’,‘advi_map’,‘jitter+adapt_full’,‘advi+adapt_diag’,‘advi’,‘adapt_full’

In most cases advi_map produces a reasonable model with few if any divergences, rhat at 1 .

But its interesting that the sampler fails after about 800 iterations (i.e. tuning phase) . So the initial ‘jitter+adapt_diag’ starts out fine, and then runs into trouble somewhere.

There is not much else that can be said without actually seeing the model. If you cannot share it, the only advice I can give is to try to give it more forgiving priors + build the model incrementally to see what aspects are “breaking” it.

It’s not uncommon for brittle models to fail with NUTS, or requiring a very specific initialization method as you noticed.