WRFV300 update: two items

(1) In WRFV300 on the Mac, using the Intel Fortran 10.1 compiler, the compiler flag –switch fe_use_rtl_copy_arg_inout causes problems that weren't apparent with earlier WRF versions. Specifically, lateral boundary tendencies for water vapor are zeroed, resulting in problems in this field that grow inward from the boundaries. In the wrfbdy_d01 file, fields like QVAPOR_BXE and related entries possess only zeroes. This file is, of course, created by real.exe.

I added this switch owing to this page. Removing it does no harm. I tried several minor versions of ifort 10.1, explored 32 and 64 bit, etc.; nothing helped fix this issue except removing this switch.

(2) In WRFV300, the Lin microphysics scheme (mp_physics = 2) has issues -- noise issues. After only a few tens of minutes, the pressure field starts displaying small scale noise. Decreasing the time step, implementing 6th order smoothing, and upping the small time step smoothing (epssm) do not help. For the simulations I am examining, the noise does not appear with any other microphysics scheme. With Lin, the noise appears in higher but not in lower resolution simulations.

The Lin code was altered between WRFV221 and WRV300. I have not isolated the code changes that cause this problem.

Playing with WRF3 (WRFV300, WPSV300) - part I

WRF v.3.0.0 was released yesterday, and I decided to see if it would be any easier to get it to run well on my Intel-based Mac Pro, with the latest ifort 10 compiler. I also tested it on two Linux machines, one with the same chip type and ifort version, the other with older 32 bit hardware and software (ifort 9). I also built WRF with PGI Fortran on the older machine, for a total of four different combinations of hardware and software (one Mac, three Linux; three ifort, one PGI).

The good news is the configuration system is a lot more slick. The bad news for the Mac Pro is the executables would not build with the stock configure.wrf obtained for ifort and OMP. A few alterations were necessary on my Mac:

(1) I'm using 64 bit compilers, so I needed to add "-m64" to CFLAGS_LOCAL.

(2) To get rid of missing symbols (that didn't draw complaints on either Intel Linux build), I had to add "$(WRF_SRC_ROOT_DIR)/frame/module_domain_type.o $(WRF_SRC_ROOT_DIR)/external/io_grib2/grib2tbls_types.o" to LDFLAGS_LOCAL.

Then, the weirdness started. On the two Core Quad machines (Mac and Linux), the OMP ifort build doesn't spawn more than one thread or capture more than 100% according to top and Activity Monitor, despite the setting for OMP_NUM_THREADS. It seems OMP is broken, and it's not platform-specific.

WRF3 is not backward compatible with respect to input files, and this makes upgrading WPS a must. But the new version of WPS' geogrid program isn't working anywhere. It spits out a segfault (at the same place) even when trying to build the example domain. Same experience with ifort and PGI, on the two Linux machines. I verified that the WPS_GEOG data have not changed, so it's not that.

No Mac WPS yet since I don't have, and have been unable as of yet to successfully build, NCL for 64 bit on the Mac. I tried to create parallel 64 and 32 bit versions of WRF and WPS (and all other necessary software) to circumvent this, but decided not to continue since the new WPS is not working yet on the Linux boxes.