acor causes problems and isn't actually needed

[paulthebaker]

@kdolum pointed out on slack:

I ran across this code in enterprise_extensions/model_utils.py:

try:
    import acor
except ImportError:
    from emcee.autocorr import integrated_time as acor

I think this type of thing is always a bad idea. We should have specific requirements (in my opinion emcee, not acor), rather than using whichever module is available. Otherwise we will have results that cannot be duplicated because they depend on the user's environment in complex ways.
This particular code also has a bug. integrated_time is a function, but acoris a module. The later code calls acor.acor, which will a work only if the code above loaded acor. If it loaded emcee, you'll get

AttributeError: 'function' object has no attribute 'acor'

Please could we fix this situation once and for all?

acor is only used in two places. First, it's used in model_utils.ul where it is needed to estimate the UL uncertainty. However, that estimate is known to be wrong. Second, it's used to automatically thin chains in model_utils.odds_ratio. We could easily have the user input their own thinning factor, instead of using acor to decide for them.

I suggest we simply remove the acor function from e_e. This will simplify things by eliminating acor and/or emcee as e_e dependencies.

[paulthebaker]

There was also some discussion with @Hazboun6 and @AaronDJohnson that post-processing utilities like model_utils.ul and model_utils.odds_ratio more properly belong in la_forge, not e_e. Should we mark functions like these as deprecated, and eliminate them entirely at some point in the future?

[AaronDJohnson]

The la_forge dev branch contains an odds_ratio calculation that uses bootstrap rather than the old method of computing uncertainties. Further, this uses emcee and not acor. So in this way, I think this has been solved if we move to la_forge as our only post-processing package.