Time of forced source

Support Data Preview 0
#1

I am trying to work with DP0.2 data in the Lasair broker. It looks like the diaSource has a time as midPointTai, but the forced source (ForcedSourceOnDiaObject) does not.

I guess I can find the time by doing a JOIN with the CcdVisit table on CcdVisitId, then get the time as expMidptMJD. Is this the recommendation?

When the alerts are sent out, will they contain a ton of CcdVisit objects in addition to the diaObject, diaSources, and ForcedSourceOnDiaObjects? Or would it possible for the time of the forced source to be included without need for this awkward join?

#2

This is not a full solution/response, which I expect is more likely to arrive once the weekend is over, but a JOIN with CcdVisit to obtain expMidptMJD is indeed what’s done in DP0.2 tutorial notebook 07a:

Here, we will define the query to extract the information from the ForcedSourceOnDiaObject table on our DiaObject of interest in order to construct a lightcurve that includes forced photometry (i.e., sub-threshold measurements with SNR<5).

Below, a JOIN to the CcdVisit table is used to obtain the exposure time mid-point in modified julian date (MJD) format (expMidptMJD), which is necessary to construct the lightcurve.

#3

As a relatively minor footnote to the previous post, the same JOIN to get expMidptMJD is also done in DP0.2 tutorial notebook 07b:

We must perform one more table JOIN using the ccdVisitId from FourcedSourceOnDiaObject in order to get the MJD of each visit from the CcdVisit table.

#4

Hi Roy, the plan for the future is to have midPointTai in both the DiaForcedSource and DiaSource tables (Table 1 and 2 in the Data Products Definition Document). The joins needed for DP0.2 won’t be needed in future queries, and the alerts will have times for all the sources they include.

1 Like
#5

Thank you Melissa!

#6

I’ll note that the APDB schema (from which the alert packets get built) already has the time for the forced sources:
https://dm.lsst.org/sdm_schemas/browser/apdb.html#DiaForcedSource

Also note that these times will be called midpointMjdTai in future releases.

1 Like
#7

One more little snit: I suggest that in DiaObject the attribute gPSFluxNdata and its 5 friends should all be int not double. (Automated checking is amazing).

#8

Note that the DP0.X schema are fixed on release, and will not change. You want to look at either the APDB schema I linked above, or the LSSTCam-imSim schema, for the current schema. The APDB schema already has that fixed.

#9

A further remark:

In this particular case, there is a specific science-based reason that will lead us to provide the source observation time directly in the per-epoch Source-like tables throughout the AP and DRP data models: the finite speed of the camera shutter means that the actual measurement time can vary across the focal plane and even within a single CCD. (The details depend on whether in operations we do one-exposure or two-exposure “visits”.)

However, more generally there is a question of how much to “denormalize” our data model to avoid “awkward JOINs”, as there will be other per-visit and per-visit-per-CCD quantities in our database. We will be working on developing the ability to make some joined information available via database views - this is not yet available in Qserv. We may also decide to explicitly denormalize some information that we expect to be heavily used.

I would expect some evolution in this regard between the Data Previews and the operations-era data model, as we learn about database usage patterns.