[wrfems] Kumar GrADS Issue
Robert Rozumalski
rozumal at ucar.edu
Fri Sep 30 09:42:53 MDT 2011
Cory,
I'll run some tests here this morning. How large is the file you are
trying to read?
It's possible that the problem exists within GrADS as I did not compile
the binaries. The 64-bit version should
support file size > 2Gb provided you are using the "-big" flag when
processing the GRIB2 files with gribmap.
This is does by default with the EMS and you can check the
$EMS_STRC/ems_post/Post_grads.pm file.
It's also possible that there is a problem with wgrib2. Test this by
using wgrib2 to list the contant of the file:
% $EMS_UTIL/bin/wgrib2 -v <large grib2 file>
Make sure it provides a complete list through the end of the file.
Check that you are using the 64-bit executables:
% file $EMS_UTIL/bin/wgrib2
% file $EMS_UTIL/grads/bin/*
This still appears to be a GrADS issue with the size of the file.
Bob
On 9/30/2011 6:55 AM, Cory Van Pelt wrote:
> Hi Bob and Matt,
>
> The file limit seems to make sense, but this is happening on a 64-bit
> system along with EMS x64 binaries.
>
> Cory
>
> On Fri, Sep 30, 2011 at 7:28 AM, Matt Foster <Matthew.Foster at noaa.gov
> <mailto:Matthew.Foster at noaa.gov>> wrote:
>
> Shouldn't the 2GB limit be gone with Large File Support (LFS)? I
> believe LFS should allow 32-bit OSes to handle up to 2TB files.
>
> Matt @ CRH
>
>
>
> On 9/29/2011 2:30 PM, Robert Rozumalski wrote:
>>
>>
>> Hello Cory,
>>
>> Because you indicated that this problem occurs "after a certain
>> forecast hour" I believe you are up against the
>> file size limit on 32-bit systems, which is 2Gb. When
>> concatenating the GRIB files it's easy for the monolithic file
>> to exceed this value. There is a test for this limit in the beta
>> release but you may still encounter the problem
>> if your processing takes place on different systems.
>>
>> Bob
>>
>>
>> On 9/27/2011 11:32 AM, Cory Van Pelt wrote:
>>> Hi Bob,
>>>
>>> I've run into something odd while plotting WRF-EMS graphics with
>>> GrADS during a 36 hour run. The graphics will become scrambled
>>> (example attached) after a certain forecast hour, and the hour
>>> in which it goes bad depends on the resolution of the model. At
>>> 8 km they scramble at around hour 21. At 10 km they go out to
>>> hour 30 before the problem starts. It seems at resolutions of
>>> above 12 km, the problem disappears. Have you seen this problem
>>> before?
>>>
>>> Thanks,
>>>
>>> Cory
>>>
>>>
>>> _______________________________________________
>>> wrfems mailing list
>>> wrfems at comet.ucar.edu <mailto:wrfems at comet.ucar.edu>
>>
>> --
>> Robert A. Rozumalski, PhD
>> NWS National SOO Science and Training Resource Coordinator
>>
>> COMET/UCAR PO Box 3000 Phone:303.497.8356 <tel:303.497.8356>
>> Boulder, CO 80307-3000
>>
>>
>>
>> _______________________________________________
>> wrfems mailing list
>> wrfems at comet.ucar.edu <mailto:wrfems at comet.ucar.edu>
>
> --
> Do not go where the path may lead; go instead where there is no path and leave a trail.
> -- Ralph Waldo Emerson
>
>
> _______________________________________________
> wrfems mailing list
> wrfems at comet.ucar.edu <mailto:wrfems at comet.ucar.edu>
>
>
>
> _______________________________________________
> wrfems mailing list
> wrfems at comet.ucar.edu
--
Robert A. Rozumalski, PhD
NWS National SOO Science and Training Resource Coordinator
COMET/UCAR PO Box 3000 Phone: 303.497.8356
Boulder, CO 80307-3000
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.comet.ucar.edu/pipermail/wrfems/attachments/20110930/0ec2e2a7/attachment-0001.html>
More information about the wrfems
mailing list