Please reply to this post to report any bugs and issues that you discover.
Bug Report(17 posts) (6 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)
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 firstname.lastname@example.org. 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 10 months ago #
We are wrapping up the work to release 4.2. We are hoping to release this week... fingers crossed!Posted 10 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 5 months ago #
I've spotted two bugs in the new 5.0.0 version of EddyPro:
1) When starting Advanced processing it seems that EddyPro fails to copy the project-file into
<drive>:\Users\<username>\.licor\eddypro\5.0.0\ini. Copying the file manually seems to fix the problem. Otherwise error(7) occurs.
2) The progress bar in the new version doesn't really display the progress. It just endlessly spins, but no percentage of the actual progress made is shown.
My OS: Win7(64-bit)Posted 2 months ago #
I am using EddyPro 5.0.0 and found the following 2 bugs related to the use of TOB1 binary files in EddyPro:
1. My TOB1 original data-files have been split to 30min TOB1 files with header and without timestamp using CampbellSci's CardConvert. In the pull-down menu next to the TOB1 raw-file-format definition you can select to automatically detect the column binary formats. As this information is available in the header I chose this option (it is also the default option). Upon running the program I get:
Fatal Error (31): TOB1 data format not recognized .....
When I change in the option in the pull-down-menu from "Detect Automatically" to "Only ULONG and IEEE$ files" (which is the correct setting for my data), the EddyPro runs fine (up until the end, see the second bug-report below).
Apparently the "Detect Automatically" option does not work.
2. The LAST datafile contains less than 30min of data, which is my flux-interval. It should not pass the "Missing samples allowance" check, which I set to 10%. When I run the program it runs fine until it reaches the last data-file. I get following Warning, immediately followed by a Fatal error:
Warning (10008): available samples not enough for an averaging period. Skipping to next averaging period.
Fatal Error (35): Sorry, something went wrong. ...... Run will be closed without creating result files.
When I do the same run with TOA5 instead of TOB1 files (also with header and without timestamp), the program terminates correctly, discarding the last interval.
Apparently, using TOB1 files, after Warning (10008) EddyPro wants to continue with a next averaging period which doesn't exist resulting in the Fatal Error???
I am repeating what I stated in my email for the benefit of others.
We were able to narrow down the problem to a setting on the metadata specifically the raw file setting and number of headers. Correct the settings allowed the computation to proceed normally.
Thanks for your help Oscar.
You must log in to post.