Forum Replies Created
-
Posts
-
Astrometrica reports two different SNRs for the same measurement. In astrometry reports it uses something that Herbert Raab calls “peak SNR”. This is the SNR in the single brightest pixel. In the photometry report it uses what we would think of as the normal SNR definition (i.e. the SNR in the photometric aperture). Both I think use a process similar to what we have been discussing on this thread but I only really care about the photometric version since that one (or actually the log of it) is included in ADES astrometry that gets sent to the MPC. I’m trying to find out how Astrometrica estimates the gain, G (e-/ADU) from the image since the photometric SNR it reports does not scale correctly.
All the discussion about estimating the sky standard deviation is very interesting but for bright sources the photon noise dominates and getting G wrong really messes things up.
The one they use in VPHOT, described on page 4 here. Essentially you calculate the mean and SD then reject pixels more than 3 sigma from the mean and repeat until no more pixels are rejected. In the past I’ve used the median to get the sky level then used pixels below the sky level to determine the SD.
It looks like gain is normally defined upside down (i.e. e-/ADU rather than ADU/e-) which is odd but would explain the reciprocal.
Mean has better properties than median so I use an iterative approach which calculates the mean and rejects outliers.
Thanks Dominic. Well beyond the call of duty to be doing stats at 2am!
That all looks reasonable. M/(M-1) and (M+1)/M aren’t quite the same but they are very similar and in any case tend to unity for the real situation of largish M. For the photon noise SG makes sense when G is defined as ADU/photon.
One further practical question about estimating G from the image. I am using the magnitude zero point derived by fitting an ensemble of stars to a catalogue. This links the magnitude (and hence photon flux) to the ADU count. Is there an alternative/better way of doing this?
I’ll try this later and will see if I can start getting some consistent SNR estimates.
If you really want to put delta-T in a program then there are polynomial approximations such as the ones here. As has been said though you are unlikely to require this for lunar phases. It is important for high precision ephemerides of relatively close objects (including satellites) since it does affect the parallax correction and, as Dominic says, it is crucial for calculating total eclipse paths. It is probably worth including in telescope pointing algorithms too. Should anyone ever decide to remove leap seconds from UTC it will become important for the general public in a few thousand years!
The attached are updated elements of 2020 SW including my astrometry from last night. These should help if you are using any program which uses the MPC elements. This is actually a text file but for some reason you can’t upload those.
I managed to get some astrometry of this very small object this evening and it was a bit off track. An updated ephemeris is attached. Tonight it is around 19.7, tomorrow night (Tuesday) it will be 18.6 moving at 5″/min and Wednesday night it will be up to 16th mag but accelerating through 30″/min. It then moves rapidly south and we lose it as it comes within the geostationary satellite belt for a short period around Sept 24.45.
Note the ephemeris is for my location and the position will be different for you. This will become more significant the further from Essex you are and the closer the object gets. Let me know if you want an ephemeris for your location.
Here’s an image tonight in pretty good seeing (FWHM = 2.4 arcsec). It is in a very crowded field and, as Gary says, now it has faded it is difficult to separate from the star just to the west.
Here is a link to an animation showing how the star and nebula have changed over the last two years. I don’t think animated GIFs work in this forum.
That’s quite close to where I stay when I’m on LP. Hopefully they will get it under control. A local news report here.
I had an email from Graeme Waddington pointing out that the periodic wiggles due to Jupiter and the other planets disappear if you use a barycentric coordinate system rather than heliocentric. This is because, when the comet is far out, it is orbiting around the centre of mass of the Solar System (the barycentre) which is not exactly at the centre of the Sun. Graeme’s plots are attached. The y axis is 1/a which, if you remember from my first post, is equal to (1-e)/q so it has the big advantage that it is well conditioned for orbits where e is near to 1 (i.e. it doesn’t tend to infinity as e tends to 1). Graeme notes “At the ends of the time frame plotted the comet is at 244 au and 250 au from the sun –> P(orig.) = 4674 yr, P(future) = 7200 yr. For a similar integration using the JPL15 orbit I get 4434 and 6718 years respectively.”
https://britastro.org/node/23563. I get 12.6 unfiltered last night using Gaia DR2 G mags.
Ray,
The change is mainly due to the gravitational perturbations of the major planets. The orbital period is very sensitive to the eccentricity so a small change in e has a big effect on the period since a = q / (1 – e) and P = a^(3/2). The attached plots show the results you get if you integrate the current orbit forwards and backwards including the gravitational effects of all the planets and the biggest asteroids. There is a clear 12 year signature which is Jupiter but you can also see the large change in period corresponding to the small change in eccentricity.
Thanks to Hazel for pointing out that we need a new chart for this comet. Here it is: https://britastro.org/wp-content/uploads/sites/2020f3_Aug.pdf
I’ve only just got around to processing my images of C/2020 F3 (NEOWISE) from July 22. An animation is here:
http://www.nickdjames.com/Comets/2020/2020f3_20200722_ndj.gif
This shows a field of view of 33×22 arcmin processed using a Larson-Sekanina filter with r=2, th=10 deg. There are 9 frames each of around 330s duration (from 2143 – 2228). You can clearly see motion in the tail and material spiraling out from the centre of the coma. The small black dot at the centre of the coma is the reference pixel for the filter.
I have done quite a few experiments with this data and I think the parameters I have chosen are the best compromise to show detail and motion (i.e. around 300s integrations and L-S with r=2, th=10).
It always amazes me that so much relative motion is visible in active comets over such a short period of time.
Bill, this is very interesting. Can you give a bit of an explanation of how you got these maps. Did you take images in two orthogonal polarizations and then difference them? If so, how do you calibrate them unless they were taken at the same time.
There is a lot of detail in the centre of the coma too https://britastro.org/node/23370
