Glossary

Bandflux: A flux density averaged over passband transmission, in nJy. It is given by this equation (we always assume “photon counter” detector): \(\frac{\int_0^\infty F_\nu(\lambda) T(\lambda) \mathrm{d}\lambda/\lambda}{\int_0^\infty T(\lambda) \mathrm{d}\lambda/\lambda}\), where \(\lambda\) is the wavelength, \(F_\nu(\lambda)\) is the source flux density, and \(T(\lambda)\) is the passband transmission.

BandfluxModel: A BandfluxModel is a subclass of the BasePhysicalModel class that represents broadband photometry in specific bands (band-fluxes), such as the g-band or r-band (instead of a full spectral energy distribution).

BasePhysicalModel: BasePhysicalModel is a superclass for all nodes that represent physical phenomena that produce flux. BasePhysicalModel itself is a subclass of the ParameterizedNode.

EffectModel: An EffectModel applies some transform to the flux density of an object. Example effects include extinction due to dust or white noise.

Filter: A filter corresponds to the physical filter used on a telescope to limit the wavelengths of light that hit the detector. Filters are represented by Passband objects and sets of filters are represented by PassbandGroup objects.

GraphState: The GraphState object is an internal book keeping object that tracks the values of parameters during the simulation. It is implemented as nested dictionaries where the outer dictionary maps the name of the generating node to a dictionary of that node’s parameters. The inner dictionary maps a parameter name to its values.

MOC: A Multi-Order Coverage map (MOC) is a data structure for efficiently representing a spatial region on a sphere. See the MOC IVOA note for more details.

Model: Model is used to refer to any physical phenomena that produces flux. All models are implemented as subclasses of the SEDModel or BandfluxModel classes. Also called a physical model.

Node: Nodes are the Python objects within the simulation that generate or use parameters. A node might represent a physical object that we are simulating, such as a Type Ia supernova with input parameters x0, x1, and c, or it might represent the statistical distributions for parameters, such as a Gaussian distribution for sampling an object’s redshift (z). It is easiest to think of nodes as machines for generating portions of the simulation data. Nodes are implemented as subclasses of the ParameterizedNode class.

node_label: The node label is a unique identifier for each ParameterizedNode that allows the simulation (and the user) to track which Python object (and thus which part of the simulation) is using a particular parameter value. All parameters are indexed by a combination of node label and parameter name so that multiple ParameterizedNode objects can use the same parameter name without inadvertently overwriting each other’s values. If a node label is not specified, LightCurveLynx automatically assigns one.

Observer Frame: The reference frame of the observer. Observations in the observer frame account for effects such as redshift.

ObsTable: The ObsTable represents the set of data about the individual observations being simulated, including where the telescope is pointing (RA, Dec) and conditions affecting the detector noise.

OpSim: A specific version of the ObsTable that stores data for the Rubin Observatory’s LSST Operations Simulator outputs.

Parameter: A parameter within the model corresponds to a variable in the mathematical equations for simulating flux. Each run of the simulation effectively samples the parameters in the model and uses them to compute the flux for a given model. Parameters may themselves be the result of computations performed with other parameters. For example we may choose an object’s brightness parameter from a Gaussian distribution that is parameterized by mean and standard deviation. Parameters are generated by nodes (ParameterizedNode objects) and stored in the GraphState objects.

ParameterizedNode: ParameterizedNodes are Python objects that are a subclass of the ParameterizedNode class and produce or use model parameters during the simulation. They contain built-in mechanisms for accepting samples of input parameters and producing dependent samples of output parameters. See also: node

Passband: A Passband object stores the information needed to transform the observed flux density over multiple wavelengths into a single band flux for a given filter.

PassbandGroup: A PassbandGroup object implements a collection of Passband objects, providing convenient helper functions for loading and processing multiple passbands. Generally users will use a single PassbandGroup corresponding to the filters on the instrument being simulated.

Physical model: A physical model is an astronomical phenomenon that is modeled using a subclass of BasePhysicalModel (usually also subclasses of SEDModel or BandfluxModel) that represents a physical phenomenon that produces flux.

Rest Frame: The reference frame of the astronomical phenomenon being simulated. Observations in the rest frame do not account for effects like dust extinction or redshift, because they are local to the phenomenon.

SED: Spectral energy distribution. In LightCurveLynx, this term refers to the distribution of flux density over wavelengths, \(F_\nu(\lambda)\). Flux density is in nJy, and wavelength is in angstroms.

SEDModel: SEDModel is a subclass of the BasePhysicalModel class that specifically represents flux density of a physical source as a function of time and wavelength.

Spectrograph: A spectrograph is an instrument that measures the flux density of a source as a function of wavelength.

SurveyInfo: The SurveyInfo object contains all of the information about the survey(s) being simulated, including the observation information (ObsTable), passbands (PassbandGroup), and noise model for each survey.

Wavelength: Photon wavelength, in angstroms.