We need a new name for the overall mapmaking flags

[chervias]

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.

[mhasself]

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

[msilvafe]

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

I see your point Matthew, but doesn't the end result mean that the samples are excluded from the map regardless? All fourier filtering and gap filling happens before this flag union step in the SAT filter-bin processing does the ML-mapmaker internally do some gap filling + Fourier filtering itself and so we need to keep these two separate flags for that case?