MCMC proposal outside prior raises FloatingPointError and kills sampler

[astrolamb]

On line 6 of runQuickMCMC.py, there's a line that changes the default behaviour of numpy when 0.0 is input into np.log. The default behaviour is a warning. Line 6 changes the bevaiour to raising a FloatingPointError. This causes an error when an MCMC iteration proposes a value outside of a prior. Instead of assigning a logpdf of -np.inf, as expected of an MCMC sampler, it just kills the sampler.

QuickCW/runQuickMCMC.py

Line 6 in d7e12cb

np.seterr(all='raise')

I see that there are similar lines of code throughout QuickCW that have been commented out. I assume this line should've also have been commented out?

I raise this because it was a source of confusion for a student who thought it was actually an enterprise problem initially.

[bencebecsy]

Thanks for raising this. The thinking behind np.seterr(all='raise') was that we'd rather have the sampler fail than something that might be an actual problem go unnoticed as a warning.

Now this is clearly not the case for a proposal outside the prior, but I actually think that should not happen, because we reflect back all parameters to be in the prior range before getting prior and likelihood with functions in the QuickCorrectionUtils.py file. But maybe that does not work in some corner cases.

@astrolamb , do you happen to know what parameter was outside the prior range in this case?

[astrolamb]

@bencebecsy the issue happened when @levischult tried to run some QuickCW analyses in April. I've tried using their old scripts but I can't recreate the bug, but those scripts/data could've been fixed somehow between then and now. This might need some further testing