Defining Filters

BayeSN includes a selection of filters and standards for convenience. Alternatively, you can use your own through a simple yaml file, allowing new or updated filters to be easily implemented independently of updates to the package.

Built-in filters

BayeSN includes the following filters, grouped together by instrument, survey or system, including the name that should be used when referring to the filter within BayeSN (e.g. g_PS1 for Pan-STARRS 1 g-band). Note that if these names do not match those contained within your data files (perhaps they contain single letter SNANA filter names), you can provide a map to match up the names in the data files with the BayeSN names, as discussed in Running large BayeSN Jobs.

  • Standard

    • Strinzinger UBVRI filters

      • Names: U, B, V, R, I

      • Source: Strinzinger+11, 2005PASP..117..810S

    • 2MASS Peters Automated Infrared Imaging Telescope JHK filters

      • Names: J, H, K

      • Source: Cohen03, 2003AJ….126.1090C

    • Persson YJHK filters

      • Names: Y_P, J_P, H_P, K_P

      • Source: 1998AJ….116.2475P

  • CSP

  • DECam

  • HST

  • LSST

  • PS1

    • PanSTARRS 1 griz filters

      • Names: g_PS1, r_PS1, i_PS1, z_PS1

      • Source: Tonry+12, 2012ApJ…750…99T

  • SWIFT UVOT

    • SWIFT UVOT UBV and UVW1/UVW2/UVM2 filters

      • Names: U_SWIFT, B_SWIFT, R_SWIFT, UVW1, UVW2, UVM2

      • Source: Poole+08, 2008MNRAS.383..627P

  • USNO

    • United States Naval Observatory 40-inch telescope u’g’r’i’z’ filters

      • Names: u_prime, g_prime, r_prime, i_prime, z_prime

      • Source: Fukugita+96, 1996AJ….111.1748F; Smith+02, 2002AJ….123.2121S

  • ZTF

    • Zwicky Transient Facility gri filters

      • Names: p48g, p48r, p48i

      • Source: Bellm+19, 2019PASP..131a8002B

  • ANDICAM

    • ANDICAM at Cerro Tololo Inter-American Observatory YJHK filters

      • Names: Y_AND, J_AND, H_AND, K_AND

      • Source:

  • UKIRT

    • WFCAM zYJHK filters

      • Names: z_WFCAM, Y_WFCAM, J_WFCAM, H_WFCAM, K_WFCAM

      • Source: Hewett+06, 2009MNRAS.394..675H

  • ATLAS

    • ATLAS co filters

      • Names: c_ATLAS, o_ATLAS

      • Source: Tonry+18, 2018PASP..130f4505T

Specifying custom filters

One of the arguments for the input.yaml file outlined in Running large BayeSN Jobs, filters, is used to specify a path to a separate yaml file which details any custom filters and standards you wish to add beyond those already included. Any custom filters or standards will get included along with those built-in, so you’ll be able to mix and match between in-built filters and custom ones. Note that if you give a custom filter/standard the same name as a built-in filter/standard, your custom one will be used instead of the built-in one.

The filter yaml to specify custom filters and standards should have the following structure:

standards_root: /PATH/TO/STANDARDS/ROOT
standards:
  vega:
    path: VEGA_STANDARD.fits/.dat
  bd17:
    path: BD17_STANDARD.fits/.dat
filters_root: /PATH/TO/FILTERS/ROOT
filters:
  test_band_1:
    magsys: ab
    magzero: 0
    path: test_band_1_response.dat
    lam_unit: nm
  test_band_2:
    magsys: vega
    magzero: 0
    path: test_band_2_response.dat

These arguments are described as follows:

  • standards_root: A directory which all paths in standards are defined relative to. For example, if the standard spectrum for Vega is located at \data\standards\VEGA_STANDARD.fits and BD17 is at \data\filters\BD17_STANDARD.fits, you can just set standards_root: \data\standards and use path: VEGA_STANDARD.fits within the key for Vega and similar for BD17. Alternatively, if you use a relative path this will be treated as being relative to the location of the filters yaml file. You can also use an environment variable here as part of the path e.g. $SNDATA_ROOT. This is an optional argument present for convenience, if not specified it is assumed that the paths for each band are all full paths rather than paths relative to standards_root.

  • standards: Keys in here define all of the standards you wish to use. For each standard, the key is the name (this can be any string of your choosing), and each must have a path specifying the location of the reference spectrum for each standard - this can be either a FITS file with named columns for WAVELENGTH and FLUX, or a text file with columns for each.

  • filters_root: This specifies a directory which all paths in filters are defined relative to, behaving exactly as standards_root does for standards. Again, if you use a relative path this will be treated as being relative to the location of the filters yaml file.

  • filters: Keys in here define all of the filters you wish you use. For each filter, the key is the name (again, this can be any string of your choosing). Each filter must have a magsys key which either corresponds to one of the built-in standards (‘vega’, ‘bd17’ or ‘ab’) or a custom standard name defined in standards, defining the magnitude system for each band. Each filter must also have a magzero key, specifying the magnitude offset for the filter, and a path specifying the location of the filter response for each filter. Optionally, you can provide a lam_unit key - by default, BayeSN expects you to use filter responses with wavelength in Angstroms, but you can specify either ‘nm’ or ‘micron’ if your filter responses use nanometres or micrometres respectively and the units will be converted into Angstroms under-the-hood.

Automatic filter dropping

The wavelength range covered by the model will depend on exactly which model you use. Filters will automatically be dropped for individual SNe when they fall out of the rest-frame wavelength range covered based on their redshift. The upper and lower cut off wavelengths for each filter are defined as the wavelength where the filter response first drops below 1 per cent of the maximum value.