Synchronization of SuperKEKB BPMs

[Mael-Le-Garrec]

The data returned when taking measurements at SuperKEKB is not really synchronized.
Some BPMs can be off by one or two turns.

This script takes as input the original measurement along its optics analysis to determine the turn offset. It then shifts the data and writes the turn by turn data.

Based on https://github.com/JacquelineKeintzel/SOMA/blob/main/checkAsync.py

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
pylhc
__init__.py
bpm_resync.py					193-196, 217
pylhc/constants
bpm_resync.py
Project Total

This report was generated by python-coverage-comment-action

[fsoubelet]

Few things here and there. Overall this is still straightforward, nice.

[JoschD]

As Mael wan't to call this from the GUI, shouldn't we move it to omc3/scripts?
Or do we assume this is done before people are opening the files in the GUI?

[fsoubelet]

As Mael wan't to call this from the GUI, shouldn't we move it to omc3/scripts? Or do we assume this is done before people are opening the files in the GUI?

I guess we could, though the GUI can call this just fine as long as PyLHC is in the specific env (which it is). I'm just wary of omc3 becoming a behemoth.

[JoschD]

though the GUI can call this just fine as long as PyLHC is in the specific env (which it is)

Yes, but the GUI in its current state only undertstands that "external programs" starting with omc3 are actually python programms to be called as python-path -m external-programm-name. And also only checks the omc3 version, not the pylhc version (both was implemented before, but I removed like three weeks ago it as in the last 5 years we didn't use any pylhc scripts).

I'm just wary of omc3 becoming a behemoth.

lol
But seriosly, I think it makes sense if the GUI is a "omc3-GUI", meaning as soon as you have omc3 installed, you can use all the functionality of the GUI + more via CLI.

PyLHC was always more like "functionality that is nice to share with people, but that we wouldn't use with the GUI/from the CCC"

[fsoubelet]

though the GUI can call this just fine as long as PyLHC is in the specific env (which it is)

Yes, but the GUI in its current state only undertstands that "external programs" starting with omc3 are actually python programms to be called as python-path -m external-programm-name. And also only checks the omc3 version, not the pylhc version (both was implemented before, but I removed like three weeks ago it as in the last 5 years we didn't use any pylhc scripts).

I'm just wary of omc3 becoming a behemoth.

lol But seriosly, I think it makes sense if the GUI is a "omc3-GUI", meaning as soon as you have omc3 installed, you can use all the functionality of the GUI + more via CLI.

PyLHC was always more like "functionality that is nice to share with people, but that we wouldn't use with the GUI/from the CCC"

Then let's have it in omc3/scripts. @Mael-Le-Garrec if you don't feel like taking care of migrating this PR I can do it, let me know.

[fsoubelet]

Now superseeded by pylhc/omc3#572 which is a port of this exact functionality and script.