Please reply to this post to report any bugs and issues that you discover.
Bug Report(13 posts) (4 voices)
3.0.0 Beta (2011-12-14)
- First public release of 3.0 Beta. This version introduces the advanced options.
- FIX: An error occurred in the calculation of corrected fluxes if the
N2O analyzer was a closed-path one, while the CH4 analyzer was open-path
or CH4 was not present at all. The bug resulted in corrected fluxes of
N2O equal to -9999 (that is, if your N2O fluxes are not -9999, they are
not affected by this bug).
- FIX: Definition of "relative separations". No impact on calculations,
only on the output metadata.
- FIX: Control on use of cell temperature (fixed re-initialization of column
- IMPROVEMENT/FIX: In statistical tests (Spike count/removal and Amplitude
Resolution/Drop Out) length of implied windows modified so as to scale with
the length of the averaging period.
- IMPROVEMENT: handling of situations where H2O readings are not available
(air density, momentum flux).
- IMPROVEMENT: Control over peculiar situations in Fluxes23 (WPL section).
- IMPROVEMENT: Introduced support for TOB1 format "FP2"
- IMPROVEMENT: Introduced detection of very implausible values in the raw
files, and their substitution with error codes.
- IMPROVEMENT: error codes in raw files (-9999) are no longer modified
during conversions of raw units into EddyPro units
- IMPROVEMENT: better handling of situation when all GHG files have invalid
metadata or are corrupted.
- GUI IMPROVEMENT: better handling of the computations exit codes
- Fixed bug concerning fluxes calculated from CH4 and N2O mole fraction
measurements from closed path systems. The bug affected also fluxes
calculated with CO2 mole fractions, if the paired H2O was measured as
either molar density or mixing ratio. In all cases, the bug resulted
in flux values =-9999 (that is, if your fluxes are not -9999, they
are not affected by this bug).
- Fixed Altitude field zeroing in the Metadata editor.
- Changed the docking policies of the Tips dock: now it's movable and
floatable top and bottom and it could also be tabbed with the Console.
- Changed the dimension policy of the Tips dock: now it's expandable.
- Fixed misspellings.
- Used native dialog for the 'Save metadata as' button.
- GUI code cleaned up.
- fixed incorrect filtering of CH4 vars in the Processing page, in case of
Generic gas analyzer
- added the changelog file viewer in the About dialog
- fixed the SoS to temperature conversion
- more detailed diagnostic on the metadata file validation at console
- quality flags recalculated according to Mauder and Foken (2004), which
should eliminate most (possibly not all) the -9999 in the quality flags
- added CHANGELOG.txt to source and installer packages
2.1.2 (2011-05-18, not public)
- fixed problem of Access denied authorization during the processing of the
- fixed typo about the unit of measure of the Raw Data Description table
(umol/mol^3, instead of umol/m^3)
- optimized GUI for support low resolution screens (up to 800x600 px)
- rearranged widgets beetwen Project page and Processing page (ID moved to
- added input dialog for the ID field
- improved look&feel of Combo box and Spin box
- changed policies for scrollbar and scrolling behaviour into the tables
- changed default value in some table fields
- changed from QByteArrays to QString where is the possibilities of weak
- fixed selection of None variables into Processing page comnbo's when there
are already some variable
- updated the manual
- first public release of EddyPro (Express version only)Posted 1 year ago #
Hi - I like the new features of 4.1 but something I noticed previously still occurs and that is errors in the results when detrending via running mean with a generic analyzer. I record data with both a Li7200 and a Picarro CO2/CH4/H2O closed bath. If I choose the CO2 channel from the LiCor I can detrend via running mean and the data are good (similar to block averaging). However, for the Picarro the variance in the CO2 signal is often (but not always) very high using running mean (leading to bad covariances) but this does occur with block averaging. It looks to me that the running mean filter is not being initialized correctly at the start of each half-hour (starting from 0 rather than the running mean value from the previous half-hour).
Thanks for a nice product.
thanks for the comment. In order to investigate the problem, it would be helpful to have:
1. two raw file of yours
2. the corresponding ".metadata" file
As you guessed, the running mean filter is not initialized from the previous half hour. Instead, it is initialized with the first data point (which is thus not filtered). For a time constant of N samples, the first N data points are only partially filtered. The first data point to be completely filtered according to the chosen time constant is the (N+1)th.
Hi Gerardo - So it could be bad data within the TC initialization phase. Attached are files with no problem on RM (...06_12_1000.dat) and one with bad CO2 covariance (...06_12_1030.dat).
Thanks for taking a look,
as it is often the case, I wasn't able to replicate the crash. :)
I processed the two raw files using CO2/H2O from either instrument, and got quite consistent results (i.e. similar fluxes) using both "Running mean" and "Exponential running mean". Could you please post also the ".eddypro" file you used?
Here are some output files using block averaging (BAeddypro...), Running Mean (RMeddypro...), and ERM; you can see that the CO2 flux is much more variable in either of the running mean examples.
ok, I've renamed these .csv output files to .dat
I tried to see if 4hr data files would affect the running mean but it doesn't seem so. These are files used to generate some of the above data: (note I renamed the biomet file to .dat from .csv).
you actually spotted a bug. There was a mistake (the same) in the two routines for RM and ERM, which caused the "spikes" you had. I am not sure why it didn't show up when using data from LI-COR's analyzer - or why it didn't show up for all half-hours. I guess it has something to do with the actual numbers in the time series.
The fix will be available starting from the next release (4.1.1). If you are interested in having the newest executable (from the development version) including this fix, please contact me by email at email@example.com. Please note that the current executable contains also other fixes, but it has not been thoroughly tested yet.
Thanks a lot for the notice!
All the best,
When you'll public the EddyPro 4.2 or the patch about the data filter bug?
LeoPosted 6 months ago #
We are wrapping up the work to release 4.2. We are hoping to release this week... fingers crossed!Posted 6 months ago #
EddyPro 4.2 Was released in Aug 2013. You can see the list of fixes and new features at http://envsupport.licor.com/help/EddyPro4/Default.htm#Whats_New.htm
A small update was also released last week related to an error caused by NOAA website unavailability due to the US government partial shutdown. Below is the message from the product manager.
Due to the recent U.S. government shutdown, the U.S. National Oceanic and Atmospheric Administration (NOAA) website is temporarily unavailable. This update (v4.2.1) fixes a GUI bug related to the retrieval of declination correction for magnetic north from this website. The update corrects an error that occurs when the website is unavailable.
We recommend that you install the latest version of EddyPro. You can find it on the EddyPro web-page here: http://www.licor.com/eddypro
Feel free to contact us if you have any questions about EddyPro or LI-COR eddy covariance systemsPosted 1 month ago #
You must log in to post.