You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So far we have followed the ACT convention, where the flags are called glitch_flags. However, now we have a glitch-finding function that add flags named glitches, which are obviously different from the overall flags, but could lead to a conflict of names.
With overall flags for mapmaking I mean the union of turnarounds, glitches, jumps, bad subscans, etc.
The text was updated successfully, but these errors were encountered:
The plan here has always been to combine various flags into two aggregate flags that mapmaking would treat slightly separately:
do_not_map -- data that are not completely invalid, but where there is some desire to exclude them from the map. For example, turn-arounds regions can usually be included, without any patching, when doing fourier filtering. But the samples themselves should be excluded from mapmaking. Or if there are a few places where the pointing is uncertain, but the signal otherwise well behaved.
invalid_signal -- data that cannot be trusted (such as glitches); these need to be gap-filled before fourier operations, and thus the samples excluded from mapmaking.
I'm open to better name suggestions here I just want to encourage a focus on how the aggregate flags will be used downstream, rather than what goes into them. (So I am quite happy to lose the "glitch_flags" hard code from the mapmakers...)
There might be
So far we have followed the ACT convention, where the flags are called
glitch_flags
. However, now we have a glitch-finding function that add flags named glitches, which are obviously different from the overall flags, but could lead to a conflict of names.With overall flags for mapmaking I mean the union of turnarounds, glitches, jumps, bad subscans, etc.
The text was updated successfully, but these errors were encountered: