wrf-model / wps Goto Github PK

View Code? Open in Web Editor NEW

199.0 199.0 157.0 6.2 MB

The official repository for the WRF Preprocessing System (WPS)

Perl 0.50% Shell 0.39% Makefile 0.80% Fortran 91.42% C 3.20% OCaml 0.10% NCL 1.32% CMake 1.41% Python 0.86%

wps's People

Contributors

Stargazers

Watchers

Forkers

wrf-cmake roshyboo mostamndi mgduda ncar huangynj yakawa davegill powersjg jimbresch andreas-h jherwehe firelab simaria hsbadr schoenemeyer uomresearchit mulangmu weiwu5 kkeene44 cacruz xianwuxue-noaa zhatin openwfm nbald byrdman1982 patrickcaohn uturuncoglu jblealjr acoat youcanf scaine1 roccco aerler jxmaster open-estuary melisadr apchoi79 limin-feng1993 bibivking tanyasmirnova micahdavid xmingzh deardenchris b4dwo1f martinjoshua maggiezj junjie2008v liliknn emillemazzaro qloridant luoyewpp nicolasgonzaleza sherlockmuco zhifzhang lpilz kursatkara grafmi noaa-national-severe-storms-laboratory ozanmert astridsuarez mwseefeldt pubali89 zhisenzhang pick2510 unusualinsights prasanthvkrishna wangpengphd simonmssu travisnmiles lionhardv2 jokervtv ndaska meteocima joejoeyjoseph sreeds82 mathieulc jierz weiwangncar robertodantas guido-offshoreweather exwexs rjvogel lyucheng729 aeinsteroid54 fengjiewen micurry dlnash yoselita arjanna incubatorshokuhou xiaofeifei00123 houcze twjuliano cenlinhe xiaohzhao5 tmgiannaros xinlei-bnu kukennakamura llp0806

wps's Issues

Need additional logic to detect WRF code downloaded as GitHub archive

If users download the WRF source code as a GitHub "archive" file from https://github.com/wrf-model/WRF/releases , the unpacked source directory will not be named WRF, but will have a name like WRF-4.0.

Somehow, we need to be able to find this WRF directory when configuring the WPS so that the path to the WRF I/O API can be added in the WPS configure.wps file.

Suggestions that have been offered:

Have the user type in the path to the WRF source code (or the name of the directory) when running the WPS configure script

WPS build fails when WRF was compiled with an 'smpar' option

When WRF was compiled with an smpar option, the WRF I/O API library contains references to OpenMP libraries (e.g., 'GOMP' with the GNU compilers). Because the WPS doesn't support an smpar option and therefore never links the OpenMP library, the build of geogrid.exe and metgrid.exe will fail with errors like:

gfortran   -o geogrid.exe cio.o wrf_debug.o bitarray_module.o constants_module.o module_stringutil.o geogrid.o gridinfo_module.o hash_module.o interp_module.o list_module.o llxy_module.o misc_definitions_module.o module_debug.o module_map_utils.o output_module.o parallel_module.o process_tile_module.o proc_point_module.o queue_module.o read_geogrid.o smooth_module.o source_data_module.o \
        /dev/shm/WPS/../WRF/frame/module_driver_constants.o \
        /dev/shm/WPS/../WRF/frame/pack_utils.o /dev/shm/WPS/../WRF/frame/module_machine.o \
        /dev/shm/WPS/../WRF/frame/module_internal_header_util.o \
        -I/dev/shm/WPS/../WRF/external/io_netcdf -I/dev/shm/WPS/../WRF/external/io_grib_share -I/dev/shm/WPS/../WRF/external/io_grib1 -I/dev/shm/WPS/../WRF/external/io_int -I/dev/shm/WPS/../WRF/inc -I/sysdisk1/duda/Thursday_test/local/include \
        -L/dev/shm/WPS/../WRF/external/io_grib1 -lio_grib1 -L/dev/shm/WPS/../WRF/external/io_grib_share -lio_grib_share -L/dev/shm/WPS/../WRF/external/io_int -lwrfio_int -L/dev/shm/WPS/../WRF/external/io_netcdf -lwrfio_nf -L/sysdisk1/duda/Thursday_test/local/lib -lnetcdff -lnetcdf \

/dev/shm/WPS/../WRF/external/io_netcdf/libwrfio_nf.a(wrf_io.o): In function `__ext_ncd_support_routines_MOD_transpose._omp_fn.0':
wrf_io.f:(.text+0x77): undefined reference to `GOMP_loop_runtime_start'
wrf_io.f:(.text+0x463): undefined reference to `GOMP_loop_runtime_next'
wrf_io.f:(.text+0x470): undefined reference to `GOMP_loop_end_nowait'
/dev/shm/WPS/../WRF/external/io_netcdf/libwrfio_nf.a(wrf_io.o): In function `__ext_ncd_support_routines_MOD_transpose._omp_fn.1':
wrf_io.f:(.text+0x517): undefined reference to `GOMP_loop_runtime_start'
wrf_io.f:(.text+0x901): undefined reference to `GOMP_loop_runtime_next'
wrf_io.f:(.text+0x90e): undefined reference to `GOMP_loop_end_nowait'
/dev/shm/WPS/../WRF/external/io_netcdf/libwrfio_nf.a(wrf_io.o): In function `__ext_ncd_support_routines_MOD_transpose._omp_fn.2':
wrf_io.f:(.text+0x9b5): undefined reference to `GOMP_loop_runtime_start'
wrf_io.f:(.text+0xd7b): undefined reference to `GOMP_loop_runtime_next'
wrf_io.f:(.text+0xd88): undefined reference to `GOMP_loop_end_nowait'
/dev/shm/WPS/../WRF/external/io_netcdf/libwrfio_nf.a(wrf_io.o): In function `__ext_ncd_support_routines_MOD_transpose._omp_fn.3':
wrf_io.f:(.text+0xe25): undefined reference to `GOMP_loop_runtime_start'
wrf_io.f:(.text+0x11e9): undefined reference to `GOMP_loop_runtime_next'
wrf_io.f:(.text+0x11f6): undefined reference to `GOMP_loop_end_nowait'
/dev/shm/WPS/../WRF/external/io_netcdf/libwrfio_nf.a(wrf_io.o): In function `__ext_ncd_support_routines_MOD_transpose._omp_fn.4':
wrf_io.f:(.text+0x1295): undefined reference to `GOMP_loop_runtime_start'
wrf_io.f:(.text+0x1685): undefined reference to `GOMP_loop_runtime_next'
wrf_io.f:(.text+0x1692): undefined reference to `GOMP_loop_end_nowait'

aarch64 support

There is support in WRF for compiling on aarch64 with gfortran and gcc (see here)

Are we also able to compile WPS on aarch64 with gfortran and gcc?

Address issues with ungrib vertical interpolation

The changes to ungrib introduced by PR #14 contain two potential issues:

If the new pressure levels are described as a , , and value, and the increment does not evenly divide the difference between the ending and starting values, the code fails.
The correctness of the vertical interpolation needs to be more closely examined: interpolating the TT field to 250 Pa from 200 Pa and 300 Pa gives values that are outside the range covered by the 200 Pa and 300 Pa values, at least in one test using GFS data.

Error in calc_ecmwf_p.exe - free(): invalid next size (normal)

Hi WRF team,

got a consistent issue with calc_ecmwf_p.exe. Below is the output with the error in.

Any advise on potential causes for this would be appreciated.

