[Wrf-users] able to read grib(NCEP FNL), but...

[Foo, Alex (Space Technology)]

Hello, there. Thanks for your attention. I am able to read FNL grib
files now.
I used wrfsi/src/include/makefile_sgi64.inc.in. My platform is
SGI/IRIX64.

It did not work before because I intended to build code in 64bit,
therefore I changed "-DBIT32" to "-DBIT64" in that
makefile_sgi64.inc.in. I was wrong. Now, my question is why does that
makefile for 64bit-build uses an option "-DBIT32"?

Another question:
The Vtable.AVN(I used) has these lines:
  11 | 100  |   *  |      | T        | K       | Temperature
  33 | 100  |   *  |      | U        | m s-1   | U
  34 | 100  |   *  |      | V        | m s-1   | V
  52 | 100  |   *  |      | RH       | %       | Relative Humidity
   7 | 100  |   *  |      | HGT      | m       | Height
and
  11 | 105  |   2  |      | T        | K       | Temperature       at 2
m
  52 | 105  |   2  |      | RH       | %       | Relative Humidity at 2
m
  33 | 105  |  10  |      | U        | m s-1   | U                 at 10
m
  34 | 105  |  10  |      | V        | m s-1   | V                 at 10
m
   7 |   1  |   0  |      | HGT      | m       | Terrain Heights
Code src/grib_prep/util/parse_table.F removed these duplicates and
printed out the following message in the run time:
> Duplicate name.  Removing T         from output list.
> Duplicate name.  Removing U         from output list.
> Duplicate name.  Removing V         from output list.
> Duplicate name.  Removing RH        from output list.
> Duplicate name.  Removing HGT       from output list.

Those removed T, U, V, RH and HGT are variables near the surface.
If they are removed from the output of initialization, we must assume
the WRF model does not need these near-surface info to start
integration. Is this really true or it is a problem?

Alex