[gradsusr] issues with memory overload when computing some fields

[Jennifer Adams]

On Oct 28, 2015, at 11:17 AM, Mark Sponsler <msponsler at COMCAST.NET> wrote:

> Jeff,
> One thing you can do is allocate more memory.
> Grads memory allocation:
> To increase the memory allocation above the standard 2 gig (to say 3 gig):
> grads -m 3000000  

Just to clarify … the -m option is used to increase the size of the *graphics* metafile buffer (the place in memory where the drawing commands are stored). In older versions, this option was used after receiving an “Out of buffer space” message when trying to draw an especially detailed or high-res graphic. For version 2.1, this command is irrelevant because the metabuffer is dynamically allocated on an as-needed basis, limited only by available memory on the system, just like data I/O requests and other memory allocations in GrADS. 

As for the original question...

> . Since I am doing this for cases featuring rather high amounts of CAPE, I suspect this is the reason my script is overloading on memory and crashing.
No. The data *values* are not a factor, only the grid dimensions are relevant for memory allocation. 

> I know this because I have the script setup to easily compute ensemble standard deviation for just about any field, and I have had no troubles computing spread for temperature, moisture, and wind. Yet, just changing the name of the field causes the script to crash.
This makes me think there is something wrong with the variable declaration in your descriptor file, or perhaps in the data files themselves. 

> Is there anything that can be done to get around this? I have attached the script code to this email.
> Here is some output from the jobs running the script:
> /home/jdduda/grads_scripts
> Tue Oct 27 15:06:13 CDT 2015
> Grid Analysis and Display System (GrADS) Version 2.1.a3
> Copyright (C) 1988-2015 by the Institute for Global Environment and Society (IGES)
> GrADS comes with ABSOLUTELY NO WARRANTY
> See file COPYRIGHT for more information
> Config: v2.1.a3 little-endian readline grib2 netcdf hdf4-sds hdf5 opendap-grids,stn geotiff shapefile cairo
> Issue 'q config' command for more detailed configuration information
> GX Package Initialization: Size = 11 8.5 
> Running in Batch mode
> All files closed; all defined objects released;
> All GrADS attributes have been reinitialized
> Notice: Implied interpolation for file /work/jdduda/analysis/FLSM/WRFPRS_FLSM.ctl
>  Interpolation will be performed on any data displayed from this file
> Notice: Implied interpolation for file /work/jdduda/analysis/MLSM/WRFPRS_MLSM.ctl
>  Interpolation will be performed on any data displayed from this file
> Notice: Implied interpolation for file /work/jdduda/analysis/LSMO/WRFPRS_LSMO.ctl
>  Interpolation will be performed on any data displayed from this file
> Data Request Warning:  Request is completely outside file limits
> Data Request Warning:  Request is completely outside file limits
This warning is another indicator that you may not have described the variable properly.

> Define Error:  Unable to allocate data memory
>   Size of request was -18950400 grid elements

This negative grid element count usually means there was some problem figuring out the grid dimensions of the variable. If you are using file templating, make sure all the files are identical — same variables, same dimensions, same order of variables listed (if netcdf varids are different from one file to the next, GrADS will get upset). 
—Jennifer

--
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 





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20151028/edd037fb/attachment-0001.html