I've had two other occurrences when PRES files are just not produced at all.

Found LOGSFP field in FILE:2014-01-31_23
Reading from FILE at time 2014-02-01_00
Found SOILHGT field in FILE:2014-02-01_00
Found LOGSFP field in FILE:2014-02-01_00
*** Error in `./util/calc_ecmwf_p.exe': free(): invalid next size (normal): 0x000000000284c250 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x81489)[0x7f8bd23c4489]
./util/calc_ecmwf_p.exe[0x40620b]
./util/calc_ecmwf_p.exe[0x406a3b]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f8bd23653d5]
./util/calc_ecmwf_p.exe[0x4015d9]
======= Memory map: ========
00400000-0041b000 r-xp 00000000 00:2e 3056139                            /wrf_host/WPS/util/src/calc_ecmwf_p.exe
0061a000-0061b000 r--p 0001a000 00:2e 3056139                            /wrf_host/WPS/util/src/calc_ecmwf_p.exe
0061b000-0061c000 rw-p 0001b000 00:2e 3056139                            /wrf_host/WPS/util/src/calc_ecmwf_p.exe
0061c000-00629000 rw-p 00000000 00:00 0 
006c4000-0301c000 rw-p 00000000 00:00 0                                  [heap]
7f8bcc000000-7f8bcc021000 rw-p 00000000 00:00 0 
7f8bcc021000-7f8bd0000000 ---p 00000000 00:00 0 
7f8bd2343000-7f8bd2505000 r-xp 00000000 fd:00 36084766                   /usr/lib64/libc-2.17.so
7f8bd2505000-7f8bd2705000 ---p 001c2000 fd:00 36084766                   /usr/lib64/libc-2.17.so
7f8bd2705000-7f8bd2709000 r--p 001c2000 fd:00 36084766                   /usr/lib64/libc-2.17.so
7f8bd2709000-7f8bd270b000 rw-p 001c6000 fd:00 36084766                   /usr/lib64/libc-2.17.so
7f8bd270b000-7f8bd2710000 rw-p 00000000 00:00 0 
7f8bd2710000-7f8bd274b000 r-xp 00000000 fd:00 36367452                   /usr/lib64/libquadmath.so.0.0.0
7f8bd274b000-7f8bd294a000 ---p 0003b000 fd:00 36367452                   /usr/lib64/libquadmath.so.0.0.0
7f8bd294a000-7f8bd294b000 r--p 0003a000 fd:00 36367452                   /usr/lib64/libquadmath.so.0.0.0
7f8bd294b000-7f8bd294c000 rw-p 0003b000 fd:00 36367452                   /usr/lib64/libquadmath.so.0.0.0
7f8bd294c000-7f8bd2961000 r-xp 00000000 fd:00 36084773                   /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f8bd2961000-7f8bd2b60000 ---p 00015000 fd:00 36084773                   /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f8bd2b60000-7f8bd2b61000 r--p 00014000 fd:00 36084773                   /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f8bd2b61000-7f8bd2b62000 rw-p 00015000 fd:00 36084773                   /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f8bd2b62000-7f8bd2c63000 r-xp 00000000 fd:00 36084795                   /usr/lib64/libm-2.17.so
7f8bd2c63000-7f8bd2e62000 ---p 00101000 fd:00 36084795                   /usr/lib64/libm-2.17.so
7f8bd2e62000-7f8bd2e63000 r--p 00100000 fd:00 36084795                   /usr/lib64/libm-2.17.so
7f8bd2e63000-7f8bd2e64000 rw-p 00101000 fd:00 36084795                   /usr/lib64/libm-2.17.so
7f8bd2e64000-7f8bd2f83000 r-xp 00000000 fd:00 36367421                   /usr/lib64/libgfortran.so.3.0.0
7f8bd2f83000-7f8bd3183000 ---p 0011f000 fd:00 36367421                   /usr/lib64/libgfortran.so.3.0.0
7f8bd3183000-7f8bd3184000 r--p 0011f000 fd:00 36367421                   /usr/lib64/libgfortran.so.3.0.0
7f8bd3184000-7f8bd3186000 rw-p 00120000 fd:00 36367421                   /usr/lib64/libgfortran.so.3.0.0
7f8bd3186000-7f8bd31a8000 r-xp 00000000 fd:00 36084761                   /usr/lib64/ld-2.17.so
7f8bd339b000-7f8bd33a0000 rw-p 00000000 00:00 0 
7f8bd33a2000-7f8bd33a7000 rw-p 00000000 00:00 0 
7f8bd33a7000-7f8bd33a8000 r--p 00021000 fd:00 36084761                   /usr/lib64/ld-2.17.so
7f8bd33a8000-7f8bd33a9000 rw-p 00022000 fd:00 36084761                   /usr/lib64/ld-2.17.so
7f8bd33a9000-7f8bd33aa000 rw-p 00000000 00:00 0 
7ffdecd8d000-7ffdecdae000 rw-p 00000000 00:00 0                          [stack]
7ffdecdbf000-7ffdecdc1000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x7F8BD2E7D697
#1  0x7F8BD2E7DCDE
#2  0x7F8BD237927F
#3  0x7F8BD2379207
#4  0x7F8BD237A8F7
#5  0x7F8BD23BBD26
#6  0x7F8BD23C4488
#7  0x40620A in MAIN__ at calc_ecmwf_p.f90:?
Aborted (core dumped)

Support Generalized Vertical Coordinates

Generalized vertical coordinates are used by a number of German models, with layer heights being specified in an invariant GRIB2 such as https://opendata.dwd.de/weather/nwp/icon-eu/grib/00/hhl/

Specification:
https://www.wmo.int/pages/prog/www/ISS/Meetings/IPET-DRC_Brasilia2010/Documents/IPETDRC-II_Doc2-3_9.doc

Ability to ungrib and process layers in this format would be very useful compared to relying on pressure level model outputs for initialization.

geog_data_path should be declared with length MAX_FILENAME_LEN

An issue when the length of the geog_data_path specification reaches 128 characters has been identified by Min Zhu on this forum post: https://forum.mmm.ucar.edu/phpBB3/viewtopic.php?f=53&t=8378 .

The "dominant" option in GEOGRID.TBL files is ambiguous

Several GEOGRID.TBL files contain entries with the dominant keyword, which isn't a documented keyword. The two possible keywords for requesting the dominant category for a field are dominant_category and dominant_only, and due to the poorly formulated parsing code in source_data_module.F, the "dominant" keyword is interpreted as "dominant_category".

geogrid.exe : formatted I/O to unit open for unformatted transfers, unit 10 , file namelist.wps

Getting following error while running ./geogrid.exe

forrtl: severe (257): formatted I/O to unit open for unformatted transfers, unit 10, file WPS/namelist.wps
Image PC Routine Line Source
libnetcdf.so.19.0 00002B2A6945B1D6 for__io_return Unknown Unknown
geogrid.exe 00000000005BEC71 for_read_seq_nml Unknown Unknown
geogrid.exe 000000000040D36E Unknown Unknown Unknown
geogrid.exe 000000000040BC55 Unknown Unknown Unknown
geogrid.exe 000000000040A5B2 Unknown Unknown Unknown
libc-2.17.so 00002B2A6B511555 __libc_start_main Unknown Unknown
geogrid.exe 000000000040A4A9 Unknown Unknown Unknown

WPS compiled using configure option 19 (Intel Compiler dmpar)

Dependencies Used :
Intel Compiler 2019.5
hdf5 1.12.1
netcdf c-4.8.0-cxx-4.3.1-f-4.5.3
pnetcdf 1.12.2
libpng 1.6.36
jasper 1.900.1
flex 2.6.3

namelist.wps file :
&share
wrf_core = 'ARW',
max_dom = 1,
start_date = '2016-10-06_00:00:00',
end_date = '2016-10-08_00:00:00',
interval_seconds = 21600,
/

&geogrid
parent_id = 1,
parent_grid_ratio = 1,
i_parent_start = 1,
j_parent_start = 1,
e_we = 91,
e_sn = 100,
geog_data_res = 'default',
dx = 27000,
dy = 27000,
map_proj = 'mercator',
ref_lat = 28.00,
ref_lon = -75.00,
truelat1 = 30.0,
truelat2 = 60.0,
stand_lon = -75.0,
geog_data_path = '/WPS_GEOG',
/

&ungrib
out_format = 'WPS',
prefix = 'FILE',
/

&metgrid
fg_name = 'FILE',
/

Why is RH set to 5% between 300 and 70 hPa and Set RH to 0 above 70 hPa in WPS/ungrib/src/rrpr.F？

Hello，
I just wonder that RH was set to 5% between 300 and 70 hPa and Set RH to 0 above 70 hPa in WPS/ungrib/src/rrpr.F.
（https://github.com/wrf-model/WPS/blob/master/ungrib/src/rrpr.F) lines: 686-697.
This makes the RH between 300 and 70 hPa in met_em_d0x.nc smaller than the GFS.

cheyenne new paths to static data

Top of the repo geogrid error message on cheyenne:

ERROR: Could not open /glade/p/work/wrfhelp/WPS_GEOG/topo_gmted2010_30s/index

We need to remove the "p" subdirectory from namelist.wps

geog_data_path = '/glade/work/wrfhelp/WPS_GEOG/'

fatal: Could not open ($NCARG_ROOT/lib/ncarg/nclscripts/csm/gsn_code.ncl)

Hi,

I am a beginner of WRF. I just installed the WRFV3 and tried to run it. However, when I run the command ‘ncl plotgrids.ncl’. It always showed an error: ‘fatal: Could not open ($NCARG_ROOT/lib/ncarg/nclscripts/csm/gsn_code.ncl)’. I have set the environment variable ‘export NCARG_ROOT=/usr/’. Could you please help me? Thanks very much! The running results and self-check process is showing below:

uav@uav-UN65U:~/Build_WRF/WPS$ ncl plotgrids.ncl
Copyright (C) 1995-2015 - All Rights Reserved
University Corporation for Atmospheric Research
NCAR Command Language Version 6.3.0
The use of this software is governed by a License Agreement.
See http://www.ncl.ucar.edu/ for more details.
fatal:Could not open ($NCARG_ROOT/lib/ncarg/nclscripts/csm/gsn_code.ncl)
fatal:error at line 7 in file plotgrids.ncl

uav@uav-UN65U:/Build_WRF/WPS$ ls $NCARG_ROOT/lib/ncarg/nclscripts/csm/gsn_code.ncl
/usr/lib/ncarg/nclscripts/csm/gsn_code.ncl
uav@uav-UN65U:/Build_WRF/WPS$

Remove hardcoding of the "WRFV3" directory in the WPS 4.x.x codes. Causing compilation failures cause wrfio libraries can't be found

I have been trying to compile WPS 4.0.2 but ungrib.exe compiles and metgrid.exe and geogrid.exe fail to compile. The error messages in log.complie are

Error : Not building geogrid. Check whether WRF is compiled in /home/rwasokadt1/WRF402/WPS-4.0.2/../WRFV3

Error : Not building metgrid. Check whether WRF is compiled in /home/rwasokadt1/WRF402/WPS-4.0.2/../WRFV3

Upon scrutiny of the log.compile file, I think this compilation failure is being caused by the fact that the WPS codes, from version 3, have the below hard coded lines. These hard coded lines are distributed all over the codes but WRF_DIR2 is wrong hence compilation failures

    if [ "" = yes ] ; then \
      WRF_DIR2=../WRFV3 ; \
    else \
      WRF_DIR2=/home/rwasokadt1/WRF402/WPS-4.0.2/../WRFV3 ; \
    fi ; \
    make -i -r ungrib.exe \
            WRF_DIR="$WRF_DIR2" \

This causes problems because now we working with version 4 codes and with git cloning/wget the folder/directory is created as WRF-4.0.x after untarring and yet WPS expects the WRF folder to be .../WRFV3 or that WRF is inside the WPS folder. Beacuse of this the wrfio files required by WPS, created when WRF is compiled, cannot be found!!

exporting the WRF-4.0.x directory like below, does not work either!!
export WRF_DIR2=/home/rwasokadt1/WRF402/WRFV402_src

Possible Solutions
Change WRFV3 to WRFV4 in the WPS codes and make sure that WRF untars to WRFV4 and not WRF-4.x.x as the current case

Or allow the user to specify the path of the WRFV-4.x.x directory. Tried this now, but its not working

Interim Crazy Solution
Rename the WRF 4.0.x to WRFV3, eg $ mv WRF-4.0.2/ WRFV3

then configure WPS

and compile

then sunny days, as shown below:

$ ls -l *.exe
geogrid.exe -> geogrid/src/geogrid.exe
metgrid.exe -> metgrid/src/metgrid.exe
ungrib.exe -> ungrib/src/ungrib.exe

then ls -ls geogrid/src/geogrid.exe
Members(Pr) 3706067 Nov 24 04:43 geogrid/src/geogrid.exe

voilà

Intermediate format : Possible inconsistency between code and user guide

Hi everybody !

I would like to report a possible inconsistency between the User manual and the code:

As a reference for the latest user guide, I am using https://www2.mmm.ucar.edu/wrf/users/docs/user_guide_V4/WRFUsersGuide.pdf. It might not be the latest but it is at least the latest I have found.

On section 3-34 one can read :

integer :: iproj
! Code for projection of data in array:
! 0 = cylindrical equidistant
! 1 = Mercator
! 3 = Lambert conformal conic
! 4 = Gaussian (global only!)
! 5 = Polar stereographic

Whereas in a Fortran routine designed to write intermediate file it is written :


   ! Projection codes for proj_info structure:
   integer, public, parameter  :: PROJ_LATLON = 0
   integer, public, parameter  :: PROJ_LC = 1
   integer, public, parameter  :: PROJ_PS = 2
   integer, public, parameter  :: PROJ_PS_WGS84 = 102
   integer, public, parameter  :: PROJ_MERC = 3
   integer, public, parameter  :: PROJ_GAUSS = 4
   integer, public, parameter  :: PROJ_CYL = 5
   integer, public, parameter  :: PROJ_CASSINI = 6
   integer, public, parameter  :: PROJ_ALBERS_NAD83 = 105 
   integer, public, parameter  :: PROJ_ROTLL = 203

Regarding option number 1, rd_intermediate give reason to the second listing. Moreover, using the second list of option, no offset was found between the field and the topography !

Wishing you all the best,

Enzo

Double Precision WRF Build Causes Metgrid Failure

When WRF is built with double-precision, it causes metgrid to fail with error:
"Require grid spacing (dx) in meters to be positive! ERROR: MAP_INIT"
This error is located in module_map_utils.F
namelist.wps declares dx = 30000
print statements in module_map_utils.F confirms that dx is being read as 0.0000000E+00
map_proj = 'lambert'

Fix for GHT bug in calc_ecmwf_p.exe

We encountered corrupt GHT datafields provided by calc_ecmwf_p.exe. The problem occurs as we feed to calc_ecmwf_p only a subset of levels (24) we receive operationally from ECMWF. The corrupt GHT fields obviously result in erroneous WRF forecasts or even a crash of WRF.

Please find below the problem analysis:

The geopotential height (GHT) is calculated using the hypsometric equation (https://en.wikipedia.org/wiki/Hypsometric_equation). For that, the temperature (TT) and specific humidity (QV) are required.

Calc_ecmwf_p.exe computes the GHT at all 137 ECMWF hybrid levels, and needs TT and QV at all these levels. The program allocates memory for TT and QV 3D arrays and fills these arrays with input data. Feeding a subset of the 137 levels into calc_ecmwf_p (we only have 24 levels), means that not all levels in the 3D array are filled. The program computes the TT and QV at the missing levels using linear interpolation. Missing levels are identified by looking at the TT-value at the first gridpoint (1,1) being equal to zero.

Now, memory allocation does not mean array initialization to zero! It can happen that the value at (1,1) is unequal to zero, meaning that the level is regarded as 'valid'. This leads to corrupt temperature and specific humidity data being transferred to the hypsometric equation, which results in corrupt GHT data.

Since the subsequent pre-processing utility mod_levs.exe removes all levels except for the subset of levels, one could argue that the GHT data at the subset of levels should be correct as the GHT data is only corrupt at the missing levels.

This is NOT the case. Calc_ecmwf_p.exe computes the GHT from level to level, starting at the lowest level 137. As a result, the computed GHT at the subset of levels is based on GHT on the missing levels with corrupt GHT values.

Solution:
After memory allocation of TT and QV, force array initialization to zero.
tt(:,:,: ) = 0 & qv(:,:,: ) = 0

In theory, this should suffice: tt(1,1,:) = 0

Possible bug when ingesting static datasets in lambert projections ?

Hi everybody,

This issue is entitled as a question as I don't really believe it could be a bug. Indeed, if it was a bug, I imagine many people would have detected it before ! But, here comes my little story :

I have been struggling with WPS lately when trying to ingest two datasets. One in Lambert 93 (EPSG:2154) and one in EPSG:3035 (i.e. Lambert Azimuthal Equal Area used for european datasets). I observed a shift with respect to the topography in both cases.

However, for the European dataset (Corinne Land Cover, FYI), everything worked perfectly when I used gdal to project it to EPSG:4326 and then use WPS ! :)

So I have tried to design a toy example : The idea is to make a dummy categorical field with two lines crossing at a specific location, both in EPSG:4326 and EPSG:2154. Then, compare that value to the point in geo_em* files were it does cross to detect if a significant shifting occurs or not.

For convenience, the dummy static fields are generated with a few python lines as one can see below:

First, the static data for EPSG:4326

import numpy as np

 # Define deltalon and deltalats
 dx = 1e-3
 dy = 1e-3
 
 # Target non zero value
 tgtlon = 5.700
 tgtlat = 45.180
 
 # Number of points
 nx = 30000; nxtgt = 15000
 ny = 30000; nytgt = 15000
 
 # Make an empty field
 #field = np.reshape(np.random.randint(0,3,nx*ny,dtype=">u1"),(nx,ny))
 field = np.zeros((nx,ny), dtype="uint8")
 
 # Make the cross of non-zero values:
 field[nxtgt-2:nxtgt+2, nytgt-2:nytgt+2] = 4
 field[nxtgt-1:nxtgt+1, nytgt-1:nytgt+1] = 5
 field[nxtgt, :] = 9
 field[:, nytgt] = 11
 field[nxtgt, nytgt] = 15
 
 # Compute stratlon,startlat
 startlon = tgtlon - nxtgt * dx
 startlat = tgtlat - nytgt * dy
 print(f"Startlon : {startlon} | startlat = {startlat}")
 
 # write index file
 index_content=f"""type=categorical
 row_order=top_bottom
 category_min=0
 category_max=33
 projection=regular_ll
 dx={dx}
 dy={dy}
 known_x=1.0
 known_y=1.0
 known_lat={startlat}
 known_lon={startlon}
 wordsize=1
 missing_value=2
 tile_x={ny}
 tile_y={nx}
 tile_z=1
 units="category"
 description="Dummy"
 """
 textfile = open('index', 'w')
 textfile.write(index_content)
 textfile.close()
 
  # write field
 filename = f"{1:05d}-{ny:05d}.{1:05d}-{nx:05d}"
 print(f"write field to {filename}")
 field.tofile(filename)

Then, the static data for EPSG:2154

 import numpy as np
 from pyproj import Proj, transform
 
 ## define parameters for the lambert93 field
 
 # Define deltalon and deltalats
 dx = 100
 dy = 100
 
 # Target non zero value
 tgtlon = 912000
 tgtlat = 6457000
 inProj = Proj(init='epsg:2154') 
outProj = Proj(init='epsg:4326')
 target_lon, target_lat = transform(inProj,outProj,tgtlon,tgtlat)
 print (f"Target lon is {target_lon}, Target Lat is {target_lat}")

# Number of points
 nx = 30000; nxtgt = 15000
 ny = 30000; nytgt = 15000
 
 # Make an empty field
 field = np.zeros((nx,ny), dtype=">u1")
 
 # Make the cross of non-zero values:
 field[nxtgt-2:nxtgt+2, nytgt-2:nytgt+2] = 1
 field[nxtgt-1:nxtgt+1, nytgt-1:nytgt+1] = 2
 field[nxtgt, :] = 9
 field[:, nytgt] = 11
 field[nxtgt, nytgt] = 15
 
 # Compute stratlon,startlat
 startlon = tgtlon - nxtgt * dx
 startlat = tgtlat - nytgt * dy
 inProj = Proj(init='epsg:2154')
 outProj = Proj(init='epsg:4326')
 startlon,startlat = transform(inProj,outProj,startlon,startlat)
 print(f"Startlon : {startlon} | startlat = {startlat}")
 
 # write index file
 index_content=f"""type=categorical
 row_order=top_bottom
 category_min=0
 category_max=15
 projection=lambert
 dx={dx}
 dy={dy}
 known_x=1.0
 known_y=1.0
 known_lat={startlat}
 known_lon={startlon}
 stdlon=3.0
 truelat1=44.0
 truelat2=49.0
 wordsize=1
 missing_value=2
 tile_x={ny}
 tile_y={nx}
 tile_z=1
 units="category"
 description="Dummy"
 """
 textfile = open('index', 'w')
 textfile.write(index_content)
 textfile.close()
 
 # write field
 filename = f"{1:05d}-{ny:05d}.{1:05d}-{nx:05d}"
 print(f"write field to {filename}")
 field.tofile(filename)

Using these static datasets together with their index files, the two lines crosses at the following longitude and latitude :

EPSG:4326 : Target LAT_M = 45.1788 LONG_M = 5.69937
EPSG:2154 : Target LAT_M = 45.1514 LONG_M = 5.7396

When the perfect value would have been : tgtlat = 45.180 | tgtlon = 5.700. Clearly, when using EPSG:4326 it works and when using EPSG:2154 there is a shift. This shift can be seen visually from the two figures below.

EPSG:4326

EPSG:2154

It may be -- read it is very likely -- that I am doing something obviously stupid when providing lambert data to WPS. In that case, I would be glad to know what because I have been trying to understand the origin of this shift for quite a while :)

But, as it occured to me with two distinct datasets (plus my toy-example) I raised that issue !

Thank you in advance for any help that one could provide !

All the best,

Enzo

Taking too long to run ./geogrid.exe GREENFRAC

Hi I'm running ./geogrid.exe and it gets stuck on Processing GREENFRAC for over an hour. It seems to run quickly for a domain in the mid latitudes but my domain is over Antarctica.

namelist.wps:

&share
wrf_core = 'ARW',
max_dom = 2,
start_date = '2020-11-30_00:00:00', '2020-11-30_00:00:00',
end_date = '2020-11-30_12:00:00', '2020-11-30_12:00:00',
interval_seconds = 21600,
io_form_geogrid = 2,
/

&geogrid
parent_id = 1,1,
parent_grid_ratio = 1,3,
i_parent_start = 1,96,
j_parent_start = 1,129,
e_we = 248,172,
e_sn = 205,172,
geog_data_res = 'default','default',
dx = 27000,
dy = 27000,
map_proj = 'polar',
ref_lat = -90,
ref_lon = -178.863,
truelat1 = -72.828,
truelat2 = -90,
stand_lon = -178.863,
geog_data_path = '/Users/tamarapletzer/wrf/downloads/WPS_GEOG',
ref_x = 124.0,
ref_y = 102.5,
/

&ungrib
out_format = 'WPS',
prefix = 'SST',
/

&metgrid
fg_name = 'FILE', 'SST',
io_form_metgrid = 2,
/

Any help is appreciated
Cheers

Ungrib not scaling negative starting latitudes

Typically, the starting latitude in a GRIB grid definition section is scaled by 1e6, and the ungrib code divides by this scaling factor. However, if the starting latitude is negative, no division by the scaling factor takes place in ungrib. For a discussion of this issue, see this forum post.

Vtable for GFS Para (FV3)

Hi, will a new Vtable be required for the updated GFS (FV3 version) due to go live in March?

Getting errors while compile

While compiling WPS I am getting errors, because jasper possible default path given in the confgure.wps as this

Settings for Linux x86_64, gfortran (dmpar)

COMPRESSION_LIBS = -L/glade/u/home/wrfhelp/UNGRIB_LIBRARIES/lib -ljasper -lpng -lz
COMPRESSION_INC = -I/glade/u/home/wrfhelp/UNGRIB_LIBRARIES/include

When I edit and give complete path to my jasper folder, its working fine. Why isn't taking $JASPERLIB and $JASPERINC given already?

metgrid does not detect inconsistent dimension size between geogrid and namelist.wps

A setup with two domains, but there is an inconsistency between the e_sn (namelist.wps) and south_north_stag (geogrid output) information, which metgrid.exe does not catch.

namelist.wps contains:

&geogrid
 parent_id         =   1,   1,
 parent_grid_ratio =   1,   5,
 i_parent_start    =   1,  25,
 j_parent_start    =   1,  30,
 e_we              =  100, 241,
 e_sn              =  80,  121,

...
/

geo_em.d02.nc contains:

netcdf geo_em.d02 {
dimensions:
	Time = UNLIMITED ; // (1 currently)
	DateStrLen = 19 ;
	west_east = 240 ;
	south_north = 160 ;
	south_north_stag = 161 ;
	west_east_stag = 241 ;
	land_cat = 21 ;
	soil_cat = 16 ;
	month = 12 ;

I can successfully run metgrid.exe afterwards:

/home/ec2-user/running/WPS>./metgrid.exe 
Processing domain 1 of 2
 Processing 2016-01-22_00
    GFS
 Processing 2016-01-22_06
    GFS
 Processing 2016-01-22_12
    GFS
 Processing 2016-01-22_18
    GFS
 Processing 2016-01-23_00
    GFS
Processing domain 2 of 2
 Processing 2016-01-22_00
    GFS
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!  Successful completion of metgrid.  !
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Add LOGSFP to METGRID.TBL.ARW

Running metgrid.exe with data containing the log surface pressure (e.g. ECMWF hybrid level data) results in the following warning:

WARNING: Entry in METGRID.TBL not found for field LOGSFP. Default options will be used for this field!

metgrid: print warning when no upper-level data found

I recently royally messed up a VTABLE, and accidentally removed all the lines for upper-level data. I was using ERA5 inputs, and had downloaded separate GRIB files for surface-level and upper-level data. I ran ungrib and metgrid, which gave no error messages, but the output met_em*.nc files were lacking the dimension num_metgrid_levels.

Perhaps metgrid should issue a warning when no upper-level output from ungrib is found - it might be worth the few lines of code it would likely take to save some confusion.

See https://forum.mmm.ucar.edu/phpBB3/viewtopic.php?f=34&t=8944&e=1&view=unread#unread

Geogrid doesn't find geog tiles that contains certain grid points

When a WRF grid point maps to a half-integer value in the projection space of a geographical dataset, and when that point is a distance of 0.5 outside of the nominal coverage of the tile, geogrid may incorrectly determine that the point lies within the tile, while interpolation schemes will think that the point lies outside of the valid coverage of the tile.

This issue can lead to points that are assigned missing values along the boundaries of source tiles.

The following namelist will reproduce the issue in the WPS v4.0 pre-release 1 code:

&share
 wrf_core = 'ARW',
 max_dom = 5,
 active_grid = f, f, f, f, t
/

&geogrid
 parent_id         = 1,1,2,3,4,
 parent_grid_ratio = 1,3,3,3,11,
 i_parent_start    = 1,20,32,25,28,
 j_parent_start    = 1,28,45,35,41,
 e_we          = 70,100,100,151,1002,
 e_sn          = 70,100,100,151,1013,
 geog_data_res = '2m','2m','30s','30s','30s',
 dx = 27000, 
 dy = 27000,
 map_proj =  'polar',
 ref_lat   = 66.5,
 ref_lon   = 20,
 truelat1  = 70,
 stand_lon = 20,
 geog_data_path = '/glade/u/home/wrfhelp/WPS_GEOG/',
/

Specifically, in the geo_em.d05.nc file, look for bad values at, e.g., (ix,jy)=(349,615).

calc_ecmwf_p.exe only works if all fields are in the same intermediate file

When ECMWF model-level data are split among multiple intermediate files (e.g, SFC and 3D files), 3-d RH and GHT fields are not produced in the output PRES files, and calc_ecmwf_p.exe stops with the message:

WARNING: Either TT or SPECHUMD not found. No RH will be computed.

A temporary work-around involves concatenating all intermediate files into one for each time period.

POWER/Linux configuration needs -qufmt=be

For compatibility with other systems, the binary files (principally, the intermediate files) created by the WPS program should be written in big-endian byte order. Accordingly, the -qufmt=be option should be added to the FFLAGS variable in the POWER/Linux stanza.

geogrid generated landmask does not see lakes with modis_15s_lake

There seems to be a "21" missing in GEOGRID.TBL in the landmask definition for modis_15s_lake

        landmask_water = modis_15s_lake:17         # Calculate a landmask from this field
        landmask_water =      modis_30s:17         # Calculate a landmask from this field
        landmask_water = modis_30s_lake:17,21      # Calculate a landmask from this field

This causes the LANDMASK computed by geogrid to not to see the lakes. I am not sure about the consequences, I think that real.exe fixes this afterwards recomputing the landmask, but at least this screws up my domain plotting script which uses geo_em files.

Ungrib v3.9 fails to build with certain gfortran versions

With some versions of the gfortran compiler, users have reported build failures of WPS v3.9:

gfortran -c -ffree-form -O -fconvert=big-endian -frecord-marker=4 read_namelist.f90
read_namelist.f90:72.25:

       add_lvls, new_plvl, interp_type
                         1
Error: NAMELIST attribute conflicts with ALLOCATABLE attribute in 'new_plvl' at (1)
read_namelist.f90:238.20:

  read(10,NML=ungrib,END=100)
                    1
Error: Symbol 'ungrib' at (1) must be a NAMELIST group name
make[1]: [read_namelist.o] Error 1 (ignored)

metgrid.exe makes file system unwritable

I am trying to run metgrid.exe on ERA5 pl files. ungrib runs without issues and metgrid runs ok for some time. After some time metgrid.exe crashes. The last lines of metgrid.log follow:

INFORM: Going to create the field SOILT
INFORM: Couldn't find SOILT000 at level 200100.000000 to fill level 0.000000 of SOILT.
INFORM: Couldn't find SOILT005 at level 200100.000000 to fill level 5.000000 of SOILT.
INFORM: Couldn't find SOILT020 at level 200100.000000 to fill level 20.000000 of SOILT.
INFORM: Couldn't find SOILT040 at level 200100.000000 to fill level 40.000000 of SOILT.
INFORM: Couldn't find SOILT160 at level 200100.000000 to fill level 160.000000 of SOILT.
INFORM: Couldn't find SOILT300 at level 200100.000000 to fill level 300.000000 of SOILT.
INFORM: Couldn't find SOILT050 at level 200100.000000 to fill level 49.000000 of SOILT.
INFORM: Couldn't find SOILT050 at level 200100.000000 to fill level 51.000000 of SOILT.
INFORM: Couldn't find SOILT001 at level 200100.000000 to fill level 1.000000 of SOILT.
INFORM: Couldn't find SOILT004 at level 200100.000000 to fill level 4.000000 of SOILT.
INFORM: Couldn't find SOILT010 at level 200100.000000 to fill level 10.000000 of SOILT.
INFORM: Couldn't find SOILT030 at level 200100.000000 to fill level 30.000000 of SOILT.
INFORM: Couldn't find SOILT060 at level 200100.000000 to fill level 60.000000 of SOILT.
INFORM: Couldn't find SOILT100 at level 200100.000000 to fill level 100.000000 of SOILT.
INFORM: Going to create the field SOIL_LEVELS
INFORM: Going to create the field PRES
INFORM: PRES at level 200100.000000 already exists; leaving it alone.
INFORM: Field LANDSEA.mask does not have a valid mask and will not be checked for missing values
WRF_DEBUG: NetCDF error: Read-only file system
WRF_DEBUG: NetCDF error in ext_ncd_open_for_write_begin wrf_io.F90, line 1373
ERROR: Error in ext_pkg_open_for_write_begin.
Note: The following floating-point exceptions are signalling: IEEE_OVERFLOW_FLAG

This causes my file system to go to read only and I have to restart to be able to use the computer again. It could be a problem with the input grib files but metgrid should not put the file system to read only mode.

I've got WPS 4.2 compiled with gfortran, serial running on Ubuntu server 18.04. I had the same problem with WPS 2.0.3

Parser message for `index` files with unrecognized options is misleading

The parser for the index file for geogrid datasets reports unrecognized options according to the position of the = character in the line, rather than the line number (which would be much more helpful). For example, the index file

type = continuous
signed = yes
projection = regular_ll
dx = 0.00027777778
dy = 0.00027777778
known_x = 1.0
known_y = 1.0
known_lat = 31
known_lon = 100
wordsize =2
endian = little
tile_x = 3601
tile_y = 3601
tile_z = 1
row_order=top_bottom
missing_value = 32768
units = "meters MSL"
description = "ASTER 1-sec Topography Height"
foobar=6

gives the error message

WARNING: In /home/wrf/geog/topo_ASTER/index, unrecognized option  in entry 7.

Geogrid logic to prevent combining different land use types assumes USGS default

The changes introduced in PR #15 assume that the default land use classification is USGS, which is not true for WPS versions 3.8 and newer, where the default has switched to MODIFIED_IGBP_MODIS_NOAH.

To observe the impact of this error, add the following entry to the GEOGRID.TBL file:

===============================
name=LANDUSEF
        optional=yes
        priority=2
        dest_type=categorical
        landmask_water =    usgs_30s:16             # Calculate a landmask from this field
        interp_option =    usgs_30s:nearest_neighbor
        rel_path =    usgs_30s:landuse_30s/
===============================

then set geog_data_res = 'usgs_30s+default', and note that no error is generated.

Detect whether MPI compiler wrapper supports -f90 option

WRF already has this check in its configure script: https://github.com/wrf-model/WRF/blob/9527846b8782cf1a137913daeb6ed267e8b2f5ca/configure#L699-L713

WPS compilation currently fails if the wrapper does not support -f90 as its configure script does not have a corresponding check.

Note that newer wrappers have changed from -f90 to -fc, which may be a more appropriate option than just leaving it out completely as WRF does currently. But note that I'm not sure if there are wrappers which have neither -f90 nor -fc, which may have been the motivation for the current logic in WRF's configure script.

geogrid.exe fails due to geog directory named "_con"

Hi all,

I raised a bug with the WRF-CMake gang, and they gave me a work-around for it, but suggested I'd log it here to, to make you guys aware of a Windows issue: WRF-CMake/wrf#43

Describe the bug

geogrid.exe is looking for orography data in DATA\geog/orogwd_1deg/con/index. However, windows does not allow any directory to be named "con". When geog data are unpacked, this directory gets named "_con", and cannot be renamed to "con". Hence, geogrid.exe fails.

To Reproduce

Steps to reproduce the behavior:

Run geogrid.exe following standard test case on https://gis4wrf.github.io/tutorials/wrf-cmake/simulate-the-2018-european-heat-wave-with-wrf-cmake/#download-geographical-data

Expected behavior

Code is actually behaving as expected. The problem is the path geogrid.exe uses to search for orography data, and the inability of Windows to name a directory "con".

System information (please complete the following information):

Windows 10 pro
Using downloaded binary wps-cmake-4.1.0-basic_nesting-serial-x64-windows-release.zip

Additional context

The code runs, so it's not really a bug, but geogrid.exe won't work without the orog data, so it's not really a feature request either...

Landmask offset in V4.0 compared to V3.8

Any help on the following topic would be greatly appreciated.

Running two "identical" model (differ with some defaults), one using v3.8 and one using v4.0.

Issue I am running into is that the default land mask in v4.0 appears offset compared to the identical model from v3.8. As far as i can tell both are using using the default geog resolution of 30s however the new v4.0 uses an improved 20-class MODIS product.

The following scatter plot shows the center points of each grid cell for Mauritius for v3.8. Land grid cells are white/not visible and water grid cells are blue.

The next shows the same but using v4.0...

and finally a zoomed in version of the islands to the north...

ERROR: Didn't recognize format version of data in FILE:2021-03-22_00.\nFound version 83886080 but expected either 3, 4, or 5. This could be an endian problem.

hello, Can somebody help me? How can I fix this error by running metgrid.exe. I am using WPSv4 and WRFv4.2.2, Intel, foltran90, Big edianHow can I fix this error by running metgrid.exe. I am using WPSv4 and WRFv4.2.2.

Settings for Linux x86_64, Intel compiler (dmpar)

COMPRESSION_LIBS = -L/gpfs/GLOBAL_JOB_REPO_KPFU/gurianov/intel/grib2/lib -ljasper -lpng -lz
COMPRESSION_INC = -I/gpfs/GLOBAL_JOB_REPO_KPFU/gurianov/intel/grib2/include
FDEFS = -DUSE_JPEG2000 -DUSE_PNG
SFC = ifort
SCC = icc
DM_FC = mpif90 -f90=ifort
DM_CC = mpicc -cc=icc
FC = $(DM_FC)
CC = $(DM_CC)
LD = $(FC)
FFLAGS = -FR -convert big_endian
#FFLAGS = -ffree-form -O -fconvert=big-endian -frecord-marker=4
F77FLAGS = -FI -convert big_endian
#F77FLAGS = -ffixed-form -O -fconvert=big-endian -frecord-marker=4
FCSUFFIX =
FNGFLAGS = $(FFLAGS)
LDFLAGS =
CFLAGS = -w
CPP = /lib/cpp -P -traditional
CPPFLAGS = -D_UNDERSCORE -DBYTESWAP -DLINUX -DIO_NETCDF -DIO_BINARY -DIO_GRIB1 -DBIT32 -D_MPI
ARFLAGS =
CC_TOOLS =

Data GFS

configure.wps
FFLAGS = -FR -convert big_endian
F77FLAGS = -FI -convert big_endian

configure.wps.log
geogrid.log
metgrid.log
ungrib.log

Wrong NLATS in processing NCAR RDA's ECMWF "ds113.1" dataset grib

I have processed grib files from RDA's ECMWF "ds113.1" dataset by using ungrib and metgrid.
But I found the wrong information with intermediate files.
FIELD = GHT
UNITS = m DESCRIPTION = Height
DATE = 2019-10-05_00:00:00 FCST = 0.000000
SOURCE = ECMWF
LEVEL = 10000.000000
I,J DIMS = 1849, 783
IPROJ = 4 PROJECTION = GAUSSIAN
REF_X, REF_Y = 1.000000, 1.000000
REF_LAT, REF_LON = 60.000004, 80.016006
NLATS, DLON = 1280.000000, 0.070000
EARTH_RADIUS = 6367.470215
DATA(1,1)=16054.108398

NLATS is 1280, not -0.07.
So the metgrid shows the error.
Oops, something is not right with the Gaussian latitude computation.
The input data gave the starting latitude as 60.000.
This routine computed the starting latitude as +- 89.946.
The difference is larger than 0.01 degrees, which is not expected.
ERROR: Gaussian_latitude_computation

Is there any soultion?

Clean up print statements for geogrid optional fields

The changes introduced in PR #16 enable users to not select optional fields, even if those fields are available on disk. The print statements generated by these changes could be made a little cleaner: for example, the output if LAI12M is made optional and not selected looks like:

  Optional fields not processed by geogrid:
    LAI12M (priority=1, resolution='', path='')
    IMPERV (priority=1, resolution='default', path='/sysdisk1/duda/WRF/geog/nlcd2011_imp_ll_9s/')
    CANFRA (priority=1, resolution='default', path='/sysdisk1/duda/WRF/geog/nlcd2011_can_ll_9s/')

Let's get familiar with the data by running g2print on one of the data files

When I run ./util/g2print.exe ../DATA/matthew/fnl_20161006_00_00.grib2 , the programm appear the error that *** Error in `./util/g2print.exe': corrupted size vs. prev_size: 0x000000000252ef90 ***. Has anyone ever encountered this problem before? and how did you solve it? think you

