May 10, 2012 at 3:57 am #1389
I’m slowly getting through the data. We’re thinking about introducing EddyPro in the next workshop to hopefully encourage others to compare the process to our in-house process.
I’ve noticed a difference in the values we obtain in CO2 in ppm and µmol/mol between our in-house process and EddyPro. Most interestingly there is a distinct pattern, where our values are in our winter in the southern hemisphere and the EddyPro values are higher in our summer. It strikes me as something seasonal.
In calculating this, is there any potential for a hemispherical related bias to influence the results?
I’ve also been asked about the the CSAT diagnostics. We collect this with our fast data and are unable to include it in the analysis. Do you see merit in including the CSAT diagnostics in the process?
TimMay 10, 2012 at 6:21 pm #1589
which analyzer are you using?
And “where our values are ….(higher?) in our winter in the southern hemisphere…”?May 10, 2012 at 9:07 pm #1590
Hello Tim and Tom,
I can affirm with good confidence that there is no implication of the emisphere (or the latitude in general) on the calculation of average concetrations in EddyPro. Some more details regarding your findings may help investigating the problem:
1. which instruments are you using to measure gas concentrations?
2. which high-frequency gas measurements are you storing (e.g. molar densities, mole fractions)?
3. which high-frequency gas measurements are you using for flux computation?
4. Are you recording high-frequency measurements of air temperature and pressure (in the cell, if you’re using a closed-path instrument)?
5. In your in-house software, do you have any latitude-dependent processing step for the concentrations? if yes, which one?
6. What is the extent of these differences in terms of ppm during summer and winter?
7. Do you observe similar differences for other gases, e.g. water vapour?
8. What exactly makes you think it is an emisphere-related issue, rather than simply a seasonal issue (I am not sure I get it from your post)?
9. Do you have a plot you can share with us for visual inspection of these seasonal patterns?
Regarding the diagnostics of the CSAT (or any other anemometer, or gas analyzer): sometimes instrumental diagnostic flags are designed in such a way that individual high-frequency data records (i.e. all data corresponding to a certain instant in time) should be discarded if flagged for bad quality. I believe this is the case with the CSAT diagnostic flag.
EddyPro provides a mechanism to describe and use such flags. In the “Dataset Selection” page, in the lower part, there is a “Flags” tab. Here you can describe up to 10 flags and for each of them specify the policy for discarding data records and the corresponding threshold value.
Let’s make an example: let’s assume your diagnostic flag takes the value “0” for good records, and “1” for bad records (those that shall be discarded). In this case, what you should do is the following:
1. in the Project page, in the “Metadata File Editor”, in the “Raw file description” tab you shall give this variable a name in the appropriate column, say we call it “my_flag”.
2. Now, it the “Flags” tab of the “Dataset Selection” page you must select “my_flag” from the dropdown menu, set the threshold value to “0”, and select the option “Discard if above threshold”.
By doing that, you instruct EddyPro to exclude from the raw data all records flagged with “1” in the data column corresponding to “my_flag”. Note that in general discarding high-frequency records does not constitute a problem for flux estimates (unless too many of them are discarded, in which case EddyPro may end up with an error code), but it may well compromise spectra and cospectra shapes. which then may become unreliable. Normally this occurrence is well evident in spectra/cospectra deviating largely from the expected ones.
Hope I was clera enough. You can find more information regarding flags in the Online Help: just search for “flags”.
PS: Please note that I don’t have EddyPro in the computer from where I am writing, so I might have mispelled some of the EddyPro titles in the text.May 11, 2012 at 1:54 am #1591
Hi Tom and Gerardo,
I’m using either the Li7500.
We’re recording molar densities and using that for our computations.
We’re recording high frequency temperature only from the CSAT.
We don’t have a latitude-dependent processing step (I think the 30 aves are just that – averages from the fast data then converted to ppm).
When I simply divide EddyPro outputs against out in-house outputs, the difference in ppm is within 5% – 5% greater in from our in-house values in our winter and <5% greater from EddyPro in our summer. As we simply average our fast data, I’m interested in tracking down what looks like a systematic error. That it appears to follow a yearly cycle, I thought there might be something I was overlooking.
I should have actually looked at our H2O values to see if the same thing occurred (to be honest, I became very focused on CO2 when I noticed this).. Silly me – I’ll look through the rest of the data again.
I’ve included an image of the plot I produced to compare the values and a minute of fast data package for you to examine (sorry – the 30min file is 1.5mb – too big to include).
Thanks for your speedy reply!
TimMay 11, 2012 at 1:57 am #1592
Sorry – the files refuse to attach (it might be due to the uni’s firewall). Please email me on email@example.com and I’ll fire through the image and a full 30min fast data file.
TimMay 11, 2012 at 3:03 am #1593
“I’m using either the Li7500.” – sorry. I’m using the Li7500, not Li7500A.May 11, 2012 at 8:47 pm #1596
The problem might be the conversion from the density measurement of the 7500 (mmol/m3) to concentration (ppm) since you need to account for temperature and pressure.
I think EddyPro 3.0 used Standard Temperature and Pressure (STP) for this type of conversion. Not sure whether this still is true for 4.0.
If you used ambient temperature and pressure in your in-house calculation, you could end up with differences in output compared to EddyPro.
It would be easy to check if that’s the actual issue by doing the conversion manually for some data points.
RegardsMay 14, 2012 at 7:35 am #1597
Hi Tom and Tim,
actually, EddyPro (all versions) uses ambient temperature estimated from sonic temperature (corrected for humidity) and mean site barometric pressure, estimated from its altitude. Even better, if a reading of ambient temperature is available in the raw files (e.g. from a thermocouple), then EddyPro uses that one.
In EddyPro 4.0 you can also provide a “biomet file” containing slow measurements of ambient temperature and pressure (among the others), which EddyPro will use for the calculation of gas concentrations.
GerardoMay 14, 2012 at 3:27 pm #1598
My mistake, Gerardo.
I guess I mixed that up with an issue I once with CO2 and the “Absolute Limit” test, where I was told that EP 3.0 used STP to check the raw data against the test thresholds.
Thanks for your explanation.May 14, 2012 at 4:21 pm #1599
actually this point does require some further explanation.
Given my former answer, you may wonder why EddyPro actually uses standard T and P when it gets to filtering outranged data in the Absolute Limits test.
The reason is merely related to the sequence of operations and the structure of the software. In a nutshell: at the point where EddyPro applies the Absolute Limits test (and all other Vickers and Mahrt tests), it still didn’t “recognize” the data columns corresponding to ambient temperature and pressure (if these are present at all, by the way). Thus, the only thing it can do is to use standard T and P. However, when – much later – it gets to calculating gas concentrations, T and P data (if available) have been detected and screened for quality.
It is in our plan to improve the Absolute Limits test and use measured T and P whenever possible.
GerardoMay 14, 2012 at 5:14 pm #1600
Thanks for the info, Gerardo.
So I take it that EP 4.0 also works in that sequence, i.e. STP of statistical tests and then actual temp and press for concentration calculations?May 14, 2012 at 8:18 pm #1601
Yes, exactly!May 17, 2012 at 4:24 am #1603
Hi Gerardo and Tom,
I wish I’d looked here this morning before sending an email to Gerardo – I hadn’t realised that I could include Biomet slow data in v4.0. I’ll need to re-process the data with this. I’m certain including the met data will fix this variation!
Thanks for this!
You must be logged in to reply to this topic.