[gradsusr] Climo Datasets

[Adv]

Hi ,
Could you please let me know how did you handle cfsrv2 data starting from
1/1/1981/00z to 12/31/2010/18z.?
Did you use cdo operator?

Thanks
Adv


On Tue, Sep 1, 2015 at 5:02 AM Christopher Gilroy <chris.gilroy at gmail.com>
wrote:

> Ok, so we currently use the 1982-2010 data from:
>
> http://cfs.ncep.noaa.gov/pub/raid0/cfsv2/climo_cfsr_time/mean/
>
>
>
> I'd like to use the data from UCAR since they have CFSR 1981-2010 (which seems to be what ever major organization uses?) in the
>
> 093.0 dataset but the one HUGE difference is that the mean data from the in
>
> that NOAA CFSR link is formatted from 1982-2010 all (pre-averaged?) into
>
> one year, 1984 whereas the UCAR data I'm getting is all based on
>
> 1/1/1981/00z-12/31/2010/18z with each date it's own tdef.
>
>
>
> So the current .ctl file is tdef 1464 (to account for leapyears) and the
>
> UCAR data .ctl is tdef 43829 (also accounting for leapyears) and while
>
> leapyears are currently an issue I'm first and foremost curious if we can
>
> take the UCAR data and make it into a single year file like the CFSR data
>
> we currently use?
>
>
>
> I have no problem having 43829 tdefs but my concern is then how would you
>
> average them to see an anomaly for the current model run vs an average for
>
> that same date and time?
>
>
>
> What we're doing is, say, 2m temp anomaly. So I figure the climo averaging
>
> would look like:
>
>
>
> 'd ave(tmp2m,time=0z31jul1981,time=0z31jul2010,1464)-273.15' - I can't even
>
> begin to comprehend how we could go about not using time= and using t=
>
> instead since the whole 1460 (non-ly) vs 1464 (ly) aspect to the data.
>
>
>
> The only reason I'm doing the time-stepping of 1464 is because there is
>
> leapyear data. Really I'd just absolutely love for it to have (beginning
>
> time) time1=0z31jul1981 and have (ending time) time2=0z31jul2010 and have
>
> it include every 0z31julYYYY in between regardless of whether it has
>
> leapyear data or not. I'm surprised there's no a way to literally have it
>
> ave the zddmmmyyyy to zdddmmmyyyy range without needing to know
>
> incrementing values. :(
>
>
>
> It makes trying to work with leapyear data a pain, let alone I don't even
>
> know if my above function would really be doing exactly (it does validate
>
> somewhat identical to other 2m temp anomaly models out there) what I need
>
> since there's really only 7 leapyears worth of data.
>
>
>
>
>
> _______________________________________________
>
> gradsusr mailing list
>
> gradsusr at gradsusr.org
>
> http://gradsusr.org/mailman/listinfo/gradsusr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20170126/1723ee02/attachment.html