[gradsusr] Problem with Ensemble Files

[Tom Hultquist]

Jennifer,

No problem, I just didn't want to provide too many details initially. The
GRIB files are from the CFS off of NOMADS. I'm grabbing 6-hourly files from
the 4x per day runs, and just grabbing member 1 (for a certain window of
time, whereby the previous files over the past five days will overlap the
same time period for which I'm computing things). The files are at
http://nomads.ncep.noaa.gov/pub/data/nccf/com/cfs/prod/cfs/cfs.20140117/00/6hrly_grib_01/with
YYYYMMDD/CC changing depending on date/cycle downloaded.

The ctl file for the most recent "run" is attached. It works ok except for
the issue I described (member #3 always causes the issue). GrADS is version
2.1.a1, although I also had the issue with 2.0.2. As best I can tell
g2ctl.pl is 0.0.4o, so perhaps that is an issue (since I do see a more
recent version, 0.0.8.8 online). I suppose I'll give that a shot in the
meantime.

tom


On Sun, Jan 19, 2014 at 8:39 PM, Jennifer Adams <jma at cola.iges.org> wrote:

> Tom,
> Can you please provide the source of your grib files, and the descriptor
> file that doesn't work? I can't resolve a problem that can't be reproduced.
> It would also be useful to know the version of GrADS and g2ctl you're using.
> --Jennifer
>
> On Jan 19, 2014, at 3:12 PM, Tom Hultquist wrote:
>
> I have a set of files with different initial times, whose forecast times
> overlap so that I can use them as an ensemble dataset. I am using g2ctl.pl with
> the -ens option, and it is creating a proper ctl file. I thought everything
> was working fine, but then noticed some oddities in a few calculations I
> was doing. So, I decided to view data from each member interactively in
> GrADS, using the ctl file which was created by g2ctl.pl. For some reason,
> it would not display anything from the third ensemble member (entire grid
> undefined). There was, however, nothing wrong with the file, since it
> worked fine if viewed individually outside of the ensemble set. In
> addition, when a new ctl is created later, and that member 3 became member
> 4, it no longer caused a problem. However, the "new" member 3 (which was
> previously member 2) had the same issue. When looking at the gribmap
> feedback (with -v turned on), I can see it runs into issues with valid
> times being outside of file limits (which indeed is true, since the files
> overlap, but don't cover the exact same time frame as member 1). When
> gribmap has this error, it shows it= (e.g. it=10) vs t= for the valid time
> conflict. I couldn't find any info on what it= references. The same error
> happens with subsequent files (members 4-20), but gribmap appears to scan
> those files twice and they display properly for me.
>
> Has anyone experienced anything like this, and/or have any suggestions?
> _______________________________________________
> gradsusr mailing list
> gradsusr at gradsusr.org
> http://gradsusr.org/mailman/listinfo/gradsusr
>
>
>  --
> Jennifer M. Adams
> Center for Ocean-Land-Atmosphere Studies (COLA)
> 111 Research Hall, Mail Stop 2B3
> George Mason University
> 4400 University Drive
> Fairfax, VA 22030
>
>
>
>
>
>
> _______________________________________________
> 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/20140119/90a6d9a9/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CFS_ensemble1.ctl
Type: application/octet-stream
Size: 2108 bytes
Desc: not available
Url : http://gradsusr.org/pipermail/gradsusr/attachments/20140119/90a6d9a9/attachment.obj