Open DougBurke opened 5 years ago
The VFAINT
vs. FAINT
part is moot ... the VFAINT
bits aren't set in FAINT
mode anyways; and VFAINT
is a superset of FAINT
What this would do (I THINK!) is to change the behavior of how afterglows are dealt with. This is a longer discussion for a different thread.
Would it affect streaks? Probably not.
No.
The events removed by destreak are not accounted for in the inst map
Excuse me while I :fork_and_knife: :chicken: (git doesn't have a crow emoji).
Digging into the ardlib
code a bit for the recent helpdesk ticket -- you know the one -- it looks like I was confusing two different issues that directly relates to this.
Yes, we will want to include BPMASK=VFAINT
(or probably BPMASK=0x3ffff
) in the detsubsys calls for ACIS datasets. All the other scripts which create responses (specextract
, mktgresp
, ... )
And to add another layer of confusion to all this ...
Yes, the code does recognize VFAINT
and FAINT
and sets the mask as described.
BUT
Way back in 2005 (circa ciao3.2.2) bits 9 & 10, the extra bits included in the VFAINT
were obsoleted. This happened at the same time we went from a 16bit to a 32bit status column.
So indeed programmatically, there is a difference between FAINT
and VFAINT
, practically there is none as those bits are never set (and reading the old emails, should be actively unset if acis_build_badpix
were to be rerun). So that part is moot.
The other part about including the missing bit 17 (new shadow bit) is still relevant.
Looking through http://cxc.harvard.edu/ciao/ahelp/mkinstmap.html#plist.detsubsys made me wonder if we should force
BPMASK=VFAINT
forVFAINT
-mode data in the routines that create instrument maps (and presumably also ARFs).