Hi, probably I'm not the best to answer the question but I will give it a shot
considering FOV ~ 3.16 x 3.16 deg^2 one of those chunks 3.16*60 /16 ~ 12 arcminutes .... considering "Barnard's star has the largest proper motion of all stars, moving at 10.3 seconds of arc per year" http://en.wikipedia.org/wiki/Proper_motion 12 arcminutes would be MORE than enough!!!! In any case, I think it is unnecesary such a huge buffer because among other things you could not afford a match of 12 arcminutes radius, at least not an all-to-all. The question is .. what should the biggest search radius used in the cross-match? It should be less than 10 sigma (sigma = astrometric precission) Finally, I don't see a huge benefit in using this chunking 16x16. It seems to me that a simple zoneID, RA index would help more efficiently to reduce the reads and do the cross-match. Cheers Maria On Tue, 21 Nov 2006, Jacek Becla wrote: > > Yes, I think the fast moving objects will be kept in a separate > catalog (called Orbit Catalog I think), and the issue I am raising > is for slow moving objects. So the question is whether slowly moving > object can move more than one chunk per night? > thanks, > Jacek > > > > > > > > Serge Monkewitz wrote: > > Kem - I just assumed there was a seperate table for moving objects so > > this is good to hear, but ... what about really slow movers? Will the > > MOP be able to detect and track an object that crosses a chunk over the > > course of 6 months? 1yr? Put another way, do we need to assume some kind > > of small but still significant (over the course of a release cycle) > > velocity for objects in the main object table (especially leading up to > > DR1 since the deep/moving pipelines won't have had very much time to > > discover/tell eachother about such objects)? > > > > Thanks, > > Serge > > > > On Tue, 21 Nov 2006 16:43:06 -0800, Kem Cook <[EMAIL PROTECTED]> wrote: > > > >> Hi Jacek, > >> > >> Your partitioning makes perfect sense, but there will be a few objects > >> which move more than quite a bit more than 1 chunk per night. But, I > >> think we were going to be keeping the moving obectsd in a separate table, > >> for this, as well as other, reasons. > >> > >> cheers, > >> > >> Kem > >> > >>> Keywords: DataAccWG > >>> > >>> Hello, > >>> > >>> Here is a brand new suggestion how to partition Object table > >>> for the nightly processing use case: > >>> > >>> http://www.slac.stanford.edu/~becla/tmp/objectTablePartitioningAtBase.doc > >>> > >>> > >>> Hope we will have time to talk about it during the telecon tomorrow. > >>> > >>> Jacek > > > > _______________________________________________ > > LSST-data mailing list > > [email protected] > > http://www.lsstmail.org/mailman/listinfo/lsst-data > > _______________________________________________ > LSST-data mailing list > [email protected] > http://www.lsstmail.org/mailman/listinfo/lsst-data > -- ------------------------------------------------ Maria A. Nieto-Santisteban ([EMAIL PROTECTED]) Johns Hopkins University 3400 N. Charles St. Physics & Astronomy Department Baltimore, MD 21218 (USA) Tel: 1 410 516-7679 Fax: 1 410 516-5096 _______________________________________________ LSST-data mailing list [email protected] http://www.lsstmail.org/mailman/listinfo/lsst-data
