Description
@kbarbary I noticed that the default Bessell bandpasses are taken directly from the B90 paper. Those bandpasses use a convention that is different than most other sources. Bessell defines the transmission as energy detected/photon incident [fixed an error here that Kyle pointed out], rather than the more conventional photons detected/photons incident.
So instead of integrating (lambda)(F_lambda)(trans)(dlambda) to get "counts" like for most of the bandpasses you have (and your synthetic photometry code does (F_lambda/nu)(trans)(dlambda), same thing modulo constants), for Bessell you need to integrate (F_lambda)(Bessell_trans)(dlambda) to get "counts". In other words, Bessell_trans is proportional to lambda*trans.
In MLCS2k2 I allow for either of these conventions and keep track in the bandpass file. I think everyone else just adopts the modern photon transmission convention like you've done. So the simplest fix would be to just adjust your Bessell transmissions to photon units, by dividing each Bessell transmission value by lambda and then renormalizing. For B or V the results should look like Table 3 of Maiz Apellaniz (2006).
This is described more in the Appendix A of the Maiz Apellaniz paper, or footnote 2 of Suntzeff et al. (1998), reiterated in footnote 3 of Jha et al. (2006). This is one of those in-the-weeds issues that keeps coming up and is hard to squash.
Activity
rbiswas4 commentedon Sep 30, 2015
I remember this issue from before SNCosmo, and I could never figure out which transmission function file followed which of the two conventions. Maybe, we could add some metadata to each bandpass file to specify the photon/energy convention, and on instantiation change the normalization to photon convention (if the bandpass is in energy). That way we can keep the original files for comparison.
Are there other transmission functions files which have energy conventions? If you have a list, we could make sure we add that information.
saurabhwjha commentedon Sep 30, 2015
Yes, you could keep track and do the synthetic photometry properly for each convention (that's what MLCS2k2 does). But just making them all photon convention would be fine too (I don't think we'll be going back to energy counting detectors anytime soon...)
I think all of the rest of the sncosmo builtin ones (des, hst, jwst, kepler, sdss) are okay.
Here are the passbands I have in MLCS2k2 with energy units (RESPUNIT=ergs in the FITS header):
JHKs_2MASS.fits
UBVRI_Astier.fits (these are the Bessell passbands, just shifted in wavelength as prescribed by Astier et al. 2006)
RI_BTC.fits (CTIO 4m BTC camera from late-90s)
UBVRI_Bessell.fits (Bessell 1990)
RI_CTIO4m.fits (Mosaic camera on CTIO4m)
B45,V45_CTIO4m.fits (High-Z team special filters)
UBVRI_Cohen (Cohen et al. 2003)
UBVRI_Kessler (Bessell passbands adjusted in wavelength as suggested in Kessler et al. (2009))
RI_LRIS (Keck LRIS)
UBVRI_Marriner (Landolt/Cohen passbands but put on BD+17 zeropoint, not Vega)
RIZ_Suprime.fits (Subaru Suprime camera passbands)
all of these are in the aux/passbands subdirectory from
http://www.physics.rutgers.edu/~saurabh/mlcs2k2/mlcs2k2.v007.tar.gz
or
http://www.physics.rutgers.edu/~saurabh/xfer/synphot.mlcs2k2.20140619.tar.gz
kbarbary commentedon Sep 30, 2015
I think we should either:
sncosmo.read_bandpass()to specify the other transmission and do the conversion upon read. That is, the returnedsncosmo.Bandpassobject will always be in photon transmission.I'm leaning towards the later, simply for data fidelity and traceability (with clear comments in the Bessel bandpass files!).
kbarbary commentedon Sep 30, 2015
... or rather, the conversion functionality should go into the initializer for
sncosmo.Bandpass, andread_bandpass()should pass a keyword along to the initializer.rbiswas4 commentedon Oct 1, 2015
Thanks for the list!
@kbarbary : I too like the second for exactly the same reason. But I wonder if we can make it possible for the user to not have to put in the keyword. While one may expect the user to read comments in the bandpass file, it is an easy mistake to make and forget adding the keyword (even if the argument has no default value, someone will copy code for the DES bandpass and make this mistake).
That is why I would prefer having some metadata in bandpass files that are in the energy convention, and the initializer to read that metadata and do the conversion as you suggest.
Incidentally, this Bessell issue is something that is likely to affect examples in the documentation
which use the Bessell filters, for example in http://sncosmo.readthedocs.org/en/v1.1.x/simulation.html.
kbarbary commentedon Oct 1, 2015
The default will be photon transmission fraction, so 99% of the time, the user will not have to change anything. Also, for any built-in bandpasses,
sncosmo.get_bandpass()will just Do The Right Thing.I agree that more explicit metadata is always better. However, none of the raw bandpass files contain this information, and there is no standard for the format of this metadata.
rbiswas4 commentedon Oct 1, 2015
Exactly. And while super convenient, I think this increases the chance of user error in the one percent of cases where they should be using it, because many user will not be used to thinking about it.
True. And I don't know what is the best way to solve this. Is inserting metadata in energy transmission files a good thing? This leaves open the possibility for users to read the file and compare the data with say, Bessell's paper and satisfy themselves that this is what SNCosmo uses (as opposed to storing a converted it directly). Or does it make sense to add a file with the metadata with the same filename and a different extentsion to read this in.
kbarbary commentedon Oct 16, 2015
@rbiswas4 Any progress on this? We should fix this sooner rather than later.
rbiswas4 commentedon Oct 18, 2015
Not fixed yet ... having some trouble with astropy.utils.get_pkgdata_filename
This is all in:
https://github.com/rbiswas4/sncosmo/tree/bessellb_changes
fix interpretation of built-in bessell bandpasses [#111]
kbarbary commentedon Oct 28, 2015
@rbiswas4 I finished the work you started and squashed it all into one commit: e79a49c which is now in master.
@saurabhwjha might want to check that the new bessell definitions are correct (in master).
fix interpretation of built-in bessell bandpasses [#111]
kbarbary commentedon Oct 28, 2015
Also backported this fix to a v1.1.1 bugfix release.