The code driving our variability models is a part of the sims_phoUtils package. Specifically, it is saved in
This code defines two mixins, VariabilityStars and VariabilityGalaxies. These mixins provide getters for the columns 'delta_lsst_u', 'delta_lsst_g', etc. and, in the case of VarabilityGalaxies, 'delta_uAgn', 'delta_gAgn', etc. When the photometry getters (see this page) calculate the magnitudes 'lsst_u' or 'uAgn', they check to see if the InstanceCatalog contains getters for 'delta_lsst_u' or 'delta_uAgn'. If it does, these values are calculated and added to the baseline magnitudes before output. Thus, in order to include variability in a catalog, users only have to make sure that the InstanceCatalog daughter class inherits from either VariabilityStars or VariabilityGalaxies. Similarly, if users wish to calculate magnitudes in a different, non-LSST system (e.g. calculate columns such as 'myCustomMagnitude'), they just need to make sure that getter methods are defined for columns named 'delta_myCustomMagnitude' (or whatever the baseline columns are named). Assuming that the getters for 'myCustomMagnitude' are written according to the formalism specified on the Simulated Photometry page, CatSim will know what to do.
Below, we discuss how the provided variability models behind 'delta_lsst_u', 'delta_lsst_g', etc. are actually encoded.
How does Variability calculate the modified magnitudes?
There are multiple models of variability stored in the catalog simulations framework (one for each unique physical source of variability). Currently, all of the provided variability models are light curve models: example light curves (magnitude as a function of time) are stored for each of the LSST bands. When a variability model is called, it is passed in parameters initializing the light curve and an MJD (mean Julian date) for the observation. The variability model returns the change in magnitude relative to the mean magnitude for that model at that MJD. Every variable object stored in the LSST database has an attribute 'varParamStr' which is a string specifying what specific variability model corresponds to that object and what parameters need to be given to correctly initialize the model. This string is read in as an ordinary database column and passed to the method applyVariability which belongs to the class Variability, from which VariabilityStars and VariabilityGalaxies inherit. Below, for example, is the getter for 'delta_lsst_u', 'delta_lsst_g', etc. in the mixin VariabilityStars
Variability.applyVariability interprets the varParamStr and calls the correct variability model, returning a dict of delta_magnitudes.
How are the variability models encoded?
In addition to applyVariability, the Variability class contains method for each of the supported variability light curve models (e.g. 'applyMflare' or 'applyRRly'). These methods are stored in a registry dict Variability._methodRegistry. The keys of this dict are included in varParamStr. When applyVariability is called, it extracts the appropriate key from varParamStr and calls the corresponding method. Here is the source code for applyVariability
The registry dict Variability._methodRegistry is constructed using decorators. If one examines the source code in Variability.py, one sees that the class Variability is declared as:
The @register_class is a decorator defined in sims_catalogs_measures/python/lsst/sims/catalogs/measures/instance/decorators.py. When the class Variability is declared (not when it is instantiated by the user, but when it is declared by Python in preparation for a user instantiation), this decorator looks at the class and, if it does not have an attribute _methodRegistry, it creates an empty dictionary _methodRegistry. The decorator then walks through the methods defined in Variability (or whatever class @register_class has been applied to) and adds any method with an attribute _registryKey to the dictionary _methodRegistry. This is how the catalog simulator stores its physical variability models.
The actual variability models are at the end of Variability.py and they are declared something like
@register_method is another decorator (also defined in decorators.py). This decorator modifies any method to which it is applied by adding a member attribute _registryKey and setting it equal to the argument of @register_method. Thus, when @register_class walks through the methods of Variability, it will log all of the methods marked by @register_method and store them in _methodRegistry. Put another way, after the class has been declared, a call to
will call the method applyAgn defined above.