IHOP02: Logbook Entries

IHOP02: CO2 Messages: 5 Entries..

Return to Logbook Contents Page
Entry Date Title Site Author #Graphics
254 Sun 16-Jun-2002co2 signals8oncley
251 Sun 16-Jun-2002CO2 calibration gas cylinder pressuresalldelany
240 Thu 13-Jun-2002co2 fluxesoncley
83 Thu 16-May-2002CO2 statistics8maclean
6 Fri 12-Apr-2002CO2 lag tests on EVE1maclean1


254: CO2, Site 8, Sun 16-Jun-2002 14:33:07 CDT, co2 signals
I've taken a peek at high-rate data from co2mr.s8.  Power spectra show the
noise level (assuming that the default calibration's gain is close) of only
0.1ppmV.  However, even close to local noon on a sunny day (6/14 16-17Z), the
signal-to-noise level is about 1 only at 0.2 Hz.  Furthermore, the cospectra
show no appreciable signal above about 0.02 Hz (though I might have made a
mistake accounting for the ~1s phase lag I calculated a few days ago).


251: CO2, Site all, Sun 16-Jun-2002 11:02:30 CDT, CO2 calibration gas cylinder pressures
The pressure in the CO2 cal gas cylinders have been monitored over the past
several weeks to monitor the usage.

                    Site 1                              Site 8

              1/1   1/2   1/3   1/4?  N2       8/4    8/1   8/3    N2    8/2?

31 May''02                                     2000  cappd  2150   650   2000 
 4 Jun''02                                     1890   ---   2050   320   1890
 6 Jun''02   2030  1850  2000  2000  1850
 7 Jun''02   1930  1730  1890  1890  1700
 9 Jun''02                                     1940   ---   2090  1930   2260
13 Jun''02   2000  1890  1960  2000  1180
15 Jun''02                                     1860   ---   2070  1890   1810
26 Jun''02				       1900   ---   2100  1050   1920


The primary regulator pressure indicated is not an extremely reliable indicator
 of the amount of gas in the cylinder, as the guages are not very accurate and 
 as the pressure varies with tank temperature. However, there is the indication
 that the usage of cal gas is very low.



240: CO2, Site , Thu 13-Jun-2002 23:13:48 CDT, co2 fluxes
I've done a tiny bit of playing around with co2 flux calculations from both
s1&s8, 4 Jun 12:00 and 19:00 CDT.  In all (4) cases, there is an obvious lag
of about 1s and taking this into account increases the magnitude of the fluxes
 by about 10%.  This isn't enough to explain away the huge amount of noise
in the flux calculations.  I note that the datsdr() returns fluxes with less
noise than dat(), but still way too much.  I haven't checked datsdr() with
var(readts(...)).

83: CO2, Site 8, Thu 16-May-2002 13:20:46 MDT, CO2 statistics

From EVE menu, displayed the FASTSAVE message to see the CO2 statistics:

co2mr:		 454.6
u'co2mr':	 -0.283
v'co2mr': 	0.06577
w'co2mr':	 0.01845
co2mr'co2mr':	 2.511

Saw exactly these same values in the netcdf file for May 15 17:27:30 CDT.

So it appears the statistics are being sent over GOES correctly.


6: CO2, Site 1, Fri 12-Apr-2002 08:29:47 MDT, CO2 lag tests on EVE
EVE will be applying a fixed sample lag prior to computing
covariances between the sonic winds and the fast co2 data.

This is necessary because it takes a second or two for air to
travel down the tube from the sonic to the Licor. 

Tony plans to estimate this lag by doing correlation vs lag
analysis of (the recently completed) FLOSS project data, and
scale the lag by the ratio of the tubing length at IHOP and
FLOSS (assumes that we can get approximately equal flow rates).

The CO2 lag time should be subtracted from the time tags of the
co2 samples,then re-match the CO2 samples against a buffer of sonic winds
before computing covariances.

The high-rate data is being saved on compact flash at the stations
with a CO2 sensor, so we can do correlation vs lag analysis on the
IHOP data, and apply corrected lags (possibly time-varying) for 
the final dataset. Note that this won't occur in real-time - at best
a week later.

The pertinent EVE configuration lines are 
(this example shows a lag of 2.5 secs):

SYNC: Sync20 20Hz
SONIC.U
SONIC.V
SONIC.W
SONIC.co2 DELAY=2.5
:

To check things, John created an EVE 
config which created a co2 value equal to the sonic tc, then applied the
lag before computing the wind-co2 covariances. The high rate data was 
also saved, and the data were passed through the ASTER covar process
and the results compared.  

The attached plot of simulated w'co2' 
computed on EVE and ASTER shows the agreement:  w'tc'.s2a is the
ASTER covariance computed with a phase entry in prep.config of:

  p=2.50 f=none d=(tc).s2a

I verified in the aster processing that the phase value is SUBTRACTED from
the time tags of the given variables.  Since the data match quite closely
(and zero lags and lags of the reverse sign don't) we can assume that EVE
is also SUBTRACTING the above delay value to the time tags of the wind.
John has verified that in the EVE code.