[Bug]: coupling analysis filters too many BPMs
JoschD opened this issue · comments
Bug Description
After a combined optics analysis of many files, very few BPMs were left for coupling (i.e. in the coupling.py output f1001.tfs and f1010.tfs.)
An example can be found in /user/slops/data/LHC_DATA/OP_DATA/Betabeat/2022-04-24/LHCB1/Results/20-17-55_ANALYSIS/
For comparison, that's what beta_phase looks like:
Operating System
CentOS (CCC)
Python Version
python 3.9
Package Version
0.2.5
A suggested fix is in #368
So it looks like this is happening, because there are different S for the BPMs in the files/planes.
Does anyone know how this could be happening? @tpersson @rogeliotomas @mihofer @fsoubelet
And at @awegsche who had a closer look at this: are these big differences? Is this between files or only between planes?
A suggested fix is in #368
So it looks like this is happening, because there are different
Sfor the BPMs in the files/planes. Does anyone know how this could be happening? @tpersson @rogeliotomas @mihofer @fsoubeletAnd at @awegsche who had a closer look at this: are these big differences? Is this between files or only between planes?
Our best guess for now is "numerical noise", since when doing the merge, pandas looks for exactly identical values.
Depending on how S values are written to disk in the acquisition files or the omc3.optics_measurements outputs, even a small difference would be enough to filter out some BPMs. Will look deeper into the files for differences.
A suggested fix is in #368
So it looks like this is happening, because there are different
Sfor the BPMs in the files/planes. Does anyone know how this could be happening? @tpersson @rogeliotomas @mihofer @fsoubeletAnd at @awegsche who had a closer look at this: are these big differences? Is this between files or only between planes?
those are two of the most conflicting files:
NAME S AMP01_X_9 PHASE01_X_9 MUX_X_9
BPMYB.5L2.B1 BPMYB.5L2.B1 28.288 0.001138 -0.167209 0.375722
BPMYB.4L2.B1 BPMYB.4L2.B1 48.858 0.002430 -0.290069 0.405325
BPMS.2L2.B1 BPMS.2L2.B1 161.394 0.002846 -0.389635 -0.345674
BPMSW.1L2.B1 BPMSW.1L2.B1 171.328 0.003756 -0.311176 -0.320695
BPMS.2R2.B1 BPMS.2R2.B1 224.452 0.004204 0.205842 0.058952
... ... ... ... ... ...
BPM.10L2.B1 BPM.10L2.B1 26464.266 0.003308 -0.051767 0.029427
BPM.9L2.B1 BPM.9L2.B1 26503.334 0.004619 -0.088569 0.172610
BPM.8L2.B1 BPM.8L2.B1 26543.799 0.003711 -0.156190 0.269131
BPM.7L2.B1 BPM.7L2.B1 26582.865 0.001754 -0.237154 0.393185
BPMR.6L2.B1 BPMR.6L2.B1 26614.973 0.003161 -0.432003 0.497893
NAME S AMP10_Y_9 PHASE10_Y_9 MUY_Y_9
BPMYB.5L2.B1 BPMYB.5L2.B1 28.28800 0.547929 0.264865 0.262835
BPMYB.4L2.B1 BPMYB.4L2.B1 48.85800 0.247893 0.202324 0.360731
BPMWI.4L2.B1 BPMWI.4L2.B1 73.32550 0.117578 0.154718 0.421969
BPMSX.4L2.B1 BPMSX.4L2.B1 123.42250 0.361200 -0.266310 -0.387033
BPMS.2L2.B1 BPMS.2L2.B1 161.39400 0.423318 -0.259497 -0.344742
... ... ... ... ... ...
BPM.10L2.B1 BPM.10L2.B1 26464.26623 0.224178 -0.044387 0.216680
BPM.9L2.B1 BPM.9L2.B1 26503.33322 0.061806 -0.137427 0.276558
BPM.8L2.B1 BPM.8L2.B1 26543.79821 0.235565 -0.441464 0.350676
BPM.7L2.B1 BPM.7L2.B1 26582.86620 0.312536 -0.467441 0.394028
BPMR.6L2.B1 BPMR.6L2.B1 26614.97220 0.378621 -0.476993 0.413975
what I can see at first glance: different representation (28.28800 vs 28.288) and slightly different values, e.g. BPM.7L2.B1
edit:
Note: these are 'parallel' input files from the input_files object passed to measure_optics
That does not look like numerical noise. That looks like different output accuracy used when creating these files.
Not true, the rounding is off.... weird