Entry | Date | Title | Site | Author | #Graphics |
---|---|---|---|---|---|
254 | Sun 16-Jun-2002 | co2 signals | 8 | oncley | |
251 | Sun 16-Jun-2002 | CO2 calibration gas cylinder pressures | all | delany | |
240 | Thu 13-Jun-2002 | co2 fluxes | oncley | ||
83 | Thu 16-May-2002 | CO2 statistics | 8 | maclean | |
6 | Fri 12-Apr-2002 | CO2 lag tests on EVE | 1 | maclean | 1 |
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).
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.
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(...)).
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.
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.