[OBSPROC-10] Define the schema of prototype of targetDB Created: 07/Oct/21  Updated: 17/Feb/22  Resolved: 17/Feb/22

Status: Won't Fix
Project: PFS observation processing/procedure
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Normal
Reporter: monodera Assignee: monodera
Resolution: Won't Fix Votes: 0
Labels: targetDB
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PDF File schema_targetdb.pdf     PDF File schema_targetdb_tables.pdf    
Issue Links:
Relates
relates to INSTRM-1302 Define tables outside opDB Open
relates to OBSPROC-18 Handling duplicates in targetDB Won't Fix
Epic Link: targetDB
Reviewers: yuki.moritani

 Description   

TargetDB is supposed to be a database hosting all targets for PFS (cf. opDB is for actually observed (or designed) targets, I believe).

I made an initial schema for targetDB which is based on the target and related tables in opDB sometime earlier. Although there are some parts which do not conform the datamodel, I would like to have your feedback to improve it (I know there are a lot of points to be discussed).

One noticeable feature is the introduction of the unique_object table. It is supposed to host unique objects on the sky and referred in the target table to handle duplication. My idea is to check duplication with objects already registered to the unique_object table by a cone search with a search radius of 1/2 to 1/3 of the fiber diameter. If no object is matched for an object, this object will be inserted in the unique_object table. I'm not sure whether this is the easiest way to handle duplication, so comments on this are very welcome.

Attached files (ver 2020-10-06 HST):

  • schema_targetdb_tables.pdf : Information on columns in each table.
  • schema_targetdb.pdf : Schema diagram of the current prototype.

 Comments   
Comment by Kiyoto Yabe [ 14/Oct/21 ]

According the current [datamodel|https://github.com/Subaru-PFS/datamodel/blob/master/datamodel.txt,] `pfsDesign` file needs the following target information (that ETS needs to take from targetDB):

  • DESIGN
    • catId 32-bit int
    • tract 32-bit int
    • patch string
    • objId 64-bit int
    • ra 64-bit float (degrees)
    • dec 64-bit float (degrees)
    • targetType 32-bit int (probably)
  • PHOTOMETRY
    • fiberFlux [nJy] 32-bit float
    • psfFlux [nJy] 32-bit float
    • totalFlux [nJy] 32-bit float
    • fiberFluxErr [nJy] 32-bit float
    • psfFluxErr [nJy] 32-bit float
    • totalFluxErr [nJy] 32-bit float
    • filterName string

So I guess catId and fluxes would be matters of discussion in the current schema.

Comment by monodera [ 10/Feb/22 ]

I still have some doubt whether it is better to have a unique_object table behind the target table, because it may make any modifications difficult. As an alternative, it can be possible to make a table containing pairs of duplicated sources, which can be made at any time by scanning the target table.

Comment by monodera [ 10/Feb/22 ]

Another concern is that the reference coordinates when checking duplicates can be those inserted first. Then, if there is astrometric issues, it affect all duplicates for these objects. We may host some major catalogs (HSC-SSP, Gaia, etc.) behind to cross matching, but may make the db too large.

Comment by monodera [ 17/Feb/22 ]

I created OBSPROC-17 and OBSPROC-18 specifically for flux columns and for handling duplicates. Other parts are mostly done and I find that the scope of this issue is too broad. If any other work are needed, I'd like to create more specific issues rather than keeping this opened forever.

Generated at Sat Feb 10 16:44:18 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.