[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
> 
>