Details
-
Type:
Bug
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: Qserv
-
Labels:
-
Story Points:0.1
-
Epic Link:
-
Sprint:DB_F16_10
-
Team:Data Access and Database
Description
Yi Mei says:
I found another problem: the database query
select * from RunDeepForcedSource where objectId=3219370448785419; |
curl -o outForcedSource -d 'query=select+*+from+RunDeepForcedSource+where+objectId=3219370448785419;' http://lsst-qserv-dax01.ncsa.illinois.edu:5000/db/v0/tap/sync
|
(Note that the direct mysql query above was run against the test database gapon_sdss_stripe92_patch366_0)
Attachments
Issue Links
- relates to
-
DM-8241 PDAC: patch "hole" in Stripe 82 catalog data
- Done
Activity
| Field | Original Value | New Value |
|---|---|---|
| Epic Link |
|
| Watchers | Fritz Mueller [ Fritz Mueller ] | Fritz Mueller, Yi Mei [ Fritz Mueller, Yi Mei ] |
| Description |
Yi Mei says:
I found another problem: the database query, {code:sql}select * from RunDeepForcedSource where objectId=3219370448785419;{code} gave me 808 records but "curl -o outForcedSource -d 'query=select+*+from+RunDeepForcedSource+where+objectId=3219370448785419;' http://lsst-qserv-dax01.ncsa.illinois.edu:5000/db/v0/tap/sync" gave me nothing. |
| Description |
Yi Mei says:
I found another problem: the database query, {code:sql}select * from RunDeepForcedSource where objectId=3219370448785419;{code} gave me 808 records but "curl -o outForcedSource -d 'query=select+*+from+RunDeepForcedSource+where+objectId=3219370448785419;' http://lsst-qserv-dax01.ncsa.illinois.edu:5000/db/v0/tap/sync" gave me nothing. |
Yi Mei says:
I found another problem: the database query{code:sql}select * from RunDeepForcedSource where objectId=3219370448785419;{code} gave me 808 records but {{curl -o outForcedSource -d 'query=select+*+from+RunDeepForcedSource+where+objectId=3219370448785419;' http://lsst-qserv-dax01.ncsa.illinois.edu:5000/db/v0/tap/sync}} gave me nothing. |
| Description |
Yi Mei says:
I found another problem: the database query{code:sql}select * from RunDeepForcedSource where objectId=3219370448785419;{code} gave me 808 records but {{curl -o outForcedSource -d 'query=select+*+from+RunDeepForcedSource+where+objectId=3219370448785419;' http://lsst-qserv-dax01.ncsa.illinois.edu:5000/db/v0/tap/sync}} gave me nothing. |
Yi Mei says:
I found another problem: the database query{code:sql}select * from RunDeepForcedSource where objectId=3219370448785419;{code} gave me 808 records but {code}curl -o outForcedSource -d 'query=select+*+from+RunDeepForcedSource+where+objectId=3219370448785419;' http://lsst-qserv-dax01.ncsa.illinois.edu:5000/db/v0/tap/sync{code} gave me nothing. (Note that the direct mysql query above was run against the test database gapon_sdss_stripe92_patch366_0) |
| Reporter | Fritz Mueller [ fritzm ] | Yi Mei [ ymei ] |
| Story Points | 2 | 0.1 |
The problem has been investigated. And here is the conclusion:
The object in question belongs to the overlap area processed during S13 DC by IN2P3 in patch=366,0. The IN2P3's version of the patch was not included into the merged Stripe82 catalog. The NCSA's version was used instead. User hit a very narrow hole in the merged dataset right on the edge.
Note that this is a well known problem with the current version of the Stripe82 catalog loaded into PDAC/Qserv database sdss_stripe82_00. The problem is well understood, and it will be solved in a refined version of the catalog.
I picked that patch by a pure accident when preparing that tiny monolithic catalog for SUIT in an anticipation of the PDAC deployment. I wouldn't draw any conclusions from this as this monolithic catalog is not meant to be used to Q&A PDAC! For that (later) purpose we're planning to have the full merged catalog on some dedicated hardware....when/if it will be available.
| Resolution | Done [ 10000 ] | |
| Status | To Do [ 10001 ] | Done [ 10002 ] |
| Comment | [ Igor says: "I think I have an answer regarding objectId=3219370448785419. This belongs to the overlap area processed by IN2P3 (patch=366,0). And it was not included into the merged dataset because the whole patch of the dataset came from the NCSA part of the original S13 DC. You've hit a very narrow hole in the merged dataset right on the edge! Remember that we discussed this problem earlier with Yusra? I picked that patch by a pure accident when preparing that tiny monolithic catalog for SUIT in an anticipation of the PDAC deployment. I wouldn't draw any conclusions from this as this monolithic catalog is not meant to be used to Q&A PDAC! For that (later) purpose we're planning to have the full merged catalog on some dedicated hardware....when/if it will be available." ] |
This is how the patch info could be found from the original (before the merge) version of the catalog brought from IN2P3:
USE lsst_prod_DC_2013_2; |
SELECT id,coadd_id FROM RunDeepSource WHERE id=3219370448785419; |
+------------------+----------+
|
| id | coadd_id |
|
+------------------+----------+
|
| 3219370448785419 | 23986179 |
|
+------------------+----------+
|
SELECT deepCoaddId,tract,patch FROM DeepCoadd WHERE deepCoaddId=23986179; |
+-------------+-------+-------+
|
| deepCoaddId | tract | patch |
|
+-------------+-------+-------+
|
| 23986179 | 0 | 366,0 |
|
+-------------+-------+-------+
|
| Labels | pdac |
A similar query for a known-loaded objectId in the qserv cluster executes correctly: