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

real.exe under WRF 4.0

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.

P

PeterJamesRye

New member
I have just upgraded from WRF 3.8 to 4.0, have installed all the WRF and WPS binaries. The WPS process proceeds through to the "met_em*" files, but when I try to run real.exe, the process fails and I see the message:

----- ERROR: topo_wind = 1 AND flag_var_sso = 0
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE: <stdin> LINE: 324
Either modify the namelist settings, or rebuild the geogrid/metgrid data

I can't find any point where flag_var_sso is supposed to go. Can you help?
 
The problem seems to be a bug in metgrid.

In file process_domain_module.F are the lines -

call mprintf(.true.,LOGFILE, 'Read in static field %s.',s1=cname)
call list_insert(static_list, ckey=cname, cvalue=cname)

and I can see in metgrid.log the confirmation for cname equal to "VAR_SSO".

But further down the code, the lines where FLAG_VAR_SSO should be set up for output seem to be

static_list_array => list_get_keys(static_list)
call list_init(flag_list)
do i=1,size(static_list_array)
istatus = 0
ctemp = 'FLAG_'//trim(static_list_array(i)%ckey)
call ext_get_dom_ti_integer_scalar(ctemp, istatus, suppress_errors=.true.)
if (istatus == 1) call list_insert(flag_list, ckey=ctemp, cvalue=ctemp)
end do

While there are many "FLAG_*" items in metrgrid.log, FLAG_VAR_SSO isn't one of them.
 
Hi,

Thanks for bringing this to our attention. We will take a look at it, test it, and get back to you. We never encountered this during our testing, though.
Are you using all new WPS files - generated from WPSV4.0?
 
I ran a quick test using GFS input data and setting topo_wind = 1 in namelist.input. I do not get this error. When you ran geogrid, namelist.wps should point to a path for 'geog_data_path.' Do you have varsso data in the directory that hold your static data?
 
Sorry, I've been away for a few days.

In response to kwerner (Sat Aug 04, 2018 4:56 am), the input files were all generated using version 4.0 of the WPS programs. The VAR_SSO data is input and written correctly by geogrid.exe, as confirmed by using ncdump on its output.

Please note my comment about the apparent bug in real.exe (Thu Aug 02, 2018 11:39 am). In the first section of the code, VAR_SSO is present, in the second section it seems to have been lost. It might be relevant that VAR_SSO is the last in the list of keys.

I'll have a look to see if the bug in start_em.F has any relevance to the issue.
 
I have just checked real.exe with the suggested patch.

Unfortunately, it has no effect on the VAR_SSO problem.

But when I run the version 3.9 real.exe, all is OK. Clearly a 4.0 bug.
 
Thanks for testing the code modification. I'm trying to run some tests with this, but as I mentioned, I'm not able to repeat the error yet, UNLESS I do not have varsso static data available in my static files directory. I previously asked 2 questions.

1) Are you using met_em* files generated from WPSV4.0 when running real.exe for V4.0?
2) In your V4.0 namelist.wps file, there is a path declared for geog_data_path. When you go to the directory where that path points, is the field varsso included in that directory?

Thanks!
 
Presumed Bug Fix ...

Line 638 and 639 of process_domain_module.F are:

call ext_get_dom_ti_integer_scalar(ctemp, istatus, suppress_errors=.true.)
if (istatus == 1) call list_insert(flag_list, ckey=ctemp, cvalue=ctemp)

ext_get_dom_ti_integer_scalar calls a netcdf function, and the netcdf functions return 0 on success.

I checked, and the return value of istatus is 0 for all keys. I haven't drilled down that far yet, but on the expectation that 0 should be the success code, not 1, I changed "istatus == 1" to "istatus == 0". Now all runs OK.
 
P.S. ...

In response to kwerner - yes, all the points you mentioned have been covered. i wouldn't have been able to get as far as i have without them.

I mentioned earlier my use of version 3.9 files as an alternative earlier, and that the preparation of the input files using them worked (I also confirmed afterward that WRF 4.0 ran OK with those files, once force_use_old_data = T had been added to namelist.input). I also mentioned that ncdump showed the VAR_SSO data had been included correctly in the version 4.0 output files.
 
