Kushner recommends "Effective Java" by Josh Bloch "Core Java 2, Volume 1, Fundamentals" by Horstman and Cornell Wed, 11 AM: Kim: intro to SNAPSim - calibration is transmission function of Channel chain from top of atmosphere to ADUs currently by filter (finer division may be necessary later) can be function of time described by a SpectralFunction, usually TabularSpectralFunction - how to use SNAPSim: one of two ways given a calibration, run observations and cosmology (i.e., user) tool to simulate the calibration process and determine calibration budget (i.e., developer) - calibration is used to figure out which photons are observed light curve templates expected SN colors calibration software converts ADUs to magnitudes (it all starts with a library of SN spectra as func of time (currently using Nugent spectra - domains within SNAPSim 1. simulation portion a. universe b. observatory c. mission d. data generation 2. analysis e. calibration f. light curve fitting g. distance modulus fitting h. cosmology fitting - (from discussion) we handle systematic errors by running many instances of simulations drawing random errors, then seeing how the cosmology results change in the end one can generate 2000 SN light curves _once_, then apply many different calibrations with various errors and run through to cosmology results, relatively quickly (so is said) - suggestions on how to run a. create source data (spectra as function of time) b. realize a calibration, apply it c. run batch job to do light-curve fitting, light curve, distance modulus and cosmology fitting d. analyze results - currently, SNAPSim has many builtin ways to draw lots of random realizations of things like dust, SN intrinsic luminosity, etc. - Alex believes it's easier/better/more logical to generate data once (takes long time) play with random realizations (I can't see how this works for all cases -- there are going to be times when we need to fiddle with the Observatory parameters) - Available physics code: master verbs that perform a lot of stuff CreateSNIaTargets GetSNAPStandardConfiguration CreateSNFastExpSeqGenerator ObserveTarget ExposeTarget FitLCTarget FitMuTarget FitCosmologyParameters - the Calibration team may have to add parts: add standard stars to the universe provide calibration observing sequences in the mission domain 2:20 PM: Kim continues - Propagation effects (Oin the PropagationEffect interface) universe domain has host-galaxy dust, etc. turn in "Target" observatory domain filter curves, flatfields, etc. turn in "Channel" - SNAPSim glues the "Target" to the "Channel" to combine all the effects which modify light as it goes from source to detector - Kim splits things into a. one Truth simulation creating the real values b. one Model side, where one can fiddle with various pieces (flatfields, filters, etc.) - each propagation effect can be assigned a role Truth = how the piece actually works FIT = model of how you think the piece works (this is simply a help for bookkeeping) - SNAPSim enforces MKS units, almost all the time exceptions: age of universe, hubble constant, etc. given in terms of standard assumed values wavelengths in micron specific intensity in dn / d(ln lambda) - JUnit provides a mechanism for running unit tests not required to check in code, but recommended - documentation go to http://build.snap.nersc.gov:2440/ username: snap password: D@rkEnergy has documentation on framework Javadocs Physics design -- see snap.docs.physics - people who are in charge of pieces IDE = McKee CVS = Stoughton Framework = Kushner util = Gladney and Kim universe = Gladney observatory = Kuznetsova mission = Kim S-to-N = Kuznetsova pixel-level = Stoughton calibration = Tucker light-curve-fitting = Bonnissant (sic) overall = Bernstein - reporting trouble double check to make sure you aren't being stupid contact the appropriate person in list above file bug report at https://projects.lbl.gov/mantis/main_page.php contact Gary Kushner or Alex Kim for a Mantis account (we break for examples) 4:50 PM: Kim continues The Framework - the framework is designed to support simulations saving data associated with a simulation run retrieving and overloading data in a series of simulation runs branching - some important classes in the framework are ... abstract class Noun information which can be saved the framework knows how to save a Noun the framework knows how to persist a Noun (almost) all data that needs to be saved is in the form of a Noun example: public class AbstractSupernova contains variables such as "date of explosion", "redshift", etc. values of these variables will be saved with each instance interface Verb a class which either creates Nouns or modifies Nouns examples of verbs CreateSNIaTargets GetSNAPStandardConfiguration CreateSNFastExpSeqGenerator ObserveTarget ExposeTarget FitLCTarget FitMuTarget FitCosmologyParameters interface Runfile, which does all the following set simulation identifiers specify antecedent Runfiles whose Nouns need to be accessed simulation run code built from Nouns and Verbs identify which Nouns are saved (it is possible to join together Runfiles as a "Batch" ( so that they are executed together Big example: Runfile "CreateSourceData" runs things all the way through generating raw light curves and saving them Runfile "Calibrate" turns the raw light curves into calibrated format, and saves them Batch "DoCosmology" includes Runfile "FitLightCurves" Runfile "CalcDistanceModuli" Runfile "FitCosmology" - Antecedent vs. Reference Datasets Runfiles produce datasets Runfiles can refer to data produced by other Runfiles antecedent dataset has whole contents copied into current and will be saved reference dataset has values available to current Runfile but will not be saved with the current Runfile - Accessing data go into Runfiles with Java code web browser Eclipse plugin Visualization easy API for making simple x-y plots, histograms can also use full power of JAIDA to make complicated plots one will often write little Java functions to save data in plain ASCII format, then read in another application - sharing data your data is saved in your exportDirectory as defined in the ~/.snoop/snoop.properties file can then send these giant files to others, they can read into the framework - Code distribution the distribution runs CVS HEAD don't make changes to HEAD! users should use the release jar "snap.jars.release" is stable, with a definite version (we users should probably grab code from the "snap.jars.release" ( as far as we can, but at some point will need to merge ( with HEAD or use it for latest feature - CVS areas snap.snoop.calibration can only be modified by members of the Calibration group, is owned by Doug Tucker/Sahar Allam code should only be checked in once it passes JUnit tests snap.users.* for each user's private work snap.snoop.physics.calibration not for our use and modification