add `nocolons` option to `namelist.wps.all_options`

It would be nice if nocolons would be added to the namelist.wps.all_options file, in order to improve discoverability by the user.

If welcome, I'm happy to submit a PR.

metgrid release-v4.0.2 IF test, should have 4.0.1, not 4.0.2 twice

Likely this transcription error is in master and develop also.

WPS/metgrid/src/input_module.F

Line 432 in fd38c29

else if (index(title,'GEOGRID V4.0.2') /= 0) then

Outside integer(kind=8) range?

In WPS, I am looking at the file ungrib/src/ngl/g2/intmath.f.

Here is the entire function (with line numbers to make identification easy):

     80       function ilog2_8(i_in)
     81       implicit none
     82       integer(kind=8), value :: i_in
     83       integer(kind=8)::ilog2_8,i
     84       ilog2_8=0
     85       i=i_in
     86       if(i<=0) return
     87       if(iand(i,i-1)/=0) then
     88          !write(0,*) 'iand i-1'
     89          ilog2_8=1
     90       endif
     91       if(iand(i,Z'FFFFFFFF00000000')/=0) then
     92          ilog2_8=ilog2_8+32
     93          i=ishft(i,-32)
     94          !write(0,*) 'iand ffffffff',i,ilog2_8
     95       endif
     96       if(iand(i,Z'00000000FFFF0000')/=0) then
     97          ilog2_8=ilog2_8+16
     98          i=ishft(i,-16)
     99          !write(0,*) 'iand ffff' ,i,ilog2_8
    100       endif
    101       if(iand(i,Z'000000000000FF00')/=0) then
    102          ilog2_8=ilog2_8+8
    103          i=ishft(i,-8)
    104          !write(0,*) 'iand ff',i,ilog2_8
    105       endif
    106       if(iand(i,Z'00000000000000F0')/=0) then
    107          ilog2_8=ilog2_8+4
    108          i=ishft(i,-4)
    109          !write(0,*) 'iand f',i,ilog2_8
    110       endif
    111       if(iand(i,Z'000000000000000C')/=0) then
    112          ilog2_8=ilog2_8+2
    113          i=ishft(i,-2)
    114          !write(0,*) 'iand c',i,ilog2_8
    115       endif
    116       if(iand(i,Z'0000000000000002')/=0) then
    117          ilog2_8=ilog2_8+1
    118          i=ishft(i,-1)
    119          !write(0,*) 'iand 2',i,ilog2_8
    120       endif
    121       end function ilog2_8

