@dathomps, Is the plan to re-run StrippingBu2LLK in its entirety for the incremental re-stripping campaign or only to run the Lb2pkll lines? If it is the former, the reproducibility issues pointed out in #41 need to be fixed.

On another point of order, BU2LLK is already huge, and adding more lines to this might not be very modular. Perhaps we could consider making a separate module? @ngrieser @fredi

As an outsider, it makes no sense that a module called Bu2LLK.py houses so many things that are not Bu decays. I strongly encourage analysers if they want to keep using this to consider segmenting to something more reasonable. At the very least, this needs to be renamed to actually reflect what it is housing (and from my brief view, I cannot even make out why all these things are put together because it is so big..)

Hi @avenkate @ngrieser , Unless there was any request from the wider wg the plan was only to run the new pkmeLoose and pkmeSSLoose lines, as I have made no changes affecting other lines and can use the last restripping version in addition as a normalisation if we actually end up using the pkllLoose lines.

I agree the line is getting busy, but I see this as completing the pkll set added in the last restripping.

Okay that seems reasonable in this case, and I think we will just freeze anything else ever being added to this module.

Please make sure your liaisons have a bookkeeping of which lines to run such that only the necessary ones make it into the config dictionary (maybe only report the timing/rates for the ones you want, like you've done is enough?)