Closed noralinn closed 11 months ago
issue not very clear - do you mean that the fwhm in header is very larg? Sasha - can you please look into this? p.s. we need to define some tests for the pipeline unitTest... thanks, eran
On Fri, Dec 1, 2023 at 1:23 AM noralinn @.***> wrote:
Does the header of processed images contain the seeing?
I though it was FWHM, but it has a values of 8000 to 11000.
I looked at: /2023/09/16/proc/230207v0/LAST.01.04.01_20230916.230227.695_clear_SN2023ijh_002_001_010_sci_proc_Image_1.fits and other images from the same night.
— Reply to this email directly, view it on GitHub https://github.com/EranOfek/AstroPack/issues/292, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJUQ4NJR3OMSTBTBT6CWCDYHEIQJAVCNFSM6AAAAABAB7FUEWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGAYTSNRXGIZDKMA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Yes, the values are very large. Therefore, I was confused whether it actually is the seeing or has a different meaning. So it is the seeing, right?
These are the FWHM values for M4T1 2023/09/16 cutout 10. The images are ok (processing worked, image subtraction, forced photometry etc. return reasonable results). Maybe just divide by 3600?
Unrelated side note: The figure also shows that focusByTemperature messes up the focus.
For the first group of points the focus is good. Then it's adjusted according to the changed temperature (orange dots indicated the focuser position) and after that it is worse and limiting magnitude degrades by ~0.5mag. There could be several reasons: Either the initial focus was bad or the adjustment was too large. The shown data was taken at the end of the night, so errors in adjustment accumulate over the night, if the focus loop wasn't rerun.
Towards the end of the night the focus improves due to the decreasing temperature, even though the target it setting. (First points were taken for an altitude of 85deg and last ones at 40 deg).
First drop in limiting magnitude is due to the focus problem. The later degradation is mostly caused by the increasing airmass and increasing sky background at lower altitudes.
Development of limiting magnitude with air mass
Does the header of processed images contain the seeing?
I though it was FWHM, but it has a values of 8000 to 11000.
I looked at: /2023/09/16/proc/230207v0/LAST.01.04.01_20230916.230227.695_clear_SN2023ijh_002_001_010_sci_proc_Image_1.fits and other images from the same night.
Hi Nora, For some reason which I will investigate on Sunday, when I am in the office, these numbers appear because the FWHM is effectively multiplied by ARCSEC_DEG = 3600 twice in imProc.psf.fwhm when it is called from pipeline.generic.singleRaw2proc, so the real range is from 2.2 to 2.8 arcsec. I would add, that this FWHM of the PSF is not seeing, but rather an upper limit thereof, because seeing is a characteristic of the atmosphere alone, and what we measure is a combination of seeing and telescope characteristics.
My previous comment was almost right, but now it seems that I have really figured out what's going on. The imProc.psf.fwhm itself is fine, the problem is that it is called in pipeline.generic.singleRaw2proc before the astrometric block and at this point its WCS CD(1,1) = CD(2,2) = 1 instead of ~ 3.5e-4. If I move imProc.psf.fwhm after the astrometric block when the CD values are already defined, it writes the right values of PSF FWHM (2-3 arcsec) into the object's header. @EranOfek , may I improve this in pipeline.generic.singleRaw2proc?
offcourse.
On Fri, Dec 1, 2023 at 9:53 PM Alexander Krassilchtchikov < @.***> wrote:
My previous comment was almost right, but now it seems that I have really figured out what's going on. The imProc.psf.fwhm itself is fine, the problem is that it is called in pipeline.generic.singleRaw2proc before the astrometric block and at this point its WCS CD(1,1) = CD(2,2) = 1 instead of ~ 3.5e-4. If I move imProc.psf.fwhm after the astrometric block when the CD values are already defined, it writes the right values of PSF FWHM (2-3 arcsec) into the object's header. @EranOfek https://github.com/EranOfek , may I improve this in pipeline.generic.singleRaw2proc?
— Reply to this email directly, view it on GitHub https://github.com/EranOfek/AstroPack/issues/292#issuecomment-1836693422, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJUQ4MRUHDKTJAH7E2HCFDYHIYSFAVCNFSM6AAAAABAB7FUEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZWGY4TGNBSGI . You are receiving this because you were mentioned.Message ID: @.***>
will be good to checl aslo the FWHM in the coadd image.
On Fri, Dec 1, 2023 at 10:22 PM Eran Ofek @.***> wrote:
offcourse.
On Fri, Dec 1, 2023 at 9:53 PM Alexander Krassilchtchikov < @.***> wrote:
My previous comment was almost right, but now it seems that I have really figured out what's going on. The imProc.psf.fwhm itself is fine, the problem is that it is called in pipeline.generic.singleRaw2proc before the astrometric block and at this point its WCS CD(1,1) = CD(2,2) = 1 instead of ~ 3.5e-4. If I move imProc.psf.fwhm after the astrometric block when the CD values are already defined, it writes the right values of PSF FWHM (2-3 arcsec) into the object's header. @EranOfek https://github.com/EranOfek , may I improve this in pipeline.generic.singleRaw2proc?
— Reply to this email directly, view it on GitHub https://github.com/EranOfek/AstroPack/issues/292#issuecomment-1836693422, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJUQ4MRUHDKTJAH7E2HCFDYHIYSFAVCNFSM6AAAAABAB7FUEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZWGY4TGNBSGI . You are receiving this because you were mentioned.Message ID: @.***>
I have made the correction in pipeline.generic.singleRaw2proc but pushed it only in my personal branch ak ,and not yet in dev1. Let us train pull requests on Sunday? In the COADD images it is already fine as in pipeline.generic.procMergeCoadd the astrometry is done before the PSF is built.
Does the header of processed images contain the seeing?
I though it was FWHM, but it has a values of 8000 to 11000.
I looked at: /2023/09/16/proc/230207v0/LAST.01.04.01_20230916.230227.695_clear_SN2023ijh_002_001_010_sci_proc_Image_1.fits and other images from the same night.