VSS Campaign to observe U Leo

I took 100 minutes of unfiltered 30s images in the wee hours of 2020-01-20, though the SNR is so low that to get adequate SNR they will probably have to be co-added a few at a time. Another run took place on 2020-01-04. They, as well as some precision photometry in Johnson V and Sloan r´, still need to be processed. Perhaps this data is too early for the INT run; I will try to take some more in the next few weeks.

A question arises from our earlier discussion in the forum about the use of non-standard sequences for VS observations to be submitted to the BAA-VSS database. There is no standard sequence for unfiltered data. Advice would be welcome, whether here, in the original thread, or off-line via email. Another case without any standard sequence concerns the observations of AT 2019xim reported on my members page.  I have specifically withheld submission of the results for this reason.

OK, CV it is then. The sequence for AT 2019xim must have been added after I took the data, which is not surprising.  My observations were completed within 48 hours of the ATEL being released.

My SOP for all variables except the very brightest is to take 30-second subs and stack in real time.  That way I can estimate the SNR and move to another object when it is high enough or very obviously too faint to be measured with sufficient precision. Stars which can vary by several magnitudes between successive observations can easily turn out to be saturated or invisible if purely dead reckoning is used to set exposure lengths.

“Given this star is rather faint, at mag 17.3, it is a target for CCD observers. It will require long and unfiltered exposures to get a reasonable signal-to-noise ratio.”

It is rather tedious sitting here waiting for photons to arrive so I am trying to get ball-park estimates of what is likely to be achieved. As the autoguider on the 0.4m Dilworth / unfiltered CCD combination still doesn’t work I restrict each exposure to 30 seconds. The sky tonight is fairly dark but not exceptionally so. The SX 814 has a very low dark noise and so the major limit on SNR is sky glow. I have found that averaging 20 subs, for a total exposure time of 10 minutes, gives a SNR of 50 to 55 when U Leo is at altitude of 60 degrees. It will be worse at lower altitudes, of course, or if the Moon is above the horizon. A SNR of 50 corresponds to a precision of 0.02 magnitudes. The light curve in the VSS Circular suggests that the peak-to-peak amplitude is perhaps 0.1 magnitudes. A period of 3.2 hours corresponds to 192 minutes. Accordingly I can hope for at most 19 samples per period  at an amplitude precision of 20%. In practice it will be less because of download times and inevitable discarded images from poor tracking.

It is going to take a lot of heavy duty signal processing to get robust results from my observations alone. If I had perhaps ten times the data I should be able to get something useful. We need lots more observers, in other words.

One unexpected side benefit is that U Leo lies in a rich field of galaxies, including a bright face-on spiral known as 2MASX J10234921+1357083 (it appears on Jeremy’s finder chart roughly halfway between U Leo and the bright star in the lower left corner; an edge-on spiral of around 17th magnitude lies to its left).  Only a few hints of spiral arms have appeared on a large stack but a “pretty-picture” may yet be possible. The galaxy’s magnitude is g=15.9 and r=15.2 so it shows up on every single sub.  There are many more galaxies brighter than 20th magnitude within a few arc minutes of U Leo; they are starting to appear in my data as the stacks get deeper.

Added in edit: since typing the above text the SNR has almost doubled.  Presumably the sky has become notably brighter for some reason I do not understand.  Perhapsthe signal processing may be easier than feared.

More 30s captures of U Leo are coming in to add to the hundreds already stored.  This is all rather tedious so I have been thinking about data processing and, in particular, about stacking the images.  The SNR of each sub varies between about 10 and about 20, depending on sky transparency, air mass, etc.  A desirable SNR might be 30-50 so perhaps 9 should be stacked.

So far, so simple. I could just divide up each night’s observations  into consecutive and non-overlapping sub-sequences of length 9, stack them and use the mid-exposure time as the date of each measurement. However, it seems that there is nothing particularly magic about any particular selection of 9 consecutive images. If the first image, say, was deleted by accident the process would yield much the same output but would contain a sample of the light curve slightly displaced from that which would have been created from the full set of images.

If this is the case, why not create 9 light curves, each with a temporal displacement from its neighbour set by the cadence of the subs?

Each curve would have no more information than any other, and the sum of them would be just as noisy in intensity values but would have more temporal sampling.  Might not this assist subsequent processing to extract a smoother light curve from the noisy data?  If not, what am I missing?  To me it appears related to a simple running-average smoohng process. It’s late and I am sleepy so could well be overlooking something which should be obvious.

Thanks.  You understand my proposal and I was specifically thinking of the analysis phase.  That should have been made clearer.

Unfortunately from the analysis point of view, the database stores only a magnitude and its uncertainty at a particular JD. The last is an annoyance but nothing more as conversion to the more useful HJD or BJD is a tedious but straightforward computation. The first two destroy some of the information held by the intensity counts of the VS, the sequence stars, local sky backgrounds and the latter’s variance. Further, it does not store the data pertaining to other stars in the image which can be used — with care — to give a tighter estimate of the ZPM and its uncertainty through ensemble photometry. Needless to say, I keep all the raw data around for subsequent re-analysis. Please note that I am not saying that the database structure should be changed!

Perhaps I should submit the raw 30s results with their 0.05 to 0.1 magnitude uncertainties and let others smooth them as they wish for their analysis. I can pretty much guarantee the 3.2-hour variability will not be visible without such smoothing.

In this case since it is a particular campaign with specific goals I would probably look to the PI for guidance.

In general though the processing (including combining) of data for submission to databases where the end use is unknown (and in this case potentially may not be known until all of us are long gone) is an ever present dilemma. I faced this in real life for example concerning databases storing vast quantities of process control and quality time series data from a continuous process (a paper machine) where (similar to astronomy) variations over several orders of timescale (from milliseconds to years in that case) are potentially of relevance. Ultimately, storing the data from every exposure and letting the final user make the decision would be ideal  (aided perhaps by tools in the database to allow the casual user interrogating the database to view the filtered data).  Andy (like our paper mill IT manager at the time) might baulk at every exposure being measured and stored individually indefinitely though!  An alternative approach could perhaps be based on examining the data prior to submission to look at what point  when combining data the variation if any becomes significant compared to the uncertainty, thus preserving the maximum information while storing  the minimum of data.  

Cheers

Robin

My thanks to Andy and Robin for their helpful advice. I was aware what is held in the DB but that explanation should be useful to others. The suggestion to contact the PI is a good one and as I will be keeping all the raw (but calibrated with darks and flats) images that will remain a possibility for those who may wish to re-analyse my data.

Most people, though, are unlikely to be that finicky and would like to have an overview of the light curve which is sufficiently good for their purposes without having to spend a great deal of effort. With that in mind, I will stack the images such that the integrated SNR is at least 30, yielding a statistical uncertainty of ~30mmag, easily good enough to pick up the pm 110mmag variation reported so far. As the database holds an explen field for each entry, I don´t see that it matters whether three subs or a dozen are stacked for each individual measurement — as long as the total duration and effective mid-exposure time is recorded of course, as it will be.

FWIW, I store essentially every image ever taken, with its metadata in a PostgreSQL database,  because disk space is cheap and I have yet to reach even a terabyte of data. Multiply that by a few hundred observers, especially if they are taking high frame rate videos, and I can see it starting to become a problem.