This page archives Slack comments from the focused discussion on persistence during the Improving JWST Data Products Workshop (IJDPW).
Harry Ferguson
Regarding persistence -- bright snowballs leave persistence that can show up in subsequent images and isn't caught by jump detection. The persistence signal looks a lot like a faint galaxy.
Yanu
@James Davies snowblind has an algorithm to flag those if you supply the list of subsequent images
Mario Gennaro
The Jupiter "offense" is something that the NIRCam team is trying to work on. We originally didn't conceive any specific mechanism for identifying "bad actors" and/or "sensistive observations" (like HST/WFC3 instead does). The rationale was that the e-folding time for NIRCam persistence was considered to be very short. Now, from preliminary analysis, our longer tau is of the order of ~1000 seconds (give it or take). That is not bad, but when you have HUGELY saturated observations (like the Jupiter ones in question, which, BTW used F150W2 and F322W2 to observe rings/moons, hence didn't care that the planet itself was going to overwhelm the pixel full-well) even 1000s are not enough.
We are working on scheduling mitigation strategies that would avoid that in the future. While the solution has not been fully identified yet, options include creating "buffers" after BAD ACTORS and/or prior to to SENSITIVE observations. This deals with persistence from without a given program. We are also working on a tool to predict self-persistence (ie from previous dithers/mosaic tiles from the same observation/program). This latter effort could lead to eg optimized dithers/PAs/expsoure parameters, but obviously if one has to observe a given patch of the sky becuase, you know, it's their target, there may not be a perfect solution to completely avoiding self-persistence.
Mario Gennaro
@Benjamin Johnson when you mention "improved persistence flagging" I am guessing you mean:
- have a model of the decay of persistence with time, possibly per pixel (calibrated eg on bright fields folllowed by draks - which is what we are doing in our NRC CAL program for persistence)
- measure fluxes in your exposures i=0,...m
- from each of the above predict the "persistence flux" for pixel (x,y)_j in exposure m+1
- set an acceptable threshold (eg 10% of the background or whatever is suitable to the specific science)
- FLAG those pixels (ie do not use them for that specific m+1 exposure)
I think that approach is viable. This was done in eg WFC3/IR with the persistence products (and it is something that our tool of my comment above may be able to achieve).
What I am less optimistic about is to use the above model to actually "recover" the pixel.
Benjamin Johnson
yes, thank you.Ya I agree that recovery is a big lift, treating decay of the persistence during the ramp fitting would likely be quite difficult, plus other difficulties I am probably missing.
Gabe Brammer
Another sneaky persistence effect I noticed was in the first exposures from the GLASS ERS program, e.g., the F090W visit jw01324001001_02201
with EXPSTART = 2022-06-28 22:04:43
. Prior to that exposure was a long stare at the LMC with NIRSpec https://www.stsci.edu/cgi-bin/get-visit-status?id=1133&markupFormat=html&observatory=JWST., where the last exposure had EXPEND = 2022-06-28 21:17:16
. Would NIRCam have been continuously flushing during that time?
Mario Gennaro
unless there was a parallel, yes
10.7s full frame idle reset
but no DARK in place
Gabe Brammer
For what it's worth, that type of persistence will never be recorded in, e.g., trapsfilled files because there were never any reads downlinked.
Mario Gennaro
indeed. One could perhaps model the exact pointing, use a 2MASS image+catalog and predict persistence from observations prior to yours (like you did for WFC3...which what we are trying to do for NIRCam as well!)
but you did that on a generic rectified grid, so again, one can use that approach to have a order-of-magintude prediction in a simil-NIRCam detector, but doing that EXACTLY and pixel-by-pixel would be quite the challenge