[pyngl-talk] PyNIO not closing grib codetables?
David Brown
dbrown at ucar.edu
Mon Nov 3 10:56:46 MST 2014
Hi Ben,
Thanks very much for your sleuthing and actually locating the problem.
In fact, I believe this problem has been fixed in the development
code, but it has been quite awhile since we released a version of
PyNIO. We are planning a new release within the next couple of months
that will have quite a few new features (including support for much
more of the NetCDF4 specification). There are also many updates to the
GRIB1 parameter tables and the GRIB2 code tables along with numerous
bug fixes.
If you would like to get a development version of PyNIO let us know.
-dave
On Mon, Nov 3, 2014 at 9:13 AM, Root, Benjamin <broot at aer.com> wrote:
> And I just realized that I didn't mention which file I was talking
> about: libsrc/NclGRIB2.c
>
> Ben
>
>
> On Mon 03 Nov 2014 10:58:33 AM EST, Root, Benjamin wrote:
>> Dived into the code, I think I found the problem. The particular RAP
>> files I am reading does emit a warning:
>> warning: Entry (242) not found in code table file
>> /nas/home/broot/centos6/lib/python2.7/site-packages/PyNIO/ncarg/grib2_codetables/ncep/4/4.2.0.1.table
>>
>> This particular issue doesn't impact me for the data I am dealing with,
>> so I ignore it. Well, it seems that in that particular code branch, the
>> file pointer does not get closed.
>>
>> In Grib2ReadCodeTable(), at line 7980, the function returns after
>> emitting that warning, but fails to close the fp pointer. I am going to
>> try adding a "(void) fclose(fp);" line to it, rebuild and install and
>> try it out.
>>
>> Cheers!
>> Ben Root
>>
>> On Mon 03 Nov 2014 10:03:49 AM EST, Root, Benjamin wrote:
>>> I had left a long-running process over the weekend to analyze about a
>>> year's worth of hourly RAP data (grib2 format). I would load up a day's
>>> worth using PyNIO, process them, and then close the files before moving
>>> onto the next day. When I got into work this morning, the analysis
>>> errorred out saying that too many files were open.
>>>
>>> I restarted it for a smaller analysis, and ran "lsof" while it executed.
>>> Here is a snippet of its output:
>>>
>>> 3
>>> /rd22/scratch/broot/centos6/lib/python2.7/site-packages/PyNIO/ncarg/grib2_codetables/ncep/4/4.2.0.1.table
>>> python2.7 17092 broot 140r REG 253,4
>>> 4998 5909053
>>> /rd22/scratch/broot/centos6/lib/python2.7/site-packages/PyNIO/ncarg/grib2_codetables/ncep/4/4.2.0.1.table
>>> python2.7 17092 broot 141r REG 253,4
>>> 4998 5909053
>>> /rd22/scratch/broot/centos6/lib/python2.7/site-packages/PyNIO/ncarg/grib2_codetables/ncep/4/4.2.0.1.table
>>> python2.7 17092 broot 142r REG 253,4
>>> 4998 5909053
>>> /rd22/scratch/broot/centos6/lib/python2.7/site-packages/PyNIO/ncarg/grib2_codetables/ncep/4/4.2.0.1.table
>>> python2.7 17092 broot 143r REG 253,4
>>> 4998 5909053
>>> /rd22/scratch/broot/centos6/lib/python2.7/site-packages/PyNIO/ncarg/grib2_codetables/ncep/4/4.2.0.1.table
>>> python2.7 17092 broot 144r REG 253,4
>>> 4998 5909053
>>> /rd22/scratch/broot/centos6/lib/python2.7/site-packages/PyNIO/ncarg/grib2_codetables/ncep/4/4.2.0.1.table
>>> python2.7 17092 broot 145r REG 253,4
>>> 4998 5909053
>>> /rd22/scratch/broot/centos6/lib/python2.7/site-packages/PyNIO/ncarg/grib2_codetables/ncep/4/4.2.0.1.table
>>> python2.7 17092 broot 146r REG 253,4
>>> 4998 5909053
>>> /rd22/scratch/broot/centos6/lib/python2.7/site-packages/PyNIO/ncarg/grib2_codetables/ncep/4/4.2.0.1.table
>>> python2.7 17092 broot 147r REG 253,4
>>> 4998 5909053
>>> /rd22/scratch/broot/centos6/lib/python2.7/site-packages/PyNIO/ncarg/grib2_codetables/ncep/4/4.2.0.1.table
>>> python2.7 17092 broot 148r REG 253,4
>>> 4998 5909053
>>> /rd22/scratch/broot/centos6/lib/python2.7/site-packages/PyNIO/ncarg/grib2_codetables/ncep/4/4.2.0.1.table
>>> python2.7 17092 broot 149r REG 253,4
>>> 4998 5909053
>>> /rd22/scratch/broot/centos6/lib/python2.7/site-packages/PyNIO/ncarg/grib2_codetables/ncep/4/4.2.0.1.table
>>> python2.7 17092 broot 150r REG 253,4
>>> 4998 5909053
>>> /rd22/scratch/broot/centos6/lib/python2.7/site-packages/PyNIO/ncarg/grib2_codetables/ncep/4/4.2.0.1.table
>>>
>>> It would seem that closing the grib file doesn't close the associated
>>> grib2 code table. As a side note, is there any reason why the codetable
>>> is not simply cached?
>>>
>>> Over a period of about 5 days worth of RAP files, I ran the lsof
>>> command, counting the number of times the table file appears:
>>>
>>> [centos6] [broot at rd22 squarepeg]$ lsof | grep table | wc -l
>>> 121
>>> [centos6] [broot at rd22 squarepeg]$ lsof | grep table | wc -l
>>> 135
>>> [centos6] [broot at rd22 squarepeg]$ lsof | grep table | wc -l
>>> 159
>>> [centos6] [broot at rd22 squarepeg]$ lsof | grep table | wc -l
>>> 179
>>> [centos6] [broot at rd22 squarepeg]$ lsof | grep table | wc -l
>>> 199
>>> [centos6] [broot at rd22 squarepeg]$ lsof | grep table | wc -l
>>> 217
>>> [centos6] [broot at rd22 squarepeg]$ lsof | grep table | wc -l
>>> 241
>>>
>>> My version of PyNIO is 1.4.1.
>>>
>>> Cheers!
>>> Ben Root
>>>
>>> ________________________________
>>>
>>> This email is intended solely for the recipient. It may contain privileged, proprietary or confidential information or material. If you are not the intended recipient, please delete this email and any attachments and notify the sender of the error.
>>>
>>> _______________________________________________
>>> pyngl-talk mailing list
>>> List instructions, subscriber options, unsubscribe:
>>> http://mailman.ucar.edu/mailman/listinfo/pyngl-talk
>>>
>>
>
> _______________________________________________
> pyngl-talk mailing list
> List instructions, subscriber options, unsubscribe:
> http://mailman.ucar.edu/mailman/listinfo/pyngl-talk
More information about the pyngl-talk
mailing list