[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