FLAG_VAR_SSO is specified in GEOGRID.TBL. When you run geogrid.exe and VAR_SSO is processed, this flag is set to 1. It is a mandatory variable for surface wind correction (topo_wind=1).
Please look at your path where the static datasets are located and make sure the varsso dataset is there.

Ming Chen
 
As a reiteration:

When line 639 of process_domain_module.F is in its original form:

if (istatus == 1) call list_insert(flag_list, ckey=ctemp, cvalue=ctemp)

FLAG_VAR_SSO is not written to the metgrid output file. But when it is of form

if (istatus == 0) call list_insert(flag_list, ckey=ctemp, cvalue=ctemp)

FLAG_VAR_SSO is written. Since the intent clearly is for FLAG_VAR_SSO to be set, the change from 1 to 0 is either a bug fix, or a successful workaround.
 
Many of us who offer help on this forum are developers of some part of the WRF modeling system, so if we ask for specific information, it’s usually for a good reason. In this case, the output of ‘ncdump -h geo_em.d01.nc’ does reveal some critical information: your geogrid output contains the VAR_SSO field, but the global attribute FLAG_VAR_SSO is absent. So, it would appear that the metgrid program is behaving correctly when it doesn’t find this flag.

In the v4.0 version of the GEOGRID.TBL.ARW file, the FLAG_VAR_SSO attribute should always be written when the VAR_SSO field is processed:
Code: 
===============================
name = VAR_SSO
        priority = 1
        optional=yes
        dest_type = continuous
        fill_missing=0.
        interp_option =   30s:average_gcell(4.0)+four_pt+average_4pt
        interp_option =   2m:average_gcell(4.0)+four_pt+average_4pt
        interp_option =   5m:average_gcell(4.0)+four_pt+average_4pt
        interp_option =   10m:average_gcell(4.0)+four_pt+average_4pt
        interp_option =    lowres:average_gcell(4.0)+four_pt+wt_average_4pt
        interp_option =   default:average_gcell(4.0)+four_pt+average_4pt
        rel_path =        30s:varsso/
        rel_path =        2m:varsso_2m/
        rel_path =        5m:varsso_5m/
        rel_path =        10m:varsso_10m/
        rel_path =        lowres:varsso_10m/
        rel_path =        default:varsso_10m/
        flag_in_output=FLAG_VAR_SSO
===============================
However, in v3.9 and earlier, no flag was output:
Code: 
===============================
name = VAR_SSO
        priority = 1
        dest_type = continuous
        fill_missing=0.
        interp_option =   30s:average_gcell(4.0)+four_pt+average_4pt
        interp_option =   2m:average_gcell(4.0)+four_pt+average_4pt
        interp_option =   5m:average_gcell(4.0)+four_pt+average_4pt
        interp_option =   10m:average_gcell(4.0)+four_pt+average_4pt
        interp_option =   default:average_gcell(4.0)+four_pt+average_4pt
        rel_path =        30s:varsso/
        rel_path =        2m:varsso_2m/
        rel_path =        5m:varsso_5m/
        rel_path =        10m:varsso_10m/
        rel_path =        default:varsso_10m/
===============================
It’s also curious that your geogrid output apparently doesn’t contain an LAI12M field, which is a mandatory field in the WPS v4.0. Are you by chance using something other than the standard GEOGRID.TBL with the WPS v4.0 code?
 
All the "TBL" files I used are those provided with the version 4.0 file set.

As you note, the absence of FLAG_VAR_SSO when VAR_SSO is present is not consistent with the intent of the program. The appearance of FLAG_VAR_SSO when the success code swaps between 0 and 1 suggests where the error might be.
 
I really suspect that the default v4.0 GEOGRID.TBL file is not being used. Your ncdump output reveals that you don't have the LAI12M, which is a mandatory field in v4.0. Also, your geogrid output contains the fields SLOPECAT, SLPX, SLPY, HGT_U, and HGT_V, which are not present in the v4.0 GEOGRID.TBL file. Can you attach your namelist.wps file? I'm wondering whether the opt_output_from_geogrid_path variable may be set to a non-default value.
 
You must log in or register to reply here.
Top