Maybe you want to identify how many visits were “counted” for WFD, maybe you want to identify how much sky within a “WFD” footprint got 925 visits. In both of these situations, you want some way to calculate a metric that is WFD-specific, although I’d argue that these may best be done with slightly different approaches.
So first of all: in the FBS (FeatureBased Scheduler), there is no strict concept of “WFD” – that is, some parts of the sky will have a different number of requested visits (actually, a different ratio of requested visits), and some parts of the sky may have additional requirements for cadence (i.e. rolling cadence footprints or weighting toward i band in the galactic bulge) – but for most of the time, most of the sky, the factors influencing scheduling in the FBS are the same.
That said, there is a particular area of sky which would traditionally be called “WFD” and that part of the sky is specified in the scheduler footprint so as to reach approximately the number (ratio) of overall visits as expected.
Thus you can count visits that fall mostly (>40%) within that region as “WFD” and tag them as such, which can be done using the ‘add_fbs_proposals.py’ script (not yet on master, but here currently). I’ve run this on the databases available on astro-lsst-01, so if you download them from there the tags will already be available (see the added Proposal table inside the database for more info, or just add a sqlconstraint of proposalId=1 for WFD when getting visits for metrics).
Then you can pull out the subset of visits that were part of “WFD” to calculate your metrics - but note that you will have a roll-off near the edge, because some part of those visits would have landed outside the defined footprint for WFD (remember, we dither). You may also find that some sky observations that you would have included are lost - because most of the pointing fell outside the “WFD” footprint.
For many metrics, it makes more sense to define a subset of healpixels that you want to use to calculate your metrics, and then use all visits as input (but only calculate your metric within the WFD footprint). You can do that by setting the subset of healpix points you want to use, by defining the WFD footprint and then using the HealpixSubsetSlicer*.
*you can also do this by finding the RA/Dec values of the points within the WFD footprint and using those to set up the UserPointsSlicer, but the HealpixSubsetSlicer will let you continue to calculate power spectra, etc.
If you set the footprint in the Slicer, and place no constraints on the visits used, you will have a complete evaluation of the metric within the WFD region, without roll-offs at the edge. If you want to eliminate DD fields, add the sql constraint note not like "DD%" and then you will get a cleaner evaluation of visits within the WFD footprint, without the extra visits from the DD fields.
Here is a quick comparison of the number of visits in all bands, after excluding DD fields: all sky, WFD footprint only, and WFD-labelled visits only.
The difference between counting ‘WFD footprint’ and ‘WFD visits’ can be important. The area with more than 0 visits within the WFD footprint is 17785 sq deg, while the area with more than 0 visits in the WFD visits metric is 19045 sq deg. However, the mean number of visits per healpixel in the WFD footprint is 912 visits, while the mean number of visits per healpix using WFD visits only is 870 (with 922/918 as their respective medians).
The footprints can be easily defined using the sims_featureScheduler Demo HERE.
(additional comment: the sims weekly build has been broken for a while, but I was able to fix that last week, so eups distrib install lsst_sims -t sims_w_2019_50 will work and will get you a version of sims_featureScheduler that will let you import and use the footprints as above. The sims_maf code referred to above is not yet on master, but is available on a branch [u/lynnej/fbs_wfd] and should be part of the binary build next week).