Komori-kun asked me that where the difference in range estimation between the online channel and SummaryPages comes from. (We have two types of range plots on the SummaryPages. One is computed on the semi-online process and provided as the EPICS channel which is shown also on the MEDM screen in the control room. Another one is computed on the SummaryPages process by using an online strain signal.) I wasn't aware of how SummaryPages was operated in detailed, so I checked source code and configuration files of SummaryPages and found that a filter design used in SummaryPages was bad.
According to the configuration file (k1hoft.ini), 10Hz high pass filter is applied to K1:CAL-CS_PROC_DARM_STRAIN_DBL_DQ. A purpose of this filter is probably to reduce the error of PSD estimation. But if my understanding about the source code of SummaryPages is correct, the current filter design makes us to underestimate the spectrum by 26% (=~2dB) in maximum at 10-100 Hz. A filter design (this is just a simulation of SummaryPages behavior with current configuration file, so it should be cross-checked by someone) is shown in Fig.1. There is too large ripples in a search frequency range.
I haven't checked that this filter can explain whole difference between the online channel and SummaryPages yet. In same FFT parameters, estimated range is close to 10% different between with and without ripples. Anyway, filter design on SummaryPages should be re-considered. Though I'm not sure the scope that affected by the configuration files, all h(t) related plots (ASD, PSD, Spectrogram, etc.) on SummaryPages are probably affected by this issue.
Lesson from this issue: Check filter performance before applying it. Even if CAL group pays efforts to provide signals with better accuracy, it's meaningless if users twist signals a lot before their analyses.
Finally, we found both online and SummaryPages estimation has bias as opposite direction.
SummaryPages estimation over-estimated as ~10-12% due to the ripple issues (see also klog#32817).
Online estimation under-estimated as ~14-16%. Depending on the situation of enhanced resonant peaks such as 7Hz, 18Hz, etc. the configuration of PSD estimation during O4a is no longer suitable for current noise.
I modified online estimation code for current noise situation and will deploy it on next maintenance day.
-----
For some consistency with various web-site of LVK, ranges was estimated by using STRAIN channel during observing run. On the other, only DISPLACEMENT channel is well-managed during commissioning test (mainly due to human resource issue). So I had to revert used channel after leaving from O4a. But I forgot it. As the mitigation way of such kind of issue, I'm now planning to prepare new EPICS records on dedicated IOC@k1script1 to save estimated ranges by using both strain and displacement for an easy cross-check. In order to avoid confusing, only one range will probably be DAQ-ed. So another one will be prepared as an volatile records only for an quick cross-check.
For an easy cross-check, new code provide two types ranges
- K1:DAS-RANGE_*** (using strain)
- K1:DAS-RANGE_***_DISP (using displacement)
and comparison in %
- K1:DAS-RANGE_***_COMP
.*_DISP and .*_COMP are not registered to DAQ and they are volatile EPICS records (If they will become important, I may add them to DAQ ).
Because it's difficult to run a new code in too old conda environment, it's now running new conda environment in which version of some packages are updated. Major difference is to update gwpy-2.1.3 to gwpy-3.0.5. In this update template is changed from f^{-7/3} to IMRPhenom which provides more accurate estimation especially for heavy mass binary (difference for BNS case is not so large). If my understanding is correct, z is also taken into account though it's not so large effect for current situation.