[gradsusr] Problem with Ensemble Files

[Jeff Duda]

Did you adjust your control file EDEF entry to correctly represent the
start time of each member?

Jeff


On Sun, Jan 19, 2014 at 5:21 PM, Tom Hultquist <weathertom at gmail.com> wrote:

> Jeff,
>
> Thanks. Yeah, I thought of doing that, but have already written the
> scripts, and they'd be way more complicated (maybe not even doable) if I
> didn't have the e dimension. It's a really bizarre problem.
>
> tom
>
>
> On Sun, Jan 19, 2014 at 5:01 PM, Jeff Duda <jeffduda319 at gmail.com> wrote:
>
>> I have run into this problem.  I just made the computations using
>> separate control files.
>>
>> Jeff Duda
>>
>>
>> On Sun, Jan 19, 2014 at 2:12 PM, Tom Hultquist <weathertom at gmail.com>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
>>>
>>>
>>
>>
>> --
>> Jeff Duda
>> Graduate research assistant
>> University of Oklahoma School of Meteorology
>> Center for Analysis and Prediction of Storms
>>
>> _______________________________________________
>> gradsusr mailing list
>> gradsusr at gradsusr.org
>> http://gradsusr.org/mailman/listinfo/gradsusr
>>
>>
>
> _______________________________________________
> gradsusr mailing list
> gradsusr at gradsusr.org
> http://gradsusr.org/mailman/listinfo/gradsusr
>
>


-- 
Jeff Duda
Graduate research assistant
University of Oklahoma School of Meteorology
Center for Analysis and Prediction of Storms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20140119/1f545acc/attachment-0001.html