1. OFR Calculator v 1.4H Donna Sueper Jimenez Group, CU Boulder, April 1, 2014 1

2. 2 The main output of the OFR panel are, in general two plots: the relative and absolute oxidation enhancement as a function of oxidation age/OH enhancement. Introduction These sample plots show the individual measurements and averages obtained by grouping the data into equally numbered points in the x dimension. These graphs can be modified to show the individual measurements colored by a third trace, and to show averages sorted into day and night groupings. The no-Oxidant data is averaged separately, to one value. The analysis steps can be broken down into 3 main steps: (1) Ensure a good comparison of ambient data and reactor data by adjusting Ox enhanced data based on a comparison of data taken through reactors with no oxidative forcing and ambient data. (2) Calculate the absolute and relative enhancements for the chosen oxidant. (y-axis) (3) Plot the data and generate averages. (x axis)

3. Code consists of 2 ipfs: OFR_Tools_v1.* which IS NOT intended to be edited by users OFR_Field_v1.* which IS intended to be edited by users and one possibly additional ipf : OFR_Extras_v1.*. The ‘extras’ pf consists of functions which may or may not be in your current experiment. Simply comment out the functions within the extras ipf until you can compile your experiment. From the main OFR menu in Igor, select “Make OFR Panel” and this panel will appear: Anything italicized in the panel does not work yet. 3

4. Step 0. Review parameters Pressing the Step 0 gold button enlarges the panel to include the display of several ‘popable’ tables. Pressing the right-side gray “Hide OFR settings” hides these tables. All entries in the table are saved as you type them in. All tables must have the same number of points within the waves shown in each table. The OFRReactorTable consists of two waves: root:OFR:ReactorID root:OFR:ReactorVolume The user should enter a name for each reactor and it’s volume in liters. The reactor name should be Igor-friendly (does not begin with a number, etc). Reactor names will be used in subsequent tables to identify oxidant and flow states. Below is a sample of a filled in OFRReactorTable: Step 0. Review parameters: OFRReactorTable 4

5. Step 0. Review parameters: OFRParameterTable The OFRParameterTable consists of three waves: root:OFR:AmbParametersDescription root:OFR:AmbParametersUnits root:OFR:AmbParametersValue The purpose of this table is to have one place for all the values needed for exposure calculations; entries can be numerical constants or the full path of time-dependent waves (all waves must be the same size/index as your time wave for AMS data). See the OFROxTable for further information. The names and units of some parameters, specifically the ones given by default must not be changed, (i.e. Reactor_Key, AmbPres, AmbTemp) but the values should be changed (the defaults are only entered for guidance). Below is a sample of a filled in OFRparameterTable: An important parameter is Reactor_Key. The wave for this parameter must contain integers; the value of 0 indicates an ambient measurement; 1 measurement through the reactor identified in the first row of the previous reactorID table, etc. Users can use the syntax such as key = valve[p] == 3 ? key[p] : 2 to generate this wave. This reactor_key wave may also have nans. 5

6. Step 0. Review parameters: OFRReactorFlowTable The OFRReactorFlowTable consists of these waves: root:OFR:ReactorFlowID root:OFR:ReactorFlowDescription root:OFR:ReactorFlowValue root:OFR:ReactorFlowStartRun root:OFR:ReactorFlowStopRun The purpose of this table is to have one place to document changing flow rates. Below is a sample of a filled in OFRReactorFlowTable : Entries in the first column must match reactor names as is given in the OFRReactorTable. The wave ReactorFlowDescription is for user’s edification only; entries in this wave are not used in calculations. 6

7. Step 0. Review parameters: OFROxTable The OFROxTable consists of these waves: root:OFR:OxName root:OFR:OxDescription root:OFR:OxReactorID root:OFR:OxKeyWaveList root:OFR:OxRunStart root:OFR:OxRunStop root:OFR:OxMeasPostReactor The purpose of this table is to have one place to document changing oxidation conditions. Below is a sample of a filled in OFRReactorFlowTable :  Entries for the OxName must be Igor-friendly.  Entries in the third column must match reactor names as is given in the OFRReactorTable.  Entries in the OxKeyWaveList must use names set by the user in the OFRParameterTable.  The wave OxDescription is for user’s edification only; entries in this wave are not used in calculations. 7

8. Step 1. Validate settings This step checks and validates user entries. It checks: for the existence and consistent length of the time series and run series waves all waves indicated by non numeric entries in the OFRParameterTable It updates/ fill in the drop down menu above the step 3 gold button with all (unique) oxidant scheme names (i.e. hardOH, softOH, O3, NO3, etc) It generates important key waves: root:OFR:AmbKey consisting of 0s and 1s, when the measurement is ambient, bypassing all reactors and chemical, physical manipulation of the signal before it reaches the detector root:OFR:Mask_Ox*_Reac* where Ox* is a string for each Oxidant name and Reac* is a string for each reactor. There will be (# reactors ) x (# unique oxidant names) such waves. In the example given here, these are root:OFR:Mask_HardOH_PAM, root:OFR:Mask_softOH_PAM. It also sets the dimension labels of each row of the wave root:OFR:AmbParametersValue to the value given in root:OFR:AmbParametersDescription. If a user changes any values within the any of the settings tables, the user needs to redo Step 1. 8

9. Step 1: Validate settings: OFR_ReactorFlow_timeGraph The purpose of the graphs optionally displayed in step 1 are to validate by visual inspection the sequence of OFR settings. If no error messages pop up, two plots are available. OFR_ReactorFlow_TimeGraph, or ‘Flow tseries’ This time series plot has (number of Reactors)-many y axes. One trace per reactor indicates the flow values as entered by the user in the OFRReactorFlowTable. For runs not indicated in the table the code performs a linear interpolation in time. Another trace per reactor indicates when the system was measuring through the reactor as indicated in the Reactor_key wave. 9

10. If no error messages pop up, two plots are available. OFR_OxLights_TimeGraph, or ‘Ox tseries’ This time series plot has (number of Oxidant schemes)-many vertical axes. One trace per oxidant scheme indicates when we were using this oxidant scheme as defined in the OFROxTable. Another trace per oxidant scheme indicates when the system was measuring through the reactor but in the “No Oxidant or NoOx” state; there is one such wave per reactor. This key wave is useful for when we want to compare the true ambient signal to the signal (“adjust to ambient”) when we measure through the reactor but do not add any oxidative influences to the sample. Step 1: Validate settings:OFR_OxLights_TimeGraph 10

11. Step 2. Generate adjusted to ambient OFR wave Before pressing the gold “2. Adjust OFR..” button the user needs to input several parameters: 2i. Result waves folder location A string containing the full path of a new or existing Igor data folder where all resulting waves will be located. 2ii. Wave to analyze A string containing the full path of a wave containing the OFR-enhanced time series wave. This wave is typically generated from squirrel or Pika. Users are encouraged to use or rename this wave to contain few (10ish )characters. In the example that follows this wave will be named HROrg_PAM; the entry in the panel looks like “root: HROrg_PAM”. 2iii. Optional wave containing only ambient measurements If this parameter is left blank, the code will look to the values in the wave indicated in 2ii and the ambient key wave root:OFR:ambKey to identify the true ambient measurements. The code will then extract these ambient measurements and create a wave containing only these measurements and fill in the name of this wave for future use. If this parameter is blank, then it assumes that wave entered in 2ii contains ambient measurements. Users may want to supply their own ambient wave if they want to remove data spikes that may be in the original data or for any other reason. The code will automatically average the ambient wave entered in 2iii over the root:OFR:ambKey periods. The first task that is done in the step 2 gold button calculation is the generation of the average ambient wave. 11

12. 12 Step 2. Generate adjusted to ambient OFR wave The gold “2. Adjust OFR..” button performs the following calculations, mostly in the function named OFR_Adjust2Ambient : Generates several waves with suffixes as listed in the initial comments of the tools ipf. Users are encourage to become familiar with these suffixes.  The wave *AmbAvg contains averages of ambient data; there is one value per contiguous ambient measurement.  The wave *AmbAvg Int contains interpolated values of *AmbAvg. Linear interpolation is performed with the x wave being the time series wave.  The wave *NoOxR contains ratios of OFR at no oxidant to Ambient  The wave *NoOxD contains differences of OFR at no oxidant to Ambient  The wave *NoOxRInt contains interpolated values of *NoOxR  The wave *NoOxDInt contains interpolated values of *NoOxR  The wave *AAD contains the Ox enhanced wave adjusted to ambient via difference  The wave *AAR contains the Ox enhanced wave adjusted to ambient via ratio By default the *AAR wave is input the parameter for step 3. Users must use their own judgment for cases when the ratio values vary too much due to low overall signal. Note that the calculations are independent of an oxidant scheme. However, data is calculated at each oxidant scheme and interpolated across each scheme. This may result in step functions when switching between reactors, for example.

13. 13 Step 2. A2A* graph The graph A2A_* is automatically generated and illustrates the calculated waves. For each oxidant scheme and each reactor, there will be plotted on the lower right axis the mask waves indicating the no-oxidant time periods. The graph below does not show typical conditions.

14. 14 Step 3. Calculate Ox-enhanced ratio, difference to ambient It is at this point in the analysis that an oxidant needs to be selected in the popup menu “Consider this oxidant”. The gold “3. Calc ratio,..” button performs calculations, mostly in the function named OFR_calc_ratioDiffToAmbient. The code generates several waves with suffixes as listed in the initial comments of the tools ipf.  The wave *Rat contains ratios of adjusted to ambient OFR to ambient  The wave *Dif contains differences of adjusted to ambient OFR to ambient  The wave *RatI contains interpolated values of *Rat  The wave DifI contains interpolated values of *Dif By default the *RatI and *DifI wave name is put into the parameter for step 4. As in the case of calculations done in step 2, data is calculated at for each reactor and each oxidant scheme.

15. 15 Step 3. RatDif* graph The graph RatDif_* is automatically generated and illustrates the calculated waves. Again, these waves are specific to an oxidation scheme, such as hardOH. But this is only to “nan out” regions not in the oxidant scheme. The window name will contain as much of the name of the original wave to analyze (with suffixes) as is possible.

16. 16 Step 4. Calculate, plot quantiles of *Rat and *Dif waves The main function that is called when this gold button is pressed is called OFR_CalcPlotQuantiles. Within this function the function OFR_Calc is called; within this function the photochemical age in days and exposure waves are calculated. Within OFR_Calc two functions within the field ipf are called for each oxidant method: OFR_CalcPrep_XXX where XXX is the oxidant method such as hardOH OFR_CalcOx_XXX where XXX is the oxidant method such as hardOH OFR_CalcPrep_XXX requires two parameters and returns a wave of wave references Hence, the function declaration can looks like Function/wave OFR_CalcPrep_HardOH(num, Air_molec_cm3) variable num wave Air_molec_cm3 The main purpose of this function is to check the existence and length of waves needed for the oxidation calculation. This ‘prep’ function is only called once, at the beginning of OFR_Calc to prepare for all calculations to come. It does no ‘real’ work. Within the OFR_Calc function the wave returned from OFR_CalcPrep_XXX is called ThisOxWaves and is used within the OFR_CalcOx_XXX function.

17. 17 Step 4. Calculate, plot quantiles of *Rat and *Dif waves OFR_CalcOx_XXX requires several parameters; two of which, the Photochemical Age and the Oxidant Exposure waves will be filled in within this function. As an example, below is the function declaration for hardOH: Function OFR_CalcOx_hardOH(ThisOxWaves, OxMask, OxKeyWaveList, reactor_resTime, flow, O3BackOfReactorWave, AmbO3Wave_molcm3, ExpResultWave, AgeResultWave) wave/wave ThisOxWaves wave OxMask, reactor_resTime, flow, O3BackOfReactorWave, AmbO3Wave_molcm3, ExpResultWave, AgeResultWave string OxKeyWaveList For each row in the Oxidant table the function OFR_CalcOx_XXX is called. This helps ensures that only the runs within each condition are analyzed separately. It is the user’s responsibility that the calculations within each OFR_CalcOx_XXX function are correct. Next, the code uses the user-settable parameters of # of quantiles, optional day/night separation and optional f(z) color scheme choice to calculate averages and the plots such as in slide 2. The data is actually plotted twice, once one bottom axis, a second on the top axis. This is to ensure that the plotted values are valid if the user modifies the top or bottom axis range. Recall that the no-oxidant data is averaged into it’s own separate bin. The final graph will have (num of quantiles + 1) many averages displayed.

18. 18 So what do I do? The user is responsible for: Entering all necessary information into the OFR tables. Create/modify/append the function OFR_CalcPrep_XXX and OFR_CalcOx_XXX where XXX is each oxidant listed in the oxidant drop down menu. In all cases, users should follow the examples given herein and within the code to do the modifications. How can I ensure that the data doesn’t perform an average over a time period where the there were interruptions? If for example the system stopped and restarted in an ambient state but you don’t want to average over the entire (single) ambient period, simply change your ambient key wave to include nans. For example change the value at the restarted run to be nan. The code looks for contiguous measurements when it does it’s averaging.