MAF: crowding metric in filters other than r?

willclarkson · February 10, 2020, 3:04pm

Hi @ljones, @yoachim and the MAF folks - what steps are required to ensure that metrics.CrowdingM5Metric can find the needed maps in filters other than “r”? Currently this metric is failing for me if the “filtername” argument is set to anything other than “r”.

I am running the “sims_w_2020_05” weekly build of the simulation framework (built from source under ubuntu 18.04 following the instructions here), using the github version of sims_maf. I get the same negative results if I also invoke maf_contrib before launch.

The last few lines of the error message I get are reproduced below. I’m pretty sure that the error message indicates that the metric is not finding the luminosity functions in the filters other than r. Can you remind me please where I get the necessary pieces from, and how I install them so that sims_maf can find them?

Thanks! – Will

Last few lines of the error message follow below. The line specifying the metric here was:

metric = metrics.CrowdingM5Metric(crowding_error=0.05,filtername=‘g’)

[…]

/raid1/soft/sims_maf_github/sims_maf/python/lsst/sims/maf/metrics/crowdingMetric.py in run(self, dataSlice, slicePoint)
81 def run(self, dataSlice, slicePoint=None):
82 # Set magVector to the same length as starLumFunc (lower edge of mag bins)
—> 83 magVector = slicePoint[f’starMapBins_{self.filtername}’][1:]
84 # Pull up density of stars at this point in the sky
85 lumFunc = slicePoint[f’starLumFunc_{self.filtername}’]

KeyError: ‘starMapBins_g’

yoachim · February 10, 2020, 6:42pm

Hi @willclarkson! I think I just patched this recently, so if you update to the latest weekly build (or clone the MAF repo and declare it etc) it should “just work”. Note we also just added TRILEGAL stellar density maps from Leo Girardi, here’s a notebook where I set the metric to use the new maps: https://github.com/LSST-nonproject/sims_maf_contrib/blob/master/science/static/Crowding_tri.ipynb

willclarkson · February 10, 2020, 10:42pm

Thanks, @yoachim! I have just installed the latest weekly build (sims_w_2020_06, three days old) and declared the github sims_maf and maf_contrib. I CAN run the Crowding_tri.ipynb notebook end-to-end using the default arguments in that notebook - as long as in the metric I specify filtername=‘r’ - otherwise I get the same error as before. I guess I have two questions:

When evaluating the crowding metric in a filter other than “r”, where do I specify the filter to use for the luminosity functions in the crowding metric? I would have thought the filtername argument in the metric would have done this, but that doesn’t seem to work.
Below is the output when I run the recommended command to determine which version is being used (from this confluence page). Not being very familiar with eups, is it possible I am still using the older build?

eups list sims_maf

2.13.0.sims-24-gbe21ed04	sims_w_2020_05 current
2.13.0.sims-24-gbe21ed04+1	sims_w_2020_06
tag:lsst	lsst setup

yoachim · February 10, 2020, 11:23pm

Ah, the way MAF deals with the extra maps could probably be improved. If you don’t set the stellar map yourself, it uses the default kwargs which are for r-band. I’ve updated the example so it explicitly sets the map and metric to g-band (and sets the metric to not auto-load any maps). This probably only work for nside 64 and 128 since those are the only resolutions for the trilegal maps.

github.com

LSST-nonproject/sims_maf_contrib/blob/master/science/static/Crowding_tri.ipynb

{
 "cells": [
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "We now have metrics that use the stellar luminosity function maps to compute the errors that will result from stellar crowding."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 1,
   "metadata": {},
   "outputs": [],
   "source": [
    "import matplotlib.pyplot as plt\n",
    "%matplotlib inline\n",
    "import lsst.sims.maf.db as db\n",
    "import lsst.sims.maf.metrics as metrics\n",
    "import lsst.sims.maf.slicers as slicers\n",

This file has been truncated. show original

willclarkson · February 11, 2020, 1:05am

… very nice, that seems to work! Thanks for this!

Will

lgirardi · February 11, 2020, 1:58pm

HI
glad to see all this working!
FYI, Trilegal maps were computed at variable resolution, between nside=64 and 1024 (nside increasing towards the Plane following changes in stellar and dust density). So, we can easily generate maps with fixed resolution until nside=1024, if that’s of practical use. Just tell us if you need more resolution, and we will produce them.
BUT keep in mind: a file for one single filter with nside=128 has 100Mby, so the n=1024 would be 6.4 Gby. Maybe that’s too large for MAF.
Cheers

willclarkson · February 12, 2020, 2:47pm

Hi @lgirardi - thanks very much for this suggestion. For context, we are working on implementing the figure of merit in the Gonzalez et al. whitepaper (https://arxiv.org/abs/1812.08670) , and indeed we may require higher-resolution maps. We’ll let you know if we do need this as our implementation develops.

Thanks again!! – Will

willclarkson · March 3, 2020, 9:31am

@yoachim what do you think of @lgirardi 's suggestion that 6.4 Gb might be too large for MAF? It looks like we WILL need the Trilegal maps at higher resolution that NSIDE=128 - I’m expecting NSIDE=512 may be sufficient.

yoachim · March 3, 2020, 5:00pm

That’s too big to put in github, but I can store it at NCSA and just include scripts to pull the data down on install (that’s what we do with things like sky brightness files). Since you (probably) only need to load one filter at a time, shouldn’t be a problem running in MAF as long as you’re not using an ancient laptop or something. If someone gives me files, I’ll drop them in.

lgirardi · March 4, 2020, 8:35am

HI @yoachim
The maps will be prepared and put in the usual place in epyc. Files with nside=256 are quick to prepare but others involve a lengthy preparatory step, still not done. Hopefully everything will be ready before Friday.
Just to clarify, what we are doing is to convert files which follow the HIPS hierarchical pixelisation scheme, into fixed-resolution maps.
Cheers Leo

willclarkson · March 4, 2020, 2:11pm

Hi @lgirardi & @yoachim - this sounds great, many thanks in advance. @lgirardi, indeed, at the moment we’re using HEALPIX since that works better with the other metrics we need (ours includes both crowding and the proper motion metric, which does use HEALPIX).

@yoachim - that’s right, our implementation of the figure of merit involves running the whole area once on each filter, dumping the results to disk, then re-loading the .npz output from each filter (as well as that for the i-band proper motion metric) to perform the calculation of the figure of merit. We’re doing this on a fairly powerful desktop, so I’m not worried about downloading large files locally and then digesting them. Am I correct that the “shebang” updating incantation would pull down the new maps once they are at NCSA?

yoachim · March 4, 2020, 7:32pm

The shebang won’t do it. But I’ll try to set it so eups distrib install sims_maps does it.

yoachim · March 6, 2020, 10:13pm

OK, thanks to @lgirardi we now have nside up to 1024. Looks like all together it takes up around 50G, so I didn’t set them to automatically download. I added a shell script with curl commands to download all the files.

@willclarkson, here are the commands you can run to drop in the higher resolution maps. You should be able to do it where ever your current TriMaps are installed and it will pick them up: https://github.com/lsst/sims_maps/blob/master/TriMaps/pull_large_maps.sh

willclarkson · March 6, 2020, 11:02pm

Thanks, pulling down the 265, 512 and 1024 maps now.