Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

Issues at 180 degree longitude

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.

philipdumont

New member
Dear UCAR,

Please consider the following problem, and advise if there is a known
fix and/or workaround.

WRF version (from rsl.*):
WRF V3.6.1 MODEL

MPI version (from "mpirun --version"):
Intel(R) MPI Library for Linux* OS, Version 5.1.3 Build 20160120 (build id: 14053)
Copyright (C) 2003-2016, Intel Corporation. All rights reserved.

We are running a job, with nested domain (2 levels) that spans the
international date line (longitude 180 degrees).

If we open any of the d02 output files from WRF_wrf.exe with a grib
viewer (we were using Panoply), and look at any of the XLONG
parameters (XLONG, XLONG_U, XLONG_V), we find an anomaly in 2 columns
of data near the center of the regions of interest. For example, for
the XLONG parameter, at X-axis coordinates 15 and 30, the values jump
all of a sudden to 86.8 and -86.3, respectively, though all the other
X-axis values are within a few degrees of +/-180.

We are unable to find any anomalies in any of the grib files that are
inputs to WRF_real.exe (met_em.*.mc), nor in any of the grib files
that are outputs of WRF_real.exe and inputs to WRF_wrf.exe
(wrfbdy_d01, wrfinput_d01). Nor are there any anomalies in the parent
domain WRF_wrf.exe output grib files (wrfout_d01*). Therefore, it
would appear that the problem is being introduced during WRF_wrf.exe's
computation of the nested domain.

The anomalies only show up when the area of interest is centered at
the 180 degree longitude. And they only ever shows up in the nested
domain, never the parent.

The problem does not seem to be related to the projection used --
we've seen it with both Lambert and Mercator.

I am including a gzip-compressed tar file of the inputs/outputs of an
example run. It has the following contents:

Code:
GENPARM.TBL                        RRTMG_LW_DATA
gribmap.txt                        RRTMG_SW_DATA
LANDUSE.TBL                        SOILPARM.TBL
met_em.d01.1980-12-31_18:00:00.nc  VEGPARM.TBL
met_em.d01.1980-12-31_21:00:00.nc  wrfbdy_d01
met_em.d02.1980-12-31_18:00:00.nc  wrfinput_d01
met_em.d02.1980-12-31_21:00:00.nc  wrfout_d01_1980-12-31_18:00:00
my_iofields_d01.txt                wrfout_d01_1980-12-31_21:00:00
my_iofields_d02.txt                wrfout_d02_1980-12-31_18:00:00
namelist.input                     wrfout_d02_1980-12-31_19:00:00
namelist.output                    wrfout_d02_1980-12-31_20:00:00
RRTM_DATA                          wrfout_d02_1980-12-31_21:00:00

The command lines used to run the job are as follows:


mpirun -n 2 WRF_real.exe
mpirun -n 16 WRF_wrf.exe

Thank you for your attention to this matter. A prompt reply would be
appreciated.
 

Attachments

  • idl_issue.tgz
    64.5 MB · Views: 49
This is a bug that has been fixed in WRFV3.9. Can you run WRF in newer version like V3.9 and later?
 
Top