how to deal the warning "left shift count >= width of type"

[sang_24]

Dear all,
My aim is to provide high resolution landuse and SRTM data to WRF model. For this I have followed available notes and discussion in forum. while writing text data to binary format data I have called write_geogrid.c from a fortran code but unfortunately the following warning is coming.

write_geogrid.c: In function ‘write_geogrid_’:
write_geogrid.c:104: warning: left shift count >= width of type
I am not able to modify write_geogrid.c code to avoid the warning.

with this warning, I proceed with mentioned further steps to insert high resolution data in WRF model.Unfortunately model is not getting the high resolution data when I checked the geo_em.d03.nc file

I suspect the warning could be the reason behind it. can we do anything to tackle this warning

Any help on it will be appreciated.

Thank you.
Sang

 

[kwerner]

Hi,
Can you attach the code you have written to call the 'write_geogrid.c' script, along with a log file with the full output you get when running that (that includes the error message)? Can you also attach your namelist.wps file, the GEOGRID.TBL you are using, and let me know which version of WPS you are running?

Thanks,
Kelly

 

[mgduda]

Can you attach the 'index' file that you've prepared for your data? The warning about the left shift count should only be a problem if your dataset uses 4 bytes to represent each value and if the data are signed.

 

[sang_24]

Hello kwerner,mgduda
Thanks for your reply.

I have attached the geogrid.tbl, index file and c and fortran code for writing binary data for your references.

for compilation of c program, I have done like this

gcc -D_UNDERSCORE -DBYTESWAP -DLINUX -DIO_NETCDF -DIO_BINARY -DIO_GRIB1 -DBIT32 -D_GEOGRID -O -c write_geogrid.c
write_geogrid.c: In function ‘write_geogrid_’:
write_geogrid.c:104: warning: left shift count >= width of type

Regards,
Sang

 

[mgduda]

Based on your code, the data are being written using 2 bytes per value, so the warning about left shift count should not affect the correctness of your resulting dataset in any way. Can you send a listing of your 'SRTM' directory where you've prepared the dataset? I'd like to confirm that the index file is actually called simply 'index', and that the data file is named '00001-02503.00001.02854'; the size of the data file should also be 2 * (2503 + 3 + 3) * (2854 + 3 + 3) bytes, since you've specified tile_bdr=3 in your index file.

 

[sang_24]

Hi mgduda,
My SRTM directoy contain only two files. they are

total 28M
drwxr-xr-x. 2 root root 4.0K Apr 17 11:06 .
drwxr-xr-x. 50 6840 users 4.0K Apr 10 11:39 ..
-rw-r--r--. 1 root root 28M Apr 10 16:10 00001-02854.00001-02503
-rw-r--r--. 1 root root 310 Apr 10 12:34 index

My WPS version is 3.4.1

Thanks.
Sang

 

[mgduda]

I think your data file should be named "00001-02503.00001-02854", rather than "00001-02854.00001-02503". The first two numbers in the filename are the range of x-coordinates contained in the file, and the last two numbers are the range of y-coordinates.

The size of the dataset also looks like it may be a factor of two too large: the file size should be exactly (2503 + 3 + 3) * (2854 + 3 + 3) * 2 based on the values in your index file.

 

[sang_24]

Hi, after your comment I read the WRF manual once again. There in example says, for 800 rows and 1200 columns, the file will be named as "00001-01200.00001-00800".

My 90 m data from SRTM contains ncols 2854 and nrows 2503.with reference to example the binary file will be named as "00001-02504.00001-02503".

So, I think the binary file name is as per the rule.

Regards,
Sang

 

[mgduda]

In this case, you'll need to set

tile_x = 2854
tile_y = 2503

in your 'index' file.

 

[sang_24]

Hi, I did
tile_x = 2854
tile_y = 2503 as per your suggestion.

Again plot HGT_M from geo_em.do3.nc. Again I found the terrain was not properly inserted.

In the user guide,"Given this array, the data are written to a file, row-byrow,
beginning at the bottom, or southern-most, row.For example, in the figure above,
the elements of the n × m array would be written in the order x11, x12, ..., x1m, x21, ..., x2m,
..., xn1, ..., xnm."

For this ,the following codes in geogrid_clc.f90 were suppose to do same
-----------------------------------------------------------------------------
! reverse the data so that it begins at the lower-left corner
do j = 1, ny
rarray,j) = iarray,ny-j+1)
end do
------------------------------------------------------------------------------

Thanks.
Sang

 

[mgduda]

You mention that "the terrain was not properly inserted." Is the terrain field zero everywhere, or does it look like nonsense? Can you attach a plot? Also, have you addressed the mismatch in the size of the 00001-02854.00001-02503 file (it was about 28 MB in your directory listing) and the specification in your index file (which suggests the file size should be (2854 + 3 + 3) * (2503 + 3 + 3) * 2 bytes)?

 

[sang_24]

hi,
my terrain looked nonsense.
though I have gone through FAQ but unable to load my bmp plots of terrain from desktop.

Regards,
sang

 

[mgduda]

If the terrain looks like nonsense, that at least indicates that geogrid is reading your data files. Have you addressed the file size issue that I mentioned in my previous post? Once you've addressed that, you can try adding the line

endian=little

to your index file in case you suspect the data were written in little-endian byte order; the default in geogrid is to assume big-endian byte order.

 

[sang_24]

Hi,
file size issue is yet to be solved and still could not figure out where the problem is.

In the section "writing static data to geogrid Binary format" , manual states that "the data are written to a file, row-by-row, beginning at the bottom, or southern-most, row"ie, X11.X12....X1m X21,X22.....X2m and so on

My srtm data looks like this
4702 4723 4743 4767 4783 4800 4825 4849 4888 4918 4937 4944 4919 4892 4871 4858 4847 4819 4815 4809 4805 4812 4846 4911 4967 5015 .........


They appear like
X11=4702
X21=4723
X31=4743
X41=4767 and so on.

My impression was, they will be in same order as in the manual sequence.

In the geogrid_clc.f90 script, i have the codes for beginning the matrix at the bottom
---------------------------------------------------------------------
! reverse the data so that it begins at the lower-left corner
do j = 1, ny
rarray,j) = iarray,ny-j+1)
end do
----------------------------------------------------------------------

As terrain is nonsense, i suspect something defect in this part of coding

Regards,
Sang.

 

[kwerner]

Sang,
I'm not sure what resolution the SRTM data are that you are working with, but we have converted some SRTM 3 arc-second data to geogrid binary format. I've tested this with 1 case, but it would be nice to have someone else test it as well. Since you are having trouble with this dataset, would you like to give our data a try? If so, you can find a downloadable tar file here:
http://www2.mmm.ucar.edu/wrf/users/download/get_sources_temp.html

The tar file includes a directory with all of the binary data, an index file, and a modified GEOGRID.TBL. You can unpack this in the same directory with your other geogrid static data, and then grab the GEOGRID.TBL out of there and put it in WPS/geogrid/. You'll need to set:

geog_data_res = 'srtm_3s+default'

in your namelist.wps file, for whichever domain(s) you'd like to use it for.

Let me know how this works out.

Thanks,
Kelly

 

[sang_24]

hi,
Yesterday, I was too surprised that SRTM data was successfully inserted in WPS after I removed "title_bdr=3" from index file.

kwerner, I will try to use the data from your link too.

Now and am working with new landuse input to WPS. hope it will work in my machine too.

Regards,
Sang