WRF4.5 with moving_nest and high-resolution land use and topography

[emmanuel_causse]

Hello,

I am running WRF4.5.2 and WPS4.5 with a version compiled for moving nests. It works very well with MODIS land use and topography but there is a lack of resolution when the moving nest comes towards land and I am therefore trying to use the hires option (after recompiling with the TERRAIN_AND_LANDUSE environment variable set to 1).

In the following small test I let the d02 domain move after modelling 40 minutes of weather. The modelling starts well, but crashes when the moving nest is supposed to start moving, with the following error:
FATAL CALLED FROM FILE: <stdin> LINE: 2419
Warning: too many input landuse types
-------------------------------------------
Abort(1) on node 12 (rank 12 in comm 0): application called MPI_Abort(MPI_COMM_WORLD, 1) - process 12

ncdump -h wrfinput_d01 | grep NUM_LAND returns NUM_LAND_CAT = 24, which I use in namelist.input…

I downloaded the high-res data from www2.mmm.ucar.edu/wrf/src/wrf_files/data4movingnest.html and followed the instructions in the WRF users’ guide.

In namelist.wps I used
geog_data_res = 'usgs_30s+default', 'usgs_30s+default',

In namelist.input I used
input_from_hires = .true., .true.,
input_from_file = .false., .false.,
time_to_move = 60000000, 40
num_land_cat = 24

I have uploaded a tar file callec emc_to_NCAR.tar with the namelist files, GEOGRID and METGRID tables, rsl.error files, etc.

Thanks in advance for any help I can receive with this issue.

Best regards
Emmanuel

 

[kwerner]

Hi Emmanuel,
Thanks for sending everything in the packaged file - that was great! The only thing I can't find is the full namelist.input file. I see namelist.output, but not *.input. Can you attach that here? Thanks!

 

[emmanuel_causse]

Oh, sorry... Here is the namelist.input file. I also join the outFields.txt file.

 

[emmanuel_causse]

By the way, in case where the high-res topo is not used (input_from_hires = .false., .false. in the namelist), is there a drawback of using the WRF version compiled with the TERRAIN_AND_LANDUSE environment variable set to 1 vs a "normal" WRF version?

 

[kwerner]

By the way, in case where the high-res topo is not used (input_from_hires = .false., .false. in the namelist), is there a drawback of using the WRF version compiled with the TERRAIN_AND_LANDUSE environment variable set to 1 vs a "normal" WRF version?

I don't believe there is an issue with that. Is that an option for you? i.e., are you okay with using that version, and is that working for you?

 

[emmanuel_causse]

I don't believe there is an issue with that. Is that an option for you? i.e., are you okay with using that version, and is that working for you?

 

[emmanuel_causse]

No, actually it is not an option. I need to use the hires topo and landuse.

 

[emmanuel_causse]

Hello again,

There was an error in the path to the SurfaceFiles folder in my previous setup, which I think explains the error.

But we still have not managed to successfully run with the hires option.

We have tried another setup, and use now debug flags in configure.wrf.

Without debug flags, we get segmentation faults from several of the rsl.error files, corresponding to the red tiles in the figure.

With debug flags "-g -O1 -traceback -check bounds,uninit -ftrapuv -fpe0" only rsl.error.0000 reports an error, this time a floating point exception. This comes from the input_terrain_rsmas subroutine. We also have the message "Access to RSMAS Topo Ingest Code is by Special Arrangement Only". So, the hires data seems not to be read properly.

We asked some colleagues to run from their own cluster with the same namelists. They were running successfully and did not have this message in their rsl.error files...

Can you figue what might cause this error?

Thanks for your patience...

 

[emmanuel_causse]

Hello again,

It runs fine now!

We found out that the landread.c file had been replaced by landread.c.dist, most probably because the compiler could not find the rpc/types.h file.

Using the original landread.c version and helping the compiler find the types.h file fixed the problem described above. That was done by introducing the following flags in the configure.wrf file before compiling:

a) adding " -lz -L/usr/include/tirpc -ltirpc" to LIB_EXTERNAL
b) adding " -I/usr/include/tirpc" to CFLAGS_LOCAL
c) adding " -I./inc/" and " -I/usr/include/tirpc -I/usr/include/tirpc/rpc" to CPPFLAGS

Best regards
Emmanuel

 

[kwerner]

Hi!
I'm so glad you found a work-around for this, and thank you for sharing the fix here so that others may use it in the future!