Project

General

Profile

bug in "seasmean" and "timmean" for 1.9.2

Added by Kyle Clem about 6 years ago

I am using version 1.9.2. Previously I reported a bug in "splitseas" where the extension given does not match the actual file formate. I now have also found two new bugs in "seasmean" and "timmean". When using "seasmean", the output DJF files are given the date for Jan, not Feb; output MAM given Apr, not May; etc... For "timmean", the date and time given to the output file is wrong: for "timmean" on an MAM file, it is given an output file date of September.

Are there any patches available for these problems? I am finding this latest release to be extremely unreliable.

Thanks,
Kyle


Replies (7)

RE: bug in "seasmean" and "timmean" for 1.9.2 - Added by Ralf Mueller about 6 years ago

Hi Kyle!

Please upload some sample data, your results and the exact calls your were using to track down this behavior. If files are to large, you can use our ftp server: ftp://ftp.zmaw.de/incoming

thx in advance
ralf

RE: bug in "seasmean" and "timmean" for 1.9.2 - Added by Kyle Clem about 6 years ago

Hi Ralf,
Thank you for your reply. I am attaching four files I generated from netCDF dataset test.mslp.mon.mean.nc with the following commands:

$cdo splitseas -seasmean test.mslp.mon.mean.nc test_seasmean_ (to get seasonal data)
$cdo timmean test_seasmean_MAM.nc test_seasmean_MAM_timmean.nc (to get the long term mean of the seasonal data)
$cdo ymonsub test_seasmean_MAM.nc test_seasmean_MAM_timmean.nc test_seasmean_MAM_ymonsub.nc (to get seasonal anomalies by year)

I am trying to calculate seasonal anomalies. The first bug is in the seasmean as it gives the date of the middle month rather than the last month. The second bug is in the timmean, as it seems to produce some arbitrary date. This problem with the timmean then causes problems with the ymonsub fuction, as the dates to not match and I get the error:

cdo ymonsub (Abort): Month 3 not found!

Thank you in advance for your help.
Best regards,
Kyle

test_seasmean_MAM_ymonsub.nc (3.24 KB) test_seasmean_MAM_ymonsub.nc $cdo ymonsub test_seasmean_MAM.nc test_seasmean_MAM_timmean.nc test_seasmean_MAM_ymonsub.nc
test_seasmean_MAM_timmean.nc (117 KB) test_seasmean_MAM_timmean.nc $cdo timmean test_seasmean_MAM.nc test_seasmean_MAM_timmean.nc
test_seasmean_MAM.nc (457 KB) test_seasmean_MAM.nc $cdo splitseas -seasmean test.mslp.mon.mean.nc test_seasmean_
test.mslp.mon.mean.nc (5.32 MB) test.mslp.mon.mean.nc Original data

RE: bug in "seasmean" and "timmean" for 1.9.2 - Added by Kyle Clem about 6 years ago

Hi Ralf-

A quick follow up on my errors-this CDO version 1.9.2 was installed on a fairly old Linux machine. I suspect the compilers were quite old. Could this be a potential problem? I suspect that it's not, given it did compile successfully and the operators generally seem to be working OK, but I thought I would ask just in case you had any thoughts or suspicions to help track down these errors...

Thanks,
Kyle

RE: bug in "seasmean" and "timmean" for 1.9.2 - Added by Uwe Schulzweida about 6 years ago

Hi Kyle,

The date and time of outfile is determined by the time in the middle of all contributing timesteps of infile. You can change this default behavior by setting the CDO option --timestat_date or the environment variable CDO_TIMESTAT_DATE to "last":

cdo --timestat_date last  splitseas -seasmean test.mslp.mon.mean.nc test_seasmean_ 
cdo --timestat_date last  timmean test_seasmean_MAM.nc test_seasmean_MAM_timmean.nc
cdo ymonsub test_seasmean_MAM.nc test_seasmean_MAM_timmean.nc test_seasmean_MAM_ymonsub.nc
or
export CDO_TIMESTAT_DATE=last
cdo splitseas -seasmean test.mslp.mon.mean.nc test_seasmean_ 
cdo timmean test_seasmean_MAM.nc test_seasmean_MAM_timmean.nc
cdo ymonsub test_seasmean_MAM.nc test_seasmean_MAM_timmean.nc test_seasmean_MAM_ymonsub.nc
Cheers,
Uwe

RE: bug in "seasmean" and "timmean" for 1.9.2 - Added by Kyle Clem about 6 years ago

Uwe Schulzweida wrote:

Hi Kyle,

The date and time of outfile is determined by the time in the middle of all contributing timesteps of infile. You can change this default behavior by setting the CDO option --timestat_date or the environment variable CDO_TIMESTAT_DATE to "last":
[...] or
[...]Cheers,
Uwe

Hi Uwe,

Thanks-this looks to have done the trick! So are these issues I experienced not bugs, just newer default behavior of CDO? The version I had previously been using was from 2014, and the default --timestat_date was "last", and so I was surprised to encounter these problems. Perhaps I jumped the gun on assuming they were bugs?

Thanks,
Kyle

RE: bug in "seasmean" and "timmean" for 1.9.2 - Added by Abubakar Bello over 2 years ago

Kindly assist me on how best to calculate seasonal anomalies (DJF, OND and JFM) for geopotential height using a merged file geo79-2020.nc. My years of interest are 1989,1996,2003 and 2015.
Here are my steps for JFM
cdo yearmean -selmon,1,2,3 geo79-2020.nc 123yearmean.n
ccdo timmean 123yearmean.nc Tmean.nc
cdo -b 64 sub 123yearmean.nc Tmean.nc ano123.nc
To extract the years I did use
cdo selyear.2015 ano123.nc ano123.15.nc
cdo selyear.2003 ano123.nc ano123.03.nc
cdo selyear.1996 ano123.nc ano123.96.nc
cdo selyear.1989 ano123.nc ano123.89.nc
Are these steps the right way?

    (1-7/7)