On the occasional uxm_relock, one or more bands on a given module will lose a large amount of good tracking channels. The official advice is to wait and see if they're recovered by the next uxm_relock. Note that uxm_relock does not disable bad tracking channels , so I don't think we're actually losing these channels, but if it happens on 2+ bands, then we will lose time while a relock is done.
Below is such a dropout happening on Uv41 band 2 before being recovered, and later a dropout on band 5.
The drop of good resonators is the sudden decrease in r2 (tracking quality), which has a cutoff of r2>0.9. Here I plot the r2 histograms for band 2 for the relock where resonators dropped out ("Bad") as well as that of the "Good" relock immediately preceding it:
Digging into this, I saw the tracking quality was computed over segments of the TOD defined by the pysmurf function make_sync_flags. This takes the sync signal of pysmurf (also called flux_ramp_strobe), which is 1 when the flux ramp is resetting and 0 when not, and identifies the starts+ends of those sync=1 blocks, though it only returns the start indices.
There is a rescaling of the x-axis, but for the bad relock, the sync flags are [ 0 149 299 449 599], and for the good relock they are [ 2 152 302 452 602].
compute_tracking_quality chunks up the data based on these indices, with all chunks being made to have the length of the shortest chunk:
|
seg_size = np.min(np.diff(sync_idxs)) |
This is a problem when the data starts with the flux ramp resetting (sync_idxs[0] = 0), in which case the first segment will be shorter than the rest, and all subsequent segments will use the wrong length. Indeed this was the case in the Uv41 band 2 example above.
To try fixing this, I recomputed the tracking quality ignoring sync_idx=0, obtaining the following plot
I repeated the same test on Uv56 band 2, which had a similar brief drop out of resonators:
There may be a smarter way to catch this in the pysmurf function make_sync_flags, but for now, I think this can be fixed with a one-line edit to compute_tracking_quality. There is at least one other reference to make_sync_flags in tracking.py, but I don't think it's necessary to fix that instance.
On the occasional uxm_relock, one or more bands on a given module will lose a large amount of good tracking channels. The official advice is to wait and see if they're recovered by the next uxm_relock. Note that uxm_relock does not disable bad tracking channels , so I don't think we're actually losing these channels, but if it happens on 2+ bands, then we will lose time while a relock is done.
Below is such a dropout happening on Uv41 band 2 before being recovered, and later a dropout on band 5.
The drop of good resonators is the sudden decrease in r2 (tracking quality), which has a cutoff of r2>0.9. Here I plot the r2 histograms for band 2 for the relock where resonators dropped out ("Bad") as well as that of the "Good" relock immediately preceding it:
Digging into this, I saw the tracking quality was computed over segments of the TOD defined by the pysmurf function
make_sync_flags. This takes the sync signal of pysmurf (also called flux_ramp_strobe), which is 1 when the flux ramp is resetting and 0 when not, and identifies the starts+ends of those sync=1 blocks, though it only returns the start indices.There is a rescaling of the x-axis, but for the bad relock, the sync flags are
[ 0 149 299 449 599], and for the good relock they are[ 2 152 302 452 602].compute_tracking_qualitychunks up the data based on these indices, with all chunks being made to have the length of the shortest chunk:sodetlib/sodetlib/operations/tracking.py
Line 34 in bff5c5a
This is a problem when the data starts with the flux ramp resetting (
sync_idxs[0] = 0), in which case the first segment will be shorter than the rest, and all subsequent segments will use the wrong length. Indeed this was the case in the Uv41 band 2 example above.To try fixing this, I recomputed the tracking quality ignoring sync_idx=0, obtaining the following plot
I repeated the same test on Uv56 band 2, which had a similar brief drop out of resonators:
There may be a smarter way to catch this in the pysmurf function
make_sync_flags, but for now, I think this can be fixed with a one-line edit tocompute_tracking_quality. There is at least one other reference tomake_sync_flagsintracking.py, but I don't think it's necessary to fix that instance.