Hi Maria
These numbers are very useful. If that is the case, indeed 12 arcmin is
an overkill and we should think about finer granularity for these chunks.
The reason why I avoided zoneIds was that zone-based clustering will
cluster data for entire "stripe" which is very nice for two edges, but
pretty inefficient for the remaining two (am I correct?). The chunks I
am suggesting try to avoid that issue. If we can efficiently cluster
data based on zoneId+ra for all four edges, I am all for it =)
thanks
Jacek
Maria A. Nieto-Santisteban wrote:
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
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
