We now have calculated Strehl ratio for four OSCO frames and they are summarized in the following table.
|| UT Date
|| Science Image #
|| Background Image #
|| Oct 17 2019
|| Dec 12 2019
|| Dec 12 2019
|| Dec 12 2019
Notes for the table:
- SE refers to results from Steve Ertel's Python code.
- DH refers to results from David Hiriart's C code.
- EL refers to results from Arcetri E-lab IDL code.
- To reconstruct the exact file name referred to in the table, convert the UT date to a number string (e.g., Oct 17 2019 -> 20191017), convert the image number as four digit string (e.g., 16 -> 0016), then concatenate instrument, UT date, image number together with a dot. For example, the exact science image file in the first dataset is: luci2.20191017.0016.fits.
- A failed calculation indicates that the program crashed during the calculation, or otherwise did not terminate, or give a reasonable result. It is likely due to a programming bug, or incorrect handling of the input fits files.
Oct 17 2019 notes:
We performed DX-AO-OSCO in evening twilight and it was successful*. With the highly
variable seeing, I could not keep the loop closed for the entirety of the LUCI script. I was able
to optimize gain, close loop, then manually ramp down gains to keep it closed.
Lucky for us there were clouds preventing twilight flats last night so Steve made another
OSCO attempt. Again the seeing was variable and the the loops wouldn’t stay closed, but we
got at least one image with better correction than the previous night, with a FWHM of 8x10
pixels (luci2.20191017.0016.fits). Still, the peak counts were just short of 400 ADU. By my
estimate we need to go 2.5 mags brighter to get good counts (a diffraction limited PSF would
then give 15k, a poorly corrected PSF 3k). This would put us at H=5th mag stars. If this
is the case we’ll have to move away from the G type R-H=0 stars since there are only 3 of
those with positive declination and the WFS is quite happy with R=7.5. If we go with K stars,
(R-H=2.5) we can have R=7.5 on the WFS and H=5 on LUCI. There are 37 such stars with
positive declination. How do we feel about this?
Dec 12 2019 notes:
- science image: luci1.20191212.0149.fits
- background image: luci1.20191212.0150.fits
- Strehl calculated: 0.3466829573094878
- science image: luci1.20191212.0156.fits
- background image: luci1.20191212.0159.fits
- Strehl calculated: 0.17649353284986405
There seems to be some reflection in the images around the star though.
Some frames have declared different dither locations (via the ’TELRA’ and ’TELDEC’ key-
words), however the star appears to have not moved (enough) in the image. For example:
luci1.20191212.0157.fits and luci1.20191212.0158.fits. Running the background subtraction will
cause problems and lead to failed or wrong results (such as Strehl > 1).
Some frames such as luci1.20191212.0164.fits to 0166.fits are small cropped star images.
Some frames are multi-frame images such as luci1.20191212.0167.fits that has 10 sub-frames
of the star. Though some of these multi-frame files do not seem to contain anything inside, such
Dec 22 2019 notes by Steve:
The automatic bad pixel finding routine of my code does not work well on LUCI images as they are not as oversampled as LMIRCam ones. Also looks lile LUCI images are free enough of bad pixels that this is not required, so using a static bad pixel map later on or turning off bad pixel correction all together are both acceptable options. Once I turned off bad pixel correction, the results from the two data sets using images 149 & 150 and images 156 & 159 on Dec 12 2019 were much closer to each other. In addition, I implemented a Gaussian fit to the observed PSFs to better determine the peak of the PSF. This didn't change things much, but is the better way to do this in any case.
I updated the table above with my new easurements. They are still below the results from the C code, but I am guessing that this may be an issue with the results from that code (not the code itself): I attached below a curve-of-growth plot of source counts vs. photomwtric aperture. One can see that the photometry converges well, but only at a radius of approx. 100 pixels. That means there is a significant halo around the source as can be expected from imperfect AO correction that would result in a Strehl ratio around 50%. The ghost is certainly a part of it, but other light is also seen in a hard stretch of the image. I can see from Al's config file for his C code runs that this was using only a photometric aperture radius of 20 pix, so it must have missed a significant amount of source flux in the extended halo. It seems plausible that this is the main source of the discrepancies now. My suggestion for the next step is thus to re-run the C code with a significantly larger aperture (e.g. 100 pix) and see if the result is closer to what my code produces. I already tried the opposite thing and checked what my code would produce with a 20 pix aperture and found Strehl values very similar to the ones from the C code (withing a few %).
This shows that an aperture small enough to exclude the ghost is not adequate to compute a correct Strehl. We'll need to understand how to best deal with this in that case: measure a Strehl that is wrong by up to 30% because it excludes a goof part of the soruce flux or measure a Strehl that is off compared to the Strehl of the science data by some amount (to be determined) because it includes the effect of the ghost that is not present in science data. The former would be too optimistic, the latter too pessimistic.
I also updated my code to work with image cubes by median combining all images in one cube to a single one. Another issue with images 167 & 168 on Dec 12 2019is that the subframe is smaller than the image size I used to cut around the star, so I had to change some parameters in reduce.py. This is not ideal and I did not save this. So the updated code (sent back by emil to Al and Yang) will still not run on these images. Furthermore, I found that the curve-of-growth photometry for these data does not converge in the subframe that is available (see below), so that my code does not compute a good Strehl. I don't see how any other tool computes a reliable Strehl on this, so I don't think the ELAB result can be better, but I'm curious to be proven wrong. In any case, for completeness, I list my result for these frames in the table above as well. The difference between the ELAB Strehl and mine for these images is of the right size to be plausibly explained by an aperture size difference if ELAB uses an aperture around 10-20 pixels.