I am getting a compile-time error that says that the value on line 91 is larger than an integer(kind=8).

From this page, https://gcc.gnu.org/onlinedocs/gcc-4.7.4/gfortran/BOZ-literal-constants.html, there is a line:

Note that initializing an INTEGER variable with a statement such as DATA i/Z'FFFFFFFF'/ will give an integer overflow error rather than the desired result of -1 when i is a 32-bit integer on a system that supports 64-bit integers.

From this page, the largest integer(kind=8) is 9.2(10)^18: http://www.cs.uwm.edu/classes/cs151/Bacon/Lecture/HTML/ch06s09.html

The value of FFFF FFFF FFFF FFFF is twice as large, 1.8(10)^19.

error "foreach: Too many arguments." when too many files to be linked

I met foreach: Too many arguments. while trying to link a whole year of fnl data using link_grib.csh. It seems that there are too many files (according to https://www.experts-exchange.com/questions/10210401/foreach-limit.html).

I simply rewrite the link_grib.csh with python, which has exactly the same usage as link_grib.csh.

#! /usr/bin/python
import sys,glob,os
def link_grib_file(filelist):
    n = 0
    for ifile in filelist:
        if ( ifile != "."):
            file_suffix = file_alphabet(n)
            os.symlink(ifile, "GRIBFILE."+file_suffix)
            n+=1
def file_alphabet(number):
    alpha=['A','B','C','D','E','F','G','H','I','J','K','L','M','N','O','P','Q','R','S','T','U','V','W','X','Y','Z']
    if number >= 26*26*26:
        print("RAN OUT OF GRIB FILE SUFFIXES!")
        exit()
    else:
        i1=number%26
        i2=(number-i1)//26%26
        i3=(number-i2*26-i1)//26//26%26
        return alpha[i3]+alpha[i2]+alpha[i1]
if __name__ == "__main__":
    varlist = sys.argv[1:]
    if (len(varlist)==1) or (len(varlist)==2 and varlist[1]=='.'):
        os.system("rm -f GRIBFILE.???")
        filelist=glob.glob(varlist[0])
        link_grib_file(filelist)
    elif (len(varlist)>1):
        os.system("rm -f GRIBFILE.???")
        filelist=varlist
        link_grib_file(filelist)
    elif (len(varlist)==0):
        print(" " ) 
        print(" " ) 
        print("   Please provide some GRIB data to link") 
        print("   usage: ./link_grib.py path_to_grib_data/grib_data_root") 
        print(" " ) 
        print(" " )

I'm wondering if it is helpful.
PS. It seems that the python code is about ten times faster than csh (maybe due to using os.symlink instead of ln -sf)

Current GFS Vtable does not work with pre-20150114 data

Apparently, older GFS datasets do not contain an MSLET field, only a smoothed PRMSL field. The current Vtable.GFS will therefore fail to identify the PRMSL field as the source of the PMSL field in these datasets. This issue was identified in this forum post: https://forum.mmm.ucar.edu/phpBB3/viewtopic.php?p=15793&sid=b53c4e3ea0dbcd94b51056de32f3d2d6#p15793 .

Compilation warnings about truncated string initialization

With the gfortran compiler, there are quite a few warnings about trunctated string
initialization that are generated during compilation of the g1print.exe utility:

gfortran -c -ffree-form -O -fconvert=big-endian -frecord-marker=4 g1print.f90
g1print.f90:664:71:

        'VSTR','M FLX','LMH','LMV','SGLYR','NLAT','ELON','UMAS','VMAS','XPRATE',&
                                                                       1
Warning: Initialization string starting at (1) was truncated to fit the variable (5/6)

HGT_M=0

We are running real simulations over Wyoming, nesting down to 100 m. At 300 m, we found an issue where the LU index is set to 17, which I presume is ocean, and the terrain height is set to 0. I attached a screenshot showing the output of geogrid.exe for a domain with a grid spacing of 300 m. You will see that the min HGT_M value is 0 (this domain is almost entirely over WY, so the minimum height should be greater than 1000 m. And, you can also see that it occurs at individual grid points (you may have to look closely to see it but it is there in the bottom right). This occurs at every 100th grid point in the y-direction (forming a line of individual points at sea level).

We have exhausted options to remove this other than to write a simple post-processing script to find these locations and replace them with adjacent values.

I should note that this occurs regardless of the averaging or smoothing scheme selected. Here, I show you the results for no smoothing and nearest neighbor because it makes it easy to see. I suspect that this is happening at the coarser resolutions but the smoothing and averaging cause the points to be undetectable.

Issue with rotated lat-lon coordinates

In geogrid the transformations between geographic and computational coordinates for lat-lon projections appear to apply the rotation by stand_lon twice. This occurs in the subroutines set_cassini, llij_casini and ijll_cassini. When unravelled, the subroutine rotate_coords(ilat,ilon,olat,olon,lat_np,lon_np,lon_0,direction), for direction -1 (geographic to computational coordinates), successively applies the following transformations:

A rotation about the z-axis by lon_np,
A rotation about the new (rotated) y-axis by 90 - lat_np
A rotation about the new (rotated) z-axis by lon_0

When direction == 1 the reverse transformation is applied.
When applied in llij_cassini for example,

call rotate_coords(lat,lon,comp_lat,comp_lon,proj%lat0,proj%lon0,proj%stdlon,-1)
comp_lon = comp_lon + proj%stdlon

the second line of code, after rotate_coords is called, has the effect of rotating again by stand_lon. A similar thing occurs in subroutine set_cassini, and the reverse occurs in ijll_cassini.
I am not sure that this is a serious issue. When pole_lat, pole_lon and stand_lon are set according to recommendation in Section 3 of the Users Guide, the centre of the computational domain is over the equator, which is important, but is rotated E-W and does not lie over the 180 deg meridian. I think that fixing this issue might break many peoples namelists and post-processing code. I am not sure if this spurious rotation has any other implications, so I am bringing it to your attention.

Error compiling with gfortran 10

Same issue as in wrf-model/WRF#1250.

2021-01-15T07:41:27.2436484Z gfortran  -ffree-form -O -fconvert=big-endian -frecord-marker=4 -c output_module.f90 -I/home/vsts/work/1/s/../WRF/external/io_netcdf -I/home/vsts/work/1/s/../WRF/external/io_grib_share -I/home/vsts/work/1/s/../WRF/external/io_grib1 -I/home/vsts/work/1/s/../WRF/external/io_int -I/home/vsts/work/1/s/../WRF/inc -I/home/vsts/work/1/s/netcdf/include
2021-01-15T07:41:27.2954031Z output_module.f90:1735:41:
2021-01-15T07:41:27.2955024Z 
2021-01-15T07:41:27.2955711Z  1735 |                                          var_value, &
2021-01-15T07:41:27.2956555Z       |                                         1
2021-01-15T07:41:27.2957208Z ......
2021-01-15T07:41:27.2957861Z  1763 |                                          var_value, &
2021-01-15T07:41:27.2958671Z       |                                         2
2021-01-15T07:41:27.2960372Z Error: Rank mismatch between actual argument at (1) and actual argument at (2) (rank-1 and scalar)

Builds with GNU 11 compilers fail with argument type mismatch errors

When using the GNU 11 compilers, various errors in actual argument types prevent all three of the main WPS components (geogrid, ungrib, and metgrid) from compiling. For example:

gfortran  -ffree-form -O -fconvert=big-endian -frecord-marker=4 -c output_module.f90 -I/glade/scratch/duda/wrf_support/WPS/../WRF/external/io_netcdf -I/glade/scratch/duda/wrf_support/WPS/../WRF/external/io_grib_share -I/glade/scratch/duda/wrf_support/WPS/../WRF/external/io_grib1 -I/glade/scratch/duda/wrf_support/WPS/../WRF/external/io_int -I/glade/scratch/duda/wrf_support/WPS/../WRF/inc -I/glade/u/apps/ch/opt/netcdf/4.8.0/gnu/11.1.0//include
output_module.f90:1735:41:

 1735 |                                          var_value, &
      |                                         1
......
 1763 |                                          var_value, &
      |                                         2
Error: Rank mismatch between actual argument at (1) and actual argument at (2) (rank-1 and scalar)
output_module.f90:1680:41:

 1680 |                                          var_value, &
      |                                         1
......
 1708 |                                          var_value, &
      |                                         2
Error: Rank mismatch between actual argument at (1) and actual argument at (2) (rank-1 and scalar)

WPS geographical input data license

What is the license for the WPS geographical input data? I could find no information on the website or in the archives.