MAF: crowding metric in filters other than r?

sims-maf
Tags: #<Tag:0x00007f61a473be20>

(Willclarkson) #1

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’


(Peter Yoachim) #2

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) #3

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:

  1. 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.

  2. 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

(Peter Yoachim) #4

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.


(Willclarkson) #5

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

Will


(Leo Girardi) #6

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) #7

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