Output Product: Photometric Random Catalog

$SetSchemaPath le3/id/vmpz/out/euc-le3-id-vmpz-RandomCatalog.xsd

Data Product Name

$PrintDataProductName

Data Product Custodian

$PrintDataProductCustodian

Name of the Schema File

$PrintSchemaFilename

Last Edited for DPDD Version

1.1

Processing Elements Creating / Updating / Using the Product

Creators:

  • VMPZ_Random (LE3_VMPZ_ID_Random)

Consumers:

  • None

Processing function using the data product

  • 2PCF-WL, PK-WL, 2PCF-GC, 3PCF-GC, PK-GC, DET-CL, PROF-CL, VMSP-ID

  • SWG-GC, SWG-WL, SWG-CL

Proposed for inclusion in EAS/SAS

This product is proposed for inclusion in SAS: yes

This product is used by different PFs in OU-LE3 and expected to be used in scientific analysis in SWG-GC, SWG-WL and SWG-CL.

Data Product Elements

$PrintDataProductElements

Detailed Description of the Data Product

This output product is a photometric random catalogue.

It is an extension of a base catalogue, includes the RandomCatalog metadata, a container with a FITS file (of type le3.id.vmpz.randomcatalog), and the mask parameters RandomParams can optionally be associated to the product.

Keywords (Primary HDU)

The primary HDU is expected to contain the following keywords, characterizing important parameters of the input product:

  1. DATE-OBS: start of observation with format ‘yyyy-mm-ddThh:mm:ss.sss’ [StringKeyword]

  2. DATE-END: end of observation with format ‘yyyy-mm-ddThh:mm:ss.sss’ [StringKeyword]

  3. TELESCOP: name of the telescope [StringKeyword]

  4. INSTRUME: name of the instrument [StringKeyword]

  5. FILTER: name of the filter [StringKeyword]

  6. FILTLST: selection of filter if intersection of multiple footprints [StringKeyword]

  7. TILEID: identifier of the MER Tile processed (-1 if multiple Tiles) [IntegerKeyword]

  8. LISTID: identifier of a MER list of tiles product (-1 if single Tile) [StringKeyword]

  9. NSIDE_WK: Nside parameter used for frame->HEALPix [StringKeyword]

  10. BITSEL: identifier of the bit of combination of bits used in the depth map (e.g. 0 for least significant bit,..,18) [StringKeyword]

  11. DEPTHEST: estimator used for depth computation [StringKeyword]

  12. BINSEL: Identifier for the selection of the bin/population [StringKeyword]

    and basic software parameters:

  13. SEED:Seed used for random generations[StringKeyword]

  14. NSIMOBJ:Number of simulated objects in the catalogue [IntegerKeyword]

  15. SOFTNAME: name of software used [StringKeyword]

  16. SOFTVERS: version of software used [StringKeyword]

Random Catalogue Table (First Extension, Binary Table)

  1. SIM_ID: Galaxy Simulated Id [K, int64]

  2. RIGHT_ASCENSION: Right ascension (in degrees) [D, float64]

  3. DECLINATION: Declination (in degrees) [D, float64]

  4. TOM_BIN_ID: ID of selection bin [J, int32]

  5. WEIGHT: weight associated to the galaxy (probability of detection?) [E, float32]

Note

Do we really need a SIM_ID? Ben said that it could be useful if we want to subselect several sub-catalogs from a master one if I remember well

Note

The weight column is not clear: does it give a probability of detection in a tomographic bin, or the weight associated to a galaxy for mitigating systematics effects/improving SNR as for the photometric galaxy clustering ?- with recipe not yet fixed in WL-

Note

Assigning the TOM_BIN_ID implies knowing the probability of assigning a detected galaxy from a given galaxy population to a given TOM_BIN_ID and should imply not yet identified products from PHZ.

Note

Here this is a random catalogue associated to a given selection, not a master catalogue where selection can be applied. But the photometric galaxy clustering use case should lead to a quite stable selection. Other possibility is to encode selection in the TOM_BIN_ID, and then further subselect on this.