This page archives Slack comments from Day 2, Session 1 of the Improving JWST Data Products Workshop (IJDPW).
Jeff Valenti - @Michele Perna or pipeline exerts - how does it happen that the leak image is subtracted from one part of the image but not another?
Dries Van De Putte - @Michele Perna Is the MSA leakage in the same place every time, or do you need to flag different regions for each target?
Anil Seth - I have this same question, and if the answer is yes, would it be possible to create a mask for this and implement a dither stategy that would remove the need for leakcal exposures?
Howard Bushouse - It's my understanding that the MSA leakage exposures capture not only signal coming through stuck open shutters, but also slight leakage through closed shutters, because they aren't 100% opaque. Hence that would change depending on where the bright sources are in the field and hence how much leakage gets through the closed shutters.
James Davies - Is the advantage of masking instead of subtracting the leakcal/imprint image pixel-by-pixel is that subtracting adds to much pixel-to-pixel noise?
Anil Seth - Agreed @Howard Bushouse, but there are situations (in relatively blank fields) where this might be a minor issue.
Michele Perna - We don't have leakage exposures in our program. this is the reason why we are removing those pixels instead of correcting them. but I think that even with leakage exposures the subtraction works well only for one dither position, not for all.
Howard Bushouse - That makes sense that you would ideally get a leakcal at each dither position, because the contamination will move with the dithers.
James Davies - @Michele Perna Did using lacosmic on the very undersampled NIRSpec psf/lsf produce any difficulties?
Michael Regan - @Michele Perna When comparing your method to the NSClean method how do we know which is correct?
Michele Perna - In the presentation, I used as a reference the trend expected for background emission.
Jeff Valenti - @Michele Perna - Is outlier detection in version 1.11 of the STScI pipeline similar in quality to OD in your pipeline or worse? I thought maybe you said they are equivalent, but the 1.11 result seemed to have outliers remaining.
David Law - Tacking this comment on here: The STScI IFU pipeline changed a few months ago to using a pixel-based outlier detection similar in concept to lacosmic, do you have a feeling for how the results of this updated pipeline compare to the outlier detection that you've been using? Edit: Never mind, answered by a slide!
James Davies - @Michele Perna The wiggles due to the spatial undersampling seem to depend on whether you have a point source or not. Does extended emission show the same amplitude wiggles?
David Law - @James Davies - See also A 3D Drizzle Algorithm for JWST and Practical Application to the MIRI Medium Resolution Spectrometer
James Davies - Thanks @David Law
Michele Perna - Good question. wiggles are also observed (at lower level) in post-SB galaxies. hope that they are still originated by an unresolved stellar component.
Anil Seth - One other question for @David Law and @Michele Perna, do the wiggles in MIRI datacubes come from the same source as the NIRSpec ones (i.e. the resampling of curved traces on the detector)?
James Davies - @Anil Seth the paper David links above in this thread is a really good discussion of exactly this in MIRI.
David Law - @Anil Seth - Yes, same general idea. There's an appendix in the paper linked above that does a quick test for NIRSpec data too. The magnitude of the undersampling is different though.
Timothy Brandt - @Michele Perna Can you diagnose the origin of the outliers? Do those pixels look strange on the individual group level?
Michele Perna - I never looked at individual group levels. I'd say that most of the residuals in the cube obtained applying the OD algorithm in v1.11.0 are bad pixels (they appear in groups, following the dithering).
Anil Seth - @Michele Perna related to the wiggles — the challenge I see is that your method assumes an object’s spectrum is spatially invariant (or that you can mask differences). Would it be possible to use star measurements/measurements where the spectrum is uniform to characterize the wiggles and use these to correct other data, or is it highly sensitive to the exact position of the point source?
Michele Perna - I think it is sensitive to the exact position of the point source. not sure about this, but I would also expect a dependence with the curvature of the spectra on the detector. However, the assumption of a uniforme spectrum works well in the surrounding of the brightest pixel (at the position of the star or AGN), which are also the ones with strong wiggles.
Jeff Valenti - @Melissa Shahbandeh - What are the stripes in Ch 4 that remain after subtracting the thermal background?
Melissa Shahbandeh - The stripes are the 2 detectors' plains (long and short) overlaid.
David Law - @Melissa Shahbandeh Can you comment on the approach that you used for masking your science sources when creating your in-field background?
Melissa Shahbandeh - We used the weightmap, we made the weightmap of the science to be zero when extracting a background region.
Ori Fox - One additional thing you’ll see from the advanced notebooks is that we can draw regions to exclude in JDAVIZ’s Cubeviz. Selecting regions is not trivial and needs to be done on a case to case basis.
James Davies - @Melissa Shahbandeh Really cool method for background subtraction. Have you tried subtracting the background in the _cal files (the slice images) by making a mean or median of all slices images by mapping those 40 regions in the cube back to the slice images (_cal) via the WCS?
Melissa Shahbandeh - Thank you, we have tried it for the cal files but since each cal file includes part of short and long detectors (producing partial spectrum), it makes it difficult to take the median of background spectra at the end since it causes some flux calibration issues between different channels. However, we are working on using WCS for region selection using the cube file.
Jane Rigby - When users are subtracting the background, are they also increasing the uncertainty array to account for the poisson noise in that background?
Melissa Shahbandeh - No, I will look into that, thanks for your comment Jane.
Ori Fox - @James Davies, we are working with some experts internally to actually create a 2D fit across the entire slice. Initial tests seem to indicate this may be the best combination of methods.
Jane Rigby - @Melissa Shahbandeh, My experience w Spitzer is that that poisson source of noise was NOT added to the uncertainties by default, and was often the leading noise source.
James Davies - @Melissa Shahbandeh and @Ori Fox, I’ll put a small example here of computing a mask in the _cal slice image given some knowledge of your background area in the _s3d cube. MIRI MRS data has WCS objects that are really easy to use. Here’s I’ll use some LMC commissioning data from program 1171. First we do imports and download a _cal file
You can write out this boolean array as a fits file and blink with the _cal data. Should be a nice representation of where the data slices are. Here’s what it looks like.
But this mask still includes the source, and we want just the background. So let’s make a mask of where the source is. We’ll get its location from the built cube collapsed in wavelength. and we’ll figure out its extent in arcsec. I’ll leave that as an excercise to the user using ds9.
Note that in this 2nd case, it will also mask the slices, just as we did above. Here’s what those 2 masks look like:
And as you can see, we now have all the information we need to create a mask where the background area is set to True and use such as mask to do a weighted average of the stack of all our input _cal images.
For NIRSpec IFU it’s a little trickier, as you have to make a mask for each slices and | them together, as there’s a separate WCS for each slice. But same basic idea.
Macarena Garcia Marin - @Amélie Canin for choosing between additive and multiplicative, do you have some overall guidelines? I am thinking of a potential pipeline integration, where the decision has to be made automatically.
JD Smith - The problem with not knowing whether offsets between spectral segments are additive or multiplicative in nature is that choosing incorrectly can lead to highly non-physical band or line ratios across the stitch position, especially when that occurs in spectral regions with weak continuum (10µm in galaxies, for example). There is a “true” answer, but it usually requires scientific and other arguments to arrive at.
Nimisha Kumari - I agree with the speaker that the decision (additive constant versus multiplicative factor) should be made based on your science case and inspection of data, e.g, in the emission line spectroscopy, if you aim to measure the line fluxes, an additive constant is going to be subtracted (as part of continuum subtraction) without changing the measured flux, however a multiplicative factor is going to affect the measured flux. So, I don't think that we should have a default additive constant or multiplicative factor in the pipeline "unless" there is an instrument/detector level cause which driving the offset. (@Jeff Valenti asked me to write my response here)
David Law - @Amélie Canin Great presentation; the pipeline can also produce 5-28 micron cubes directly from the 2d data on the Ch1 spatial sampling scale, do you have a feeling how the results compare? How do you handle the artificial structures produced by resampling onto spatial/spectral voxel scales substantially below the native detector sampling?
Amélie Canin - Was my oral response enough?
David Law - Thanks- sounds like the main issue is if flux level stitching between bands is needed. I'd be interested to know if this is less necessary with the latest set of flux calibration updates, although there will likely always be at least 1% differences from various detector effects. My concern on the resampling is that there are no good sampling choices for full-wavelength data given the large differences in both PSF and native detector/slicer sampling. I.e., if you drizzle things onto a grid far below the true sampling you have enormous covariance and can produce spurious features. We tried working around that in the pipeline 5-28 micron cubes using nonlinear wavelength solutions, but the cube format doesn't accommodate changing spaxel scales with wavelength.
Michael Regan - For small offsets it doesn’t matter if you add or multiply. Only the second order term in the expansion matters.
David Law - As mentioned by a couple folks, what the 'right' thing to do is depends. Scaling offsets are produced by any errors in the flux calibration, which should be quite small with current CRDS 1147. Flatfields errors could affect this though too. Shift offsets will be from imperfections in the background subtraction, and will be more noticeable at long wavelengths. Both can interact with each other in unpleasant ways.
JD Smith - But “small” is a fractional concept (5% fine, 50% scary). For certain objects in some spectral regions, the continuum drops to near zero. So scaling a segment to stitch well, when the true offset was additive, can produce highly unphysical spectra, line ratios, etc.
Michael Regan - True, I made an assumption that the offset is small in both absolute and relative terms.
JD Smith - When continuum goes near zero it’s hard to be fractionally small.
David Law - @Jean-Baptiste Ruffio Really awesome to see how well the detector-based point cloud extraction and forward modeling for NIRSpec IFU data is working out!
Michael Regan - @Jean-Baptiste Ruffio How much improvement would there be with more uniform spacing of the point cloud?
Jean-Baptiste Ruffio - Yeah it's a good question, I don't have a number, although that could likely be characterized. My guess is that, to zeroth order, the systematics are proportional to the undersampling, so if you improve your sampling by a factor 2, you reduce your systematics by a factor 2? but would need to be looked at in more details (edited)
Actually, I think David's plot answers this question. Going from 1 to 4 dithers (sampling improved by a factor sqrt(4)=2) does seem to reduce the systematics by ~x2.
Thomas Vandal - @Jean-Baptiste Ruffio How constrained are you by the primary spectral type, vsini, as well as RV and spectral type difference with the companion, for it to be easy to disentangle? I guess the requirement depends on contrast too? ( How well would this work for short-separation M dwarf + Giant planet, or brown dwarf binaries)
Jean-Baptiste Ruffio - Yeah, unfortunately I did not have time to dive into the detailed of the modeling. We derive an empirical model of the starlight directly from the same exposure, so the model is pretty much as accurate as you can be. As long as your companion has different features than the host, you should be able to detect it, this would need to be looked at in a case by case basis of course. We did look at the dependence of the companion temperature in figure 14 of JWST-TST High Contrast: Achieving direct spectroscopy of faint substellar companions next to bright stars with the NIRSpec IFU, but that's not as challenging as what you have in mind. I think it depends how similar you think your host/companion pair will be.
Thomas Vandal - Thanks! I'll have to read the paper more in depths but this is very interesting!
Anil Seth - @Jean-Baptiste Ruffio Sorry if I missed this, but I think you used WebbPSF to model the star? It sounded like Michele Perna was showing quite a bit of difference relative to WebbPSF. Do you have ideas on how to improve this?
Marshall Perrin - Yes. @Jean-Baptiste Ruffio and I are co-PIs leading the cycle 2 GO CAL program to obtain high quality empirical PSF calibration data for the NIRSpec IFU. This is one of the datasets that Michele Perna mentioned is upcoming for PSF calibration.
Anil Seth - When will the data be taken? (Or what is the PID?)
Marshall Perrin - pid 3399, coming this spring in Feb-April (exact dates still TBD but that’s the window).
Marshall Perrin - My guess is a substantial part of the difference between current webbpsf models and reality will turn out to be the detector effects (charge transfer, IPC, etc) since those turned out to be the dominant missing systematic for imaging modes. That will almost certainly be a big part of it. But then there is the complex effects of the image slicer on the optical quality, for which the existing ground calibration data is not sufficient to model at high fidelity. The in-flight calibration is definitely needed for that.
Anil Seth - A related question @Marshall Perrin, how much do you think the disperser matters? I.e. are stars taken in lower spectral resolution modes useful for PSFs from the higher spectral resolution gratings?
Marshall Perrin - :shrug: don’t know yet! Excellent question and worthy of investigation, in both directions. On the optical side it should in principle be the case, but (a) the different dispersion patterns will inevitably result in different impacts of the detector systematics, (b) the gratings themselves introduce some pupil plane wavefront error. So it is probably more complicated than we would like. The program 3399 calibration plan is only for the high res gratings, so we were planning to try to bin those down to provide medium and prism PSFs… but it’s TBD how precisely that will work or not.
Anil Seth - I have data in the same filters, so it’ll be useful for me! Thanks for getting this.
Thomas Vandal - @Jean-Baptiste Ruffio I saw that you greyed out within 0.3 arcsec in the contrast curve but mention it's theoretically possible in the paper. What are the main blockers to access these shorter separations?
Jean-Baptiste Ruffio - The starlight model is derived empirically from the same science exposure, this is the best way to get the most accurate spectrum of the star which you need for photon noise limited detection. For this first analysis, we effectively combined everything in the FOV, but if you had a companion really close to the star, then your starlight model would start to include more and more planet signal. This would lead to self-subtraction later. In the extreme case, if your planet exactly overlaps with the star, you would not be able to detect it at all with this exact implementation. Something you could do to get closer than 0.3'' would be to mask the assumed companion location before computing the empirical model of the star, this would allow you to get closer than 0.3'' although still not exactly 0''. If the planet is too close to the star, your only hope is to use a theoretical model of the stellar spectrum (you can no longer use an empirical one), but how well you can do this is unclear to me.
Greg Sloan - @Jean-Baptiste Ruffio - No question here. Just a comment. I really like the point-cloud approach. We've talked about this on the MIRI team. My philosophy has always been that as soon as you've resampled, regridded, interpolated (or whatever), you've mixed information from two or more pixels. The egg is broken and you cannot go back. The pipeline is full of resamplings, and going back to data as it appears on the detector can always help.
