Add stars to NSB maps / Validate against sstcam-sandbox Draco field

[STSpencer]

It would be good for the camera fov plots to have the brightest stars highlighted. Add an overlay that queries gaia for the n brightest stars in a field and plots their position in the camera plane.

• [x] Run Draco field through nsb fits generation.
• [x] Note to self. Reminder to double check the observation height for Cerro Paranal observations in fromfits.py in the location description, might help with star positions a bit.
• [x] Also double check the potential effect of using skycoord from_name as opposed to specifying the ra dec manually.

[watsonjj]

Something similar was done in the slow-signal pointing calibration (I think I already gave you this notebook): https://github.com/watsonjj/sstcam-sandbox/blob/master/sstcam_sandbox/d190607_pointing/engineeringv2.ipynb

It would be a good idea to look at the same star field with your tool, and check the FoV matches to the one in this notebook (as a crosscheck).

[STSpencer]

Part of the issue here is validating the PSF of the instrument, i.e. does one star's brightness extend over multiple pixels in the field.

[RichardWhite109]

There are more detailed studies - but Figure 7 in this document shows that the PSF is basically always within a pixel. There's also an image of polaris in that document somewhere... if we need to smear the image, then likely only such that ~10-20% ends up in neighbouring pixels... and that's most important off axis. SST2M-RfI_FollowUpQ_v1.5-Submission.pdf

[STSpencer]

There are more detailed studies - but Figure 7 in this document shows that the PSF is basically always within a pixel. There's also an image of polaris in that document somewhere... if we need to smear the image, then likely only such that ~10-20% ends up in neighbouring pixels... and that's most important off axis. SST2M-RfI_FollowUpQ_v1.5-Submission.pdf

Ok, good to know thanks. I suspect the current sky brightness model is only going to be correct up to factors of order unity as we don't yet have a good grip on the p0,p1 and p2 parameters defined in #1 (this would need to be fit to HV data). So in the Draco slow chain data Jason's shared:

is the spreading out of light from the stars due to the longer exposure and tracking errors rather than the PSF of the ASTRI optics? Or are there multiple bright stars within the circled regions?

[RichardWhite109]

is the spreading out of light from the stars due to the longer exposure and tracking errors rather than the PSF of the ASTRI optics? Or are there multiple bright stars within the circled regions?

This can be a few things:

• Misalignment of 1 or 2 mirror segments at the specific time we used the telescope (as opposed to when the last aligned it).. this is very likely I think
• Camera being not quite at the correct position (out of focus) (1 mm --> 10% PSF change)... could well be
• Cross-talk in the camera (could be there at the few percent - 10% level perhaps)
• Some residual effects in the SiPMs when a star leaves (e.g. SiPM heats up, gain changes, takes a while to return) (I guess this one is unlikely).
• Can also be that the star is actually between pixels...
• Not sure about the exposure times here - but you could be correct...
• Final one: light can leave an an SiPM, hit the inside of the window and then bounce to a neighbouring pixel. I.e. Akira's thing

[STSpencer]

@watsonjj I'm having some problems with this, whilst the star positions look correct in the images, I've don't get any hotspots corresponding to the bright stars in the images made by NSB/my photutils code.

I think you were right yesterday in that it could just be that I'm just looking at the wrong patch of sky; I'm using the time/coordinates from https://github.com/watsonjj/sstcam-sandbox/blob/master/sstcam_sandbox/d190607_pointing/engineeringv2.ipynb along with astropy to calculate the RA and DEC. I've treble checked and the values are set to these in all the places they're meant to be (and I've also checked it's not something really daft like dates being in the wrong format for different packages). This is the astropy code I'm using:

from astropy.coordinates import EarthLocation, AltAz, ICRS
from astropy.time import Time
import astropy.units as u
import numpy as np

loc=EarthLocation.from_geodetic(lon=14.974609, lat=37.693267, height=1750*u.m) # ASTRI Site Coordinates                                                                                                  

obsalt=73.21*u.degree
obsaz=0.5*u.degree

starttime=Time('2019-05-09T01:37:54.72806')
aa=AltAz(alt=obsalt,az=obsaz,location=loc,obstime=starttime)
coords=aa.transform_to(ICRS())
print(coords.ra.hms,coords.dec.hms)
print(coords.ra.deg,coords.dec.deg)

Which returns the values

hms_tuple(h=17.0, m=44.0, s=44.07090155746744) hms_tuple(h=3.0, m=37.0, s=58.06248275387105)
266.1836287564894 54.49192701147445

Do you have any way of double checking if this time/location/set of coordinates is correct? I only ask as it seems the Draco constellation is at ra=17h dec=+65 (aka 255,+65) deg which would seem to be out of the field of view (according to wikipedia).

[RichardWhite109]

Could it be something simple like the time zone? i.e. are you + or - 1 hour out? Maybe just try starttime=Time('2019-05-09T00:37:54.72806') and starttime=Time('2019-05-09T02:37:54.72806')

[STSpencer]

Could it be something simple like the time zone? i.e. are you + or - 1 hour out? Maybe just try starttime=Time('2019-05-09T00:37:54.72806') and starttime=Time('2019-05-09T02:37:54.72806')

I'll give it a shot and see what happens.

[STSpencer]

Something odd's going on here. I've been running runs with exactly the same parameters (for source RA DEC/obs altitude, the astri site and azimuth) but different times. The run for Time('2019-05-09T00:37:54.72806') works fine, albeit the stars are still out of place: But the run for Time('2019-05-09T02:37:54.72806') fails completely, with NSB claiming the sun is above the safety threshold of (-18) degrees and is at -14 degrees alt. Now I've tried changing that value, but NSB still fails, making me think it's hardcoded in somewhere too.
Now at local time 02.37, the sun should be well below the horizon,

making me think that in fact I'm two hours out because of the Italian time zone. I'm going to try that now, plus check the source code for nsb for anything unintentionally hardcoded.

[STSpencer]

Alright, I might have found another problem. NSB has a well hidden maximum magnitude setting (that's hardcoded in) which is currently set at m_V=3, but two of the Draco stars are brighter than that, and I'm not sure they're being plotted. I'm going to try increasing it to -2.

Edit: So the reason the gaia catalog doesn't go to mag -2 is because gaia didn't map stars up to mag -2, it only mapped them to mag 3. The way the non-gaia stellar data is combined with the gaia data is a potential source of bugs.

• [x] Double check for potential sources of bugs related to final entry in ducaticat.txt not being mag.

Edit 2: Doesn't look like mag column is the problem. Homogenising the data files for the mag>3 and mag<3 stars doensn't seem to change the final outcome, despite the fact that the diffs of the healpix maps change. Results in results/dracomaxmagneg2 match those (earlier catalog version but same field/parameters) in results/dracoutc

In particular I'm struggling to understand what the bright source at the centre of the intensity map is meant to be, I thought it might be NGC6426, but it seems odd it's ~an order of magnitude brighter than anything else in the field. Here's the associated fov map:

(This is unusual, in say the moonlit run of Eta Carinae I ran (results/EtaCarinae_nightmare), the fov map matches quite well the skyframe, integrated pixel map. This could be a moonlight/background scaling issue).

• [ ] Investigate further origin of bright feature in Draco map.

That said, it's also odd that I can't clearly make out any bright constellations in the allsky maps:

Potential sources of all these issues:

• [x] Also double check effect of else statement on L169 of nsb/gaia/create.py getSurfaceBrightness being set to 100. (This makes no noticeable difference)
• [ ] Investigate deeper potential assumption issues, check further records with HESS.

[STSpencer]

@watsonjj I'm having some problems with this, whilst the star positions look correct in the images, I've don't get any hotspots corresponding to the bright stars in the images made by NSB/my photutils code.

I think you were right yesterday in that it could just be that I'm just looking at the wrong patch of sky; I'm using the time/coordinates from https://github.com/watsonjj/sstcam-sandbox/blob/master/sstcam_sandbox/d190607_pointing/engineeringv2.ipynb along with astropy to calculate the RA and DEC. I've treble checked and the values are set to these in all the places they're meant to be (and I've also checked it's not something really daft like dates being in the wrong format for different packages). This is the astropy code I'm using:

from astropy.coordinates import EarthLocation, AltAz, ICRS
from astropy.time import Time
import astropy.units as u
import numpy as np

loc=EarthLocation.from_geodetic(lon=14.974609, lat=37.693267, height=1750*u.m) # ASTRI Site Coordinates                                                                                                  

obsalt=73.21*u.degree
obsaz=0.5*u.degree

starttime=Time('2019-05-09T01:37:54.72806')
aa=AltAz(alt=obsalt,az=obsaz,location=loc,obstime=starttime)
coords=aa.transform_to(ICRS())
print(coords.ra.hms,coords.dec.hms)
print(coords.ra.deg,coords.dec.deg)

Which returns the values

hms_tuple(h=17.0, m=44.0, s=44.07090155746744) hms_tuple(h=3.0, m=37.0, s=58.06248275387105)
266.1836287564894 54.49192701147445

Do you have any way of double checking if this time/location/set of coordinates is correct? I only ask as it seems the Draco constellation is at ra=17h dec=+65 (aka 255,+65) deg which would seem to be out of the field of view (according to wikipedia).

So I think there's a multitude of issues here, I was getting astropy declinations in HMS when in fact NSB wants them in DMS, which combined with timezones meant draco was out of position.