Dark Field vs Bright Field Relative Study

[STSpencer]

Using current parameter setup, investigate a bright field (Eta Carinae) against a dark field (assuming 40MHz NSB for dark field average) on a relative basis, for the Paranal site with no moonlight on either. Find per pixel brightness and then bin by tray (need new code for this bit).

Given Paranal is UTC-3, parameter values to use:

Common to both: Fov: 10 degrees Fits projection: TAN Gaussian Blurring: 3 pixels (on NSB map not camera, <1 pixel in camera terms) Pixel Size: 0.19 deg Location: SST-1 Paranal, EarthLocation.from_geodetic(lon=-70.317876,lat=-24.681546,height=2176.6*u.m) UTC Time Correction: -3 Model: 'hess_basic' Healpix Level: 11 Min Gaia Mag: 15

Bright field: Source: Eta Carinae RA, DEC (hms,dms): '10 45 03.55;-59 41 03.95' RA, DEC (degrees): 161.265 -59.684 ALT, AZ (degrees): 33.0833 146.699 Observation local time: Time('2022-02-07T01:54:0') UTC time: Time('2022-02-07T04:54:0')

Dark Field: Tycho SNR is out as not visible from Paranal. @RichardWhite109 do you have any ideas of an alternate dark field? Edit: One option is just to stay at same alt and change az at the same time. A field centered on RA,DEC 161.984 -42.958 would have alt,az of 33.08,126.7 and doesn't seem to have any stars > 5 mag in V.

[STSpencer]

Alright, so the first NSB runs for the dark and bright eta car fields described above have been run. The results (including pixel astropy tables in csv) can be here for the on-source Eta Car run, and here for the 'dark field' run at the same alt and time, but a 20 degree different az.

The fields of view look like this for the bright field:

and this for the dark field:

The engineering camera frames look like this for the bright field:

and this for the dark field: .

Binning up by Target module, they look like this for the bright field:

and this for the dark field:

Essentially for pixels, the average intensity goes up by a factor 1.73 between the dark and bright fields, the standard deviation increases by a factor 2.64 between the dark and bright fields, the dynamic range (max-min) also goes up by a factor 2.65.

Similarly, in terms of mean brightness values a TM, the average intensity goes up by a factor 1.74, the standard deviation increases by a factor 4.01 and the dynamic range goes up by a factor 4.57.

Some caveats to bear in mind:

1. This is prod3b CHEC-S on ASTRI geometry and pixel mappings (ctapipe still needs this updating for prod5/engineering camera), but this shouldn't have a huge effect.
2. Field rotation is probably out, but in terms of overall camera averages this should still be ok.
3. The modelling of Eta Car probably isn't sufficiently complex, the gaia data only considers the V band (and in practical terms I guess UV photons would be a significant complication here).

Is there any other analysis of this data that would be useful? If we're satisfied this really is a 'dark field' and it's suitable, what NSB rate would be most appropriate to average by (I'm guessing take the mean of the dark field as 40MHz and divide all the intensity values such that you get values in Hz a pixel).

If not, I'll run an Eta Car field under full moonlight this afternoon for an extra comparison point.

[RichardWhite109]

At least for me this looks pretty good. I think the only question is how representative the dark field is, but the factors between these 2 fields basically imply that if we can meet performance requirements at NSB rates upto ~4 x 0.24 photons ns−1 sr−1 cm−2 (== 40 MHz x 4 = 160 MHz for Prod4 PDE curves) then we're doing fine.

Clearly the 'thing to deal with' is the variation in NSB across the camera in these bright fields. If every pixel behaved well up to 160 MHz though (i.e. no thermal issues, some but not large GxPDExOCT drop) then it should be fine.

For the moonlight - would also be very nice to have. But would go for half moon, not full... this is then basically the requirement "B-SST-1680: SSTs must be capable of gamma-ray observations with uniform night sky background illumination levels up to at least 4.3 photons ns−1 sr−1 cm−2 in the wavelength range 300-650 nm with the Moonlight Reference Spectrum"

[STSpencer]

Alright, I've taken a first crack at a half moonlight run, the results can be found here along with the input parameters. Here's the field in the same format as before:

I guess it kind of comes down to what you're defining as half moon. This run has 0.53 FLI but the moon is quite far away (I'm going to try running more brightness curves using NSB to try and get a better grip on what to set as input parameters), my guess is Lunar separation is going to have a bigger effect than the phase of the moon itself. Also we've not fitted the relative coefficients of sky brightness from the Krisciunas et al lunar sky background model and the gaia data (and I'm not sure we'll be able to until we get an SSTCAM on site), so this is probably not terribly reliable anyway.

[STSpencer]

Alright, I've run timespans for Eta Carinae over a month and over a year.

For a given month, the lunar phase is the greatest influence, but over a year the maximum brightness of the region for a full moon can as much as double based on lunar separation. If we say in a hand waving way that the average peak brightness per lunar phase is about 2000 nLb then the last run should correspond to about 50% moonlight (as much as we can model it with the nsb tool), unless anyone prefers a different definition?

[RichardWhite109]

Sounds reasonable for the moment. In the end we need to understand the definitions Konrad (and ASWG) use. Here:

https://www.mpi-hd.mpg.de/hfm/CTA/MC/Prod4/Config/Threshold/SST-Thresholds.pdf

https://www.mpi-hd.mpg.de/hfm/CTA/MC/Prod4/Config/Threshold/chec-rates-2018-11-07.pdf

they talk about partial moon resulting in 156 MHz for CHEC-S on ASTRI and 750 MHz for full moon. Once conversion between nLb and MHz is sorted out we can see how this compares. Also note that @watsonjj has now confirmed folding the moonlight spectrum with our SiPMs that he also gets 750MHz for the B-SST-1680 Max Observing level requirement (implying this is consistent with the ASWG definition of full moon).

[STSpencer]

I think this issue has largely been superseded by issue #18 so can now be closed.