WFD metrics with the FBS output

Tags: #<Tag:0x00007fb384086788>

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.
image
image
image
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).

Thanks Lynne! @gnarayan ran this and it seems to be working for us! Is it possible to get a small test database with this additional column added (It could be the fbsv1.4 itself if there are no further changes). Thanks!

I believe the FBS 1.4 databases should all have this added. You can tell by the following:

-- Loading resources from /Users/lynnej/.sqliterc
SQLite version 3.28.0 2019-04-15 14:49:49
Enter ".help" for usage hints.
sqlite> .tables
Proposal         SummaryAllProps  info           
sqlite> 

If the “Proposal” table is there, the WFD visits should be labelled accordingly (using the proposalId in the SummaryAllProps table).
All of the 1.3 and 1.4 databases downloadable from astro-lsst-01 should have this labelling, I’m just not 100% sure about the versions at NCSA (I think the 1.4 databases there should have it, but probably not the 1.3 runs).

@rbiswas - I did check that the add_fbs_proposals.py script did add the Proposal table to the opsim DBs I downloaded from NCSA. I rsync’d those mostly in mid Dec. after the email from @MichelleLochner, but I don’t know when the transition from run 1.3 to 1.4 happened or if the files I downloaded were 1.3 or 1.4. If there’s any worry though, it’s easy to redownload opsim DBs (and I guess then we don’t have run this script?).

So, the script doesn’t automatically know whether the WFD footprint should be the standard footprint or an extended N/S footprint (and if it’s extended, whether it should be using the dust cut or a simple galactic latitude cut). So, I’d say - use the versions of the databases provided, rather than running it yourself, unless you already know how you’d like to label things.

The FBS 1.4 runs were just released, so the ones you’d have would’ve been 1.3.
It’s possible that you should be using FBS 1.3 … I think the DESC paper is trying to use a consistent set of runs and you should use what they’ve decided if you’re trying to match that.
However, if it’s for current evaluation purposes, I’d say go with the FBS 1.4 runs as they will have the updated seeing inputs.

Hello @ljones,

Has the HealpixSubsetSlicer been included in the recent weekly builds?

Thanks!

Yes - it should be in (at least) the last two weekly builds, the most recent being sims_w_2020_06.

1 Like

Hi @ljones, I have recently downloaded the v1.3 sims from astro-lsst-01 (this past Monday). However, it appears that for 20 strategies the proposal table was not added. I was going to run the script myself, but I figured I’d ask first if it was trivial to add these, before I begin trying to install FBS, which appears to be needed for the script.

Would it be possible to rerun the add_fbs_proposals.py script on the following cadences?

  • altLike_large_v1.3_10yrs.db
  • altLike_v1.3_10yrs.db
  • altroll_mod2_dust_sdf_0.20_v1.3_10yrs.db
  • altroll_mod2_sdf_0.20_v1.3_10yrs.db
  • altwfd_dust_v1.3_10yrs.db
  • altwfd_v1.3_10yrs.db
  • big_sky_dust_v1.3_10yrs.db
  • big_sky_nouiy_v1.3_10yrs.db
  • bulges_bsv1.3_10yrs.db
  • bulges_bulge_wfdv1.3_10yrs.db
  • bulges_cadence_bsv1.3_10yrs.db
  • bulges_cadence_bulge_wfdv1.3_10yrs.db
  • bulges_cadence_i_heavyv1.3_10yrs.db
  • bulges_i_heavyv1.3_10yrs.db
  • no_gp_north_v1.3_10yrs.db
  • stuck_rolling_v1.3_10yrs.db
  • twilight_neo_mod1_v1.3_10yrs.db
  • twilight_neo_mod2_v1.3_10yrs.db
  • twilight_neo_mod3_v1.3_10yrs.db
  • twilight_neo_mod4_v1.3_10yrs.db

I’ve also found that the v1.4 cadence:

  • sat_dodge_v1.4_10yrs.db

also does not have a proposal table.

I would greatly appreciate it!

Thanks,

Ah, right - the sat_dodge_v1.4_10yrs.db database is maybe one that the wider community may not be that interested in analyzing … It’s a basic attempt at evaluating the impact of having to dodge satellites by waiting to take visits until there is no satellite in the field (so, queueing a pointing, evaluating if there is a satellite, and then waiting until the satellite exits the field to take the exposure). The impact is thus a fewer number of visits overall; and if we have to wait (on average) long enough that overall the number of visits decreases by more than the fraction of the fields we’d have to throw away due to satellite trails, then this is not a good strategy. So, in practice, whether this is a good approach will depend on how bright the satellites are (still somewhat unknown, but is starting to seem unlikely to be bright enough to cause very large fractions of the FOV to have to be discarded) and how many satellites there are, as well as whether we could potentially do something even a bit more advanced such as avoiding entire satellite tracks (because one problem with dodging satellites is not knowing exactly when we will take the exposure, due to possible variability in the slew times, etc.). Thus, in general, I don’t think sat_dodge_v1.4_10yrs is necessarily a simulation that others need to investigate, although it is very useful for those of us in the project and investigating this specific question. I can add the proposalId tagging to this simulation if you need it.

As for the v1.3 runs: all of the runs in your list should be completely replaced by v1.4 runs, except for the altLike*, altwfd*, and altroll* runs, although they have similar style (or improved versions of) runs in v1.3 … is there a particular reason you want the v1.3 versions instead? If so, I can add the proposalIds to these runs, but I suspect it may be better to look at v1.4 in general.
I will note that the twilight_neo* runs in v1.3 had a bug where the NEO cadence wasn’t executed properly, so these should be ignored.

Hi @ljones,

Thanks for the quick response! For the DESC Observing Strategy working group journal paper on our observing strategy studies we have been asked to run all v1.3 and v1.4 cadences for our full science metrics. If there are good reasons that we may not be interested in certain strategies I can pass that along to Dan and Michelle that possible we shouldn’t include those in our set for the paper. It definitely makes sense to avoid the twilight_neo and sat_dodge. However, if not too much trouble to run. I would certainly appreciate if the proposal table could be added to the other cadences.

Thanks again!

Hi again @ljones, I was wondering if you were intending to add the the proposal table to the cadences listed above? In order to include my cadence metrics with others of the DESC Observing Strategy working group in our current work I would very much appreciate if these could be added.

Thanks!

My apologies for the delay - the runs should all be labelled if you download them from
http://astro-lsst-01.astro.washington.edu:8081/ (the ones at NCSA are not labelled).
If you want to download all of the opsim databases, instead of going through the astro-lsst-01 page directly you may find it easier to access these (exactly the same) databases through the links at
https://epyc.astro.washington.edu/~lynnej/opsim_downloads/

Hi @ljones. No problem at all, thank you very much!