Langley Calibration. Web interface a) Limiting the Lamp Calibration dates b) Creating a Langley Calibration factor from Mauna Loa data c) Calculating the Langley Factor on the fly New Langley Calibration method. Web Interface. Limiting the Lamp Calibration
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
a) Limiting the Lamp Calibration dates
b) Creating a Langley Calibration factor from
Mauna Loa data
c) Calculating the Langley Factor on the fly
Limiting the Lamp Calibration
Done, needs debugging
Creating a Langley Calibration factor from Mauna Loa data (table: langley_calibrations)
Need to add login, needs debugging
Needs to be done.
First 8 weeks use langley calibration factor from Mauna Loa data
Otherwise use daily vnaught created by new langley method
java code already in place.
(1997 – May 2010)
Needs to be verified/examined (1997,2007 done)
Holes need to be filled in when possible
So far, all software bugs have been fixed but will continue when examining data
Better error trapping
Determination of good data/ qc codes have changed
Run la for every day
store data in table optical_depths_la
air mass is 2 -6 for VIS and 1.2/1.5 – 2.2/3 for UV
AM data only
New field added to table date_excluded (yes or no)
RunReloadVoGen.java (previous data)
RunNightlyVoGen.java (nightly load)
Reads tracking table for every site to get time period to run so will not span a serial number
Get cosine corrected voltages for every day during time period determine by tracking table
Creates la config file
Checks qc codes/ sunny days to throw out data is needed
Runs la and stores in table optical_depths_la
Runs every night after cosine corrected voltages have been loaded. Currently 7:20 am.
What if site did not poll, when to run it? During loadfile.pl maybe?
Serial Number logic. What if serial number changed during the day? Need to run twice one for old serial number and one for new serial number.
Qc code usage, what is thrown out? Need to verify since qc codes have been updated.
Better error trapping with descriptions and less debug statements
Source: LoadVoRunningMean.java(previous data)
Logic: At a serial number start:
Take first 3 values and create a mean/standard deviation
Check the next value against the mean/standard deviation derived from first 3
THROW OUT VALUE
else if (new value – mean value) > std dev * 2
just a possibility to throw out
Continue updating the mean and standard deviation for 12 values only.
If the second criteria above was selected then keep track for the next value. If you have 3 of those values you then want to keep the values. If you do not get three of those values you throw it out.
date_excluded in table optical_depths_la
Store the values you kept with mean/standard
deviation in table optical_depths_mean
Nightly logic for this. Deciding the 3 in a row logic. And also a new serial number logic. Need a table to store the 12 running mean values.
When to run it? What about a site that was missed at night?
What if no vnaughts for yesterday. Just keep previous running mean? And tag it along?
Who is going to keep track if there is no vnaughts. What was the reason/ instrument failure, cloudy day etc.
Email message/ what if discovered a problem and a flag is added/ need to rerun?
Logic: PASS 1: Input start date and end data(one day)
gets voltage intercept from optical_depths_mean table. Goes back 3 months and forward 3 months in previous data. Trims out 2 standard deviations from least squares regression. Must have a minimum of 5 to continue.
If none then use yesterdays prediction and carry it along for 2 months.... More than 2 months -9998....
If more than 5 then get a linear regression(dividing by 1000) to make values more reasonable. At end multiply by 1000.
PASS TWO: Use a weighted sum of values to try and eleviate the noise.
Num of days = date wanted - optical depth start
sum = value/(num of days*num of days)
valsDaySum = 1/(numofdays*numofdays) + sum
Store value in daily_vnaughts table.
To do: 1000) to make values more reasonable. At end multiply by 1000.Implementing nightly version.
When to run. Serial number logic.. Problems when fails.
Cannot go forward 3 months. Go back 6 instead?