[gradsusr] Problem with Ensemble Files

[Tom Hultquist]

g2ctl.pl did that for me, but it appears to have done it correctly.


On Sun, Jan 19, 2014 at 5:31 PM, Jeff Duda <jeffduda319 at gmail.com> wrote:

> 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
>
> _______________________________________________
> 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/31ff7b96/attachment.html