[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: A Data Reduction Proposal
If anyone is interested, I have some Perl/SQL (PostgreSQL) which does #5 in
Tom's list below for a single radius (.004 degrees is what I currently use
along with at least 10 measurements). Basically, all the radius matching is
accomplished using PostgreSQL's circle_contain_pt and using a bounding box
around the circle to gain index usage to minimize the stars to search.
Later,
Rob
> -----Original Message-----
> From: Tom Droege [mailto:tdroege2@earthlink.net]
> Sent: Friday, February 01, 2002 4:17 PM
> To: tass@listserv.wwa.com
> Subject: A Data Reduction Proposal
>
>
> I will shortly send out Data Set 20a to Mark Pitts. Here is
> a proposal as
> to what might be done with it. This is just my proposal.
> This is what I
> would do if I were up to speed on data analysis. I might
> start it and
> instantly switch to something else as I started seeing
> results. So if you
> start it there is no obligation to see it through to
> conclusion. Here it is:
>
> Hypothesis: Things that affect the photometry also affect
> the astrometry.
>
> Discussion: Andrew has been seeing some affects due to things like
> bad/weak pixels and cosmic rays. I would propose that weak
> pixels distort
> the light distribution around a detected star and thus the
> final position
> determined for the star. A weak pixel should push the
> position determined
> away from the pixel. Likewise a cosmic ray should pull the position
> towards the cosmic ray. In either case, the position found
> will be moved
> from the position that would be found for a clean hit. Of
> course, this is
> with statistics folded in. It might not work for every star position
> found, but the hypothesis is that it makes an improvement for
> a group of
> measurements. The astronomy for a group of clean
> measurements should be
> "tighter" than that of a group of "dirty" measurements. I
> propose a test
> to see if this is true.
>
> Procedure:
>
> 1) Use the Michael Richmond pipeline, or the pipeline of your
> choice to
> reduce the DS20a data to star lists.
> 2) Do not throw anything away (except for stars too near the
> image edges to
> be measured well).
> 3) In particular, do not require a V, I match to keep a measurement.
> 4) Sort the data by position.
> 5) Find stars. (What? I thought we found stars in 1? Well,
> now we find
> stars by grouping. We are now in x,y, number of hits space.
> Previously we
> were in x, y, intensity space. We now get a position that is
> the centroid
> of all the measurements that are clustered near one mean
> position. First
> we find the centers of measurement clusters. Then we extract all the
> measurements for a star at increasing radii from the center. We will
> probably get position errors of one to two arc seconds from
> 1) above. We
> might thus take radii of 1, 2, 3, 4, 5 arc seconds. The
> larger the radii,
> the more measurements will be found for the star. Note that
> this is not
> new software. This is what one does to find stars in 1). It
> is just that
> now the "intensity" axis is somewhat grainier.)
> 6) Now make plots of the data sets found for the various search
> radii. Plot sigma of the measurements kept vs magnitude.
> Compare this
> with the expected plot from the statistics as Michael and
> Andrew have been
> doing in their reduction. Use this information to decide
> where to put the
> "cut".
> 7) Add in the VI pair requirement and compare again. This
> is an extra cut
> that might (or might not) improve the result.
>
> There should be hundreds of measurements of each star in each
> filter so the
> statistics should be pretty good.
>
> I do not see any obvious bias that is introduced by this
> scheme. Others
> might see something. Comments are welcome.
>
> Tom Droege
>
>