<div>Hi ,</div><div>Could you please let me know how did you handle cfsrv2 data starting from 1/1/1981/00z to 12/31/2010/18z.?</div><div>Did you use cdo operator?</div><div><br></div><div>Thanks </div><div>Adv</div><div><br></div><div><br><div class="gmail_quote"><div>On Tue, Sep 1, 2015 at 5:02 AM Christopher Gilroy &lt;<a href="mailto:chris.gilroy@gmail.com">chris.gilroy@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><pre style="color:rgb(0,0,0)" class="gmail_msg">Ok, so we currently use the 1982-2010 data from:<br><br><a href="http://cfs.ncep.noaa.gov/pub/raid0/cfsv2/climo_cfsr_time/mean/" class="gmail_msg" target="_blank">http://cfs.ncep.noaa.gov/pub/raid0/cfsv2/climo_cfsr_time/mean/</a><br><br><br><br>I&#39;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<br><br>093.0 dataset but the one HUGE difference is that the mean data from the in<br><br>that NOAA CFSR link is formatted from 1982-2010 all (pre-averaged?) into<br><br>one year, 1984 whereas the UCAR data I&#39;m getting is all based on<br><br>1/1/1981/00z-12/31/2010/18z with each date it&#39;s own tdef.<br><br><br><br>So the current .ctl file is tdef 1464 (to account for leapyears) and the<br><br>UCAR data .ctl is tdef 43829 (also accounting for leapyears) and while<br><br>leapyears are currently an issue I&#39;m first and foremost curious if we can<br><br>take the UCAR data and make it into a single year file like the CFSR data<br><br>we currently use?<br><br><br><br>I have no problem having 43829 tdefs but my concern is then how would you<br><br>average them to see an anomaly for the current model run vs an average for<br><br>that same date and time?<br><br><br><br>What we&#39;re doing is, say, 2m temp anomaly. So I figure the climo averaging<br><br>would look like:<br><br><br><br>&#39;d ave(tmp2m,time=0z31jul1981,time=0z31jul2010,1464)-273.15&#39; - I can&#39;t even<br><br>begin to comprehend how we could go about not using time= and using t=<br><br>instead since the whole 1460 (non-ly) vs 1464 (ly) aspect to the data.<br><br><br><br>The only reason I&#39;m doing the time-stepping of 1464 is because there is<br><br>leapyear data. Really I&#39;d just absolutely love for it to have (beginning<br><br>time) time1=0z31jul1981 and have (ending time) time2=0z31jul2010 and have<br><br>it include every 0z31julYYYY in between regardless of whether it has<br><br>leapyear data or not. I&#39;m surprised there&#39;s no a way to literally have it<br><br>ave the zddmmmyyyy to zdddmmmyyyy range without needing to know<br><br>incrementing values. :(<br><br><br><br>It makes trying to work with leapyear data a pain, let alone I don&#39;t even<br><br>know if my above function would really be doing exactly (it does validate<br><br>somewhat identical to other 2m temp anomaly models out there) what I need<br><br>since there&#39;s really only 7 leapyears worth of data.</pre><br><br></div><br><br>_______________________________________________<br class="gmail_msg"><br>gradsusr mailing list<br class="gmail_msg"><br><a href="mailto:gradsusr@gradsusr.org" class="gmail_msg" target="_blank">gradsusr@gradsusr.org</a><br class="gmail_msg"><br><a href="http://gradsusr.org/mailman/listinfo/gradsusr" rel="noreferrer" class="gmail_msg" target="_blank">http://gradsusr.org/mailman/listinfo/gradsusr</a><br class="gmail_msg"><br></blockquote></div></div>