Process ZTF Forced Photometry

[dirodriguezm]

ZTF Forced Photometry starts on October 10th. We need to at least ingest that data and store it both raw on S3 and on our queryable databases (Mongo + PSQL). No other requirement is needed for this iteration.

The new alert schema is at https://github.com/ZwickyTransientFacility/ztf-avro-alert/tree/master/schema

In order to ingest the new data the following changes are needed:

• In survey_parser_plugins we need to ensure that the forced photometry field reaches extra_fields on the generic alert This is done by adding fp_hist to fields_from_top here
• In prv_candidates_step we should read fp_hist from extra_fields and parse that to a generic_alert here by following the structure of the LSST parser here
• Finally when the correction_step sends scribe commands with a forced_photometry collection, we should be able to write that into PSQL and MongoDB. So we need to create a PSQL command that writes into a new table named forced_photometry
  • This also indicates that there should be a new ForcedPhotometry model on DBPlugins and the appropiate migration should be applied to the PSQL Database

### Tasks
- [ ] https://github.com/alercebroker/pipeline/issues/177
- [ ] https://github.com/alercebroker/pipeline/issues/178
- [ ] https://github.com/alercebroker/pipeline/issues/179
- [ ] https://github.com/alercebroker/pipeline/issues/180
- [ ] https://github.com/alercebroker/pipeline/issues/181
- [ ] https://github.com/alercebroker/pipeline/issues/189
- [ ] https://github.com/alercebroker/pipeline/issues/210
- [ ] https://github.com/alercebroker/pipeline/issues/216
- [ ] https://github.com/alercebroker/pipeline/issues/217
- [ ] https://github.com/alercebroker/pipeline/issues/231
- [ ] https://github.com/alercebroker/pipeline/issues/234

[dirodriguezm]

Cortesía de @ale-munozarancibia

Yap sobre los campos del esquema de ZTF para forced phot:

• field: va a extra_fields
• rcid: va a extra_fields
• fid: va a fid
• pid: va a extra_fields (duda: hay otro pid ya usado antes en mongodb? Dónde iba?)
• rfid: va a extra_fields. La info detrás de este id es la misma q la usada en alertas, así q para postgres se podría seguir el mismo estilo q en alertas
• sciinpseeing: va a extra_fields
• scibckgnd: va a extra_fields
• scisigpix: va a extra_fields
• magzpsci: va a extra_fields
• magzpsciunc: va a extra_fields
• magzpscirms: va a extra_fields
• clrcoeff: va a extra_fields
• clrcounc: va a extra_fields
• exptime: va a extra_fields
• adpctdif1: va a extra_fields
• adpctdif2: va a extra_fields
• diffmaglim: va a extra_fields
• programid: va a extra_fields
• jd: se usa para calcular mjd y se guarda solo mjd (así se hace en alertas cierto?)
• forcediffimflux: va a extra_fields, así como en ATLAS flux va a extra_fields. Se usa para calcular mag. Habría q decidir si se guarda el número tal cual viene (en unidades "DN") o se guarda convertido a una unidad estándar (como uJy o mJy), lo q requiere usar el valor de magzpsci (duda: cómo se hizo en ATLAS?)
• forcediffimfluxunc: va a extra_fields, así como en ATLAS Dflux va a extra_fields. Se usa (junto con forcediffimflux) para calcular dmag. Sobre unidades, idem q forcediffimflux
• procstatus: va a extra_fields
• distnr: va a extra_fields. En cuanto a postgres, idem q rfid
• ranr: va a extra_fields. En cuanto a postgres, idem q rfid
• decnr: va a extra_fields. En cuanto a postgres, idem q rfid
• magnr: va a extra_fields. En cuanto a postgres, idem q rfid
• sigmagnr: va a extra_fields. En cuanto a postgres, idem q rfid
• chinr: va a extra_fields. En cuanto a postgres, idem q rfid
• sharpnr: va a extra_fields. En cuanto a postgres, idem q rfid 1:13 En ALeRCE habría q crear:
• tid: =ZTF
• sid: =ZTF
• aid
• oid: a partir de info alerta
• mjd: a partir de jd
• ra: aqui no sé bien si debería ser ra de la alerta q envió la forced phot, o de la primera alerta del oid. Convendría ver qué puntos de forced phot se repiten en alertas sucesivas de un mismo oid
• e_ra: sospecho q debería ser 0 xq las coordenadas están fijas a donde uno decidió calcular la forced phot, pero puede q me equivoque y deba ser el mismo valor de las alertas. Necesario confirmar
• dec: idem q ra
• e_dec: idem q e_ra
• mag: a partir de forcediffimflux. Fórmula correcta dependerá de qué unidades tenga forcediffimflux en ese momento de la pipeline. Si se usa forcediffimflux tal como viene, hay q incluir tb magzpsci en el cálculo. Si se pasó forcediffimflux a una unidad estándar, solo hay q incluir forcediffimflux en la fórmula
• e_mag: a partir de forcediffimflux y forcediffimfluxunc. Sobre fórmula correcta, idem q mag
• mag_corr: una vez obtenidos mag y e_mag, deberían servir las mismas funciones q se usan en alertas para obtener mag_corr
• e_mag_corr: idem q mag_corr
• e_mag_corr_ext: idem q mag_corr
• isdiffpos: a partir de signo de forcediffimflux
• corrected
• dubious
• parent_candid: a partir de info alerta
• has_stamp: imagino q será False para puntos de forced phot, a menos q vengan stamps para esos puntos