Single Pixel Investigation

[STSpencer]

The dv-investigations Trello board has a task:

`Histogram of exposed NSB fluxes over a year in a pixel'

This issue is to discuss how to deliver this, and decide what precisely would be useful. NSB has a built in tool through the model.CalculateTimescale() method that makes plots that give the brightness in nLb of a particular source on the sky over a timeframe given a moonlight model, like this one for the Vela Pulsar:

However what NSB doesn't have is a built in method for calculating the flux in a SiPM pixel, which is an integral over a finite angular extent on the sky (~0.2 degrees, which is >> bigger than the angular extent of a singular star on the sky). The problem is to calculate that at any given moment in time, you have to generate an fov map, and then use the photutils camera photometry code. For calculating an entire camera worth of pixels, this takes ~8 hours a time to generate, so doing this for an entire year of observations at ~20m time resolution (which seems to be ~the time for a cluster of bright stars to move out of a pixel) is probably computationally prohibitive.

An alternative would be to just simulate one pixel or target module's worth of sky fov, which would cut down the computational cost significantly. But to do this, one would need to write a scripts that automates the generation of a my_config.cfg config file for a particular source, calculates the correct pointing alt and az using astropy (or you could just point at one alt/az all year), and writing the time string in the correct format for a given time interval, generates the fov using nsb and then extracts the pixel brightness using something resembling the pixel brightness extraction in from_fits.py, then save the results to an array/disk. All of this assumes issues #1 and #3 have been solved, but there would be some bespoke scripting required to generate something like this to begin with.

Is this useful, or are the NSB timescale plots enough for chosen sources and parameters? Presumably there's a bit of variance depending on zenith angle and the position of the pixel in the camera.

[STSpencer]

Alright, from the call this morning, it sounds like the sky brightness results from nsb's timescale mode (or some analysis based on the arrays it generates subject to differing moonlight conditions) are going to be enough. This then returns to being a mixture of issues #1 and #3, determining model parameters and sources, albeit analysed in a different context. However I still think issue #8 (auto-generating config files) is worth doing just to cut down the number of free parameters in runs of NSB and make it easier to reproduce results.

[STSpencer]

Given that we appear to be reasonably happy with the NSB Hz conversions using the mean method, I thought it time to revisit the 'timespan' plots for Eta Car. Unfortunately, using the conventional mean method nLb conversion in #17 yields quite low values (in the kHz) probably because the brightnesses produced by the timespan code aren't an integral over a patch of sky.

The obvious decision is to treat these timespan plots as relative brightnesses, and scale them to the mean Hz rates obtained with the whole camera observations. The question then becomes how to do that fairly; here I've scaled the mean brightnesses to the pixel mean of the 'typical' eta car observation (75.96 MHz) and it seems to work reasonably well for a month and a year:

[STSpencer]

I've run the single night extreme case scenario requested by Jason on the call on Tuesday, this is a 24 hour timespan at 1 minute resolution for the night of 2022/05/15 (the brightest the Eta Carinae region gets during 2022).

(https://github.com/sstcam/sstcam_nsb/blob/main/results/timespans/timespan_Hz_daylongmin_etacar_brightness.npy is the equivalent brightness numpy array). It winds up that this becomes quite strongly dependent upon which normalisation you choose. There are two options I can see, normalise based on the mean of the brightness array, or it's minimum . So far, for the mean brightness normalisation we've used: brightness = brightness * norm/np.nanmean(brightness) Alternatively you can use the minimum of the array: brightness = brightness * norm/np.nanmin(brightness) I think the minimum value method is probably more appropriate given the circumstances so that's what I've used, and this winds up getting more consistent results with the longer term timespans. Either way you get the increase in Hz as a function of time, but the absolute values change. For the normalisation I've chosen 135 Hz as that's the average brightness of the region that week.

[STSpencer]

The same data for 2022/05/15, but now max normalised to the maximum Hz value from the year long timespan plot. It looks much nicer and more consistent with the year long plots. The associated numpy array is here. Note that this still relies on assuming our original eta car run for the entire camera was a 'typical' observation.