Disable corrections that moved to hax

[JelleAalbers]

This disables cax tasks that added run doc overrides for corrections that have moved to hax. These are now so far out of date the correction map files they reference no longer exist, breaking various things (shifter notebooks, waveform inspection code, etc).

After merging this, we'd still have to

• Update the cax(es) that runs the correction tasks (I don't know where); unless this happens automatically
• Scrub the references to the outdated correction maps from the run docs (I could do this).

The alternative to this is to update the corrections db with all the new corrections in hax.ini. I doubt we want to to do this and maintain two separate systems.

[tunnell]

See https://xe1t-wiki.lngs.infn.it/doku.php?id=xenon:xenon1t:org:commissioning:meetings:20180418

[tunnell]

Also, next time: you can just delete lines of code instead of commenting them out. We have version control and otherwise it piles up.

[JelleAalbers]

Thanks for merging; however, to finish this update, someone has to (update if this didn't happen automatically and then) restart the cax that currently does this correction-adding. Right now I can see the old corrections are still being added, see e.g. run 18583.

[tunnell]

That should have happened automatically (at least when I set things up). Maybe worth asking in Gitter computing.

[ershockley]

I thought I did restart but just in case I retried now

[JelleAalbers]

@ershockley unfortunately I still see the old corrections being added (see e.g. run 18664). Could there be a cax instance running somewhere else?

[ershockley]

@XeBoris is there a cax running on xe1t-datamanager that calculates corrections?

[ershockley]

Okay I found the issue - it should have been obvious. We use the pax_v6.8.0 env which I guess no longer gets updated automatically by DeployHQ? Anyway I checked the cax installation and these changes weren't applied in that env. I have removed the three tasks manually with the configuration file, and this should fix the issue (unless there's another cax instance somewhere - I do not know of one).

@JelleAalbers I should have asked this earlier but do you know if removing these corrections will break pax?

[JelleAalbers]

@ershockley Thanks! Pax has defaults for these values in the XENON1T.ini, which Lutz recently updated. The defaults in pax 6.8.0 are likely not accurate, so this will lead to wrong values for pax-computed corrections if we continue processing with pax 6.8.0. However, assuming we do not rely upon these quantities (since hax took over corrections) anywhere it should not matter.