Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

Apparent 2GB GriB file size limit?

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.

G

GlennCreighton

New member
I’m running ungrib.exe on some rather large > 4GB GriB2 inputs, and I’m seeing that ungrib likes to stop reading in the file about 2GB in. It completes, but has only processed a subset of the input grib file. If I create a subset of the file that is less than 2GB, ungrib reads the full file just fine. I’m thinking its running up against some limit somewhere, but am not sure where. I’m running WPS 3.8, so this may be a version thing? Is there some environment variable I'm not setting correctly before compiling such as is used to enable large file support for NetCDF?

Any help would be appreciated. Thanks!
 
Hi,
It does sound like a large file support issue, as without that, you can't have files larger than 2 GB. Do you know whether large file support was set prior to building WPS, specifically? If you aren't sure, I would recompile WPS to make sure it's utilized. You should set this in the command line, or your environment script prior to configuring WPS (csh e.g.):
setenv WRFIO_NCD_LARGE_FILE_SUPPORT 1
 
Thanks for the quick reply! Unfortunately, I already have WRFIO_NCD_LARGE_FILE_SUPPORT=1 set in my environment at compile time. I *believe* that variable only pertains to large NetCDF file support. This problem seems to be with reading in large GriB2 files and/or writing out large WPS intermediate files. I'm guessing it has more to do with the former because depending on the subset of the larger GriB2 file I'm reading in, ungrib finds a different number of valid inputs to process (e.g. say my 4GB GriB2 file has only one or two Vtable entries in the first half of the file and 10 others in the second half. When I process it with ungrib, I will get just those first 2 entries in my intermediate WPS output file. However, if I cut out the first half of the GriB file and just process that with ungrib, I will get the 10 others. Does that make sense?)
 
You're correct that the WRFIO_NCD_LARGE_FILE_SUPPORT variable pertains only to netCDF file I/O. I took a quick look through the code that ungrib.exe uses to read records from GRIB files, and it looked to me that the code was using a signed 32-bit integer for the file offset, in which case I think the code is incapable of reading beyond 2 GB from a file.

Would it be workable for you to split your GRIB files into files that are less than 2GB in size?
 
Hi Mike,

Yeah, we can do that as a workaround. Otherwise, can I not utilize some compiler option or another to override that code's choice to use a 32-bit signed integer? Also, can you specify which file it was in which you saw this declaration? Thanks for the help!

Glenn
 
The code that I was looking at was the call to baread in the rd_grib2 subroutine. The second argument to baread (in ungrib/src/ngl/w3/baciof.f) is apparently the number of bytes to skip, which is a default Fortran integer. You could try adding compiler flags to promote the default integer kind to a 64-bit integer, but I suspect this might cause problems with the interoperability of Fortran and C code: the baread subroutine calls the C routine ba_cio (in ungrib/src/ngl/w3/bacio.v1.3.c), where the integer arguments are C ints.
 
Gah, yeah my feeble first attempts at throwing, say -integer-size 64 or -m64 did not yield fruit. Any idea if this has been "fixed" in newer versions?
 
To my knowledge, there are unfortunately no updates to the GRIB-reading code that would support 64-bit file offsets.
 
You must log in or register to reply here.
Top