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

(RESOLVED) Taking too long to run ./geogrid.exe GREENFRAC

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.

tpletzer

New member
Hi I'm running ./geogrid.exe and it gets stuck on Processing GREENFRAC for over an hour. It seems to run quickly for a domain in the mid latitudes but my domain is over Antarctica.

namelist.wps:

&share
wrf_core = 'ARW',
max_dom = 2,
start_date = '2020-11-30_00:00:00', '2020-11-30_00:00:00',
end_date = '2020-11-30_12:00:00', '2020-11-30_12:00:00',
interval_seconds = 21600,
io_form_geogrid = 2,
/

&geogrid
parent_id = 1,1,
parent_grid_ratio = 1,3,
i_parent_start = 1,96,
j_parent_start = 1,129,
e_we = 248,172,
e_sn = 205,172,
geog_data_res = 'default','default',
dx = 27000,
dy = 27000,
map_proj = 'polar',
ref_lat = -90,
ref_lon = -178.863,
truelat1 = -72.828,
truelat2 = -90,
stand_lon = -178.863,
geog_data_path = 'WPS_GEOG',
ref_x = 124.0,
ref_y = 102.5,
/

&ungrib
out_format = 'WPS',
prefix = 'SST',
/

&metgrid
fg_name = 'FILE', 'SST',
io_form_metgrid = 2,
/

Any help is appreciated
Cheers
 
Hi,
We have occasionally seen problems with GREENFRAC taking too long for particular simulations since we changed the default static data to MODIS FPAR GREENFRAC, beginning with V3.8. To get past this problem, you can modify the greenfrac that is used by adding "nesdis_greenfrac+" to your "geog_data_res" path. For e.g., if it's currently set to
Code:
geog_data_res = 'default','default',
then change it to
Code:
geog_data_res = 'nesdis_greenfrac+default','nesdis_greenfrac+default',

Let me know if that helps.
 
Hi,

Thank you for your reply. Where can I download the nesdis_greenfrac data from?

Is it available on this page? https://www2.mmm.ucar.edu/wrf/users/download/get_sources_wps_geog.html#mandatory
 
Hi,
Yes, it's available from the Optional Input Data section of that page. It's the one just called 'greenfrac.' However, it has recently been brought to my attention that an easier option to solve this issue is to simply use four_pt interpolation for the default option. To do this, find the section for GREENFRAC in the geogrid/GEOGRID.TBL and the final line in that section is
Code:
rel_path=default:greenfrac_fpar_modis/
Just change that to
Code:
rel_path=default:greenfrac_fpar_modis+four_pt/
Then save the GEOGRID.TBL and try running geogrid again to see if that helps.
 
Hi,
Thank you for your quick reply! I managed to get the greenfrac to process much faster using your advice about nesdis_greenfrac data, though for some reason the LAI12M takes much longer now (30 min on a cluster for a 60km x 60km domain with 200m resolution).

I also tried adding in four_pt to the GEOGRID.TBL file and got the following error:

Parsed 29 entries in GEOGRID.TBL
Processing domain 1 of 1
ERROR: Could not open /WPS/WPS_GEOG/greenfrac_fpar_modis+four_pt/index
application called MPI_Abort(MPI_COMM_WORLD, 33242704) - process 0
In: PMI_Abort(33242704, application called MPI_Abort(MPI_COMM_WORLD, 33242704) - process 0)
Killed

Am I missing some files in WPS_GEOG for the four_pt interpolation? My WPS_GEOG contains:
albedo_modis orogwd_10m soiltype_top_30s
greenfrac_fpar_modis orogwd_1deg topo_gmted2010_30s
lai_modis_10m orogwd_20m varsso
lai_modis_30s orogwd_2deg varsso_10m
landuse_30s orogwd_30m varsso_2m
maxsnowalb_modis soiltemp_1deg varsso_5m
modis_landuse_20class_30s_with_lakes soiltype_bot_30s greenfrac
 
tpletzer said:
I also tried adding in four_pt to the GEOGRID.TBL file and got the following error:

Parsed 29 entries in GEOGRID.TBL
Processing domain 1 of 1
ERROR: Could not open /WPS/WPS_GEOG/greenfrac_fpar_modis+four_pt/index
application called MPI_Abort(MPI_COMM_WORLD, 33242704) - process 0
In: PMI_Abort(33242704, application called MPI_Abort(MPI_COMM_WORLD, 33242704) - process 0)
Killed
The suggestion to add "four_pt" to the "rel_path" specification in the GREENFRAC entry of the GEOGRID.TBL file isn't correct. I think what's needed is to modify the interp_option specification for the "default" resolution. The "search" interpolation option that is at the end of the list of interpolation options is employed when none of the source data pixels surrounding a WRF land grid cell is valid (i.e., not missing): in this case, the geogrid program employs a breadth-first search through the source dataset, beginning at the pixel nearest to the WRF model grid cell and searching outward for a valid pixel value. This search can take quite some time when the WRF land-sea mask isn't in agreement with the implicit land-sea mask, e.g., in the vegetation fraction dataset.

It may help, then, to try changing the default specification of interp_option
Code:
interp_option=default:average_gcell(4.0)+four_pt+average_4pt+average_16pt+search
so that the "+search" option is no longer present:
Code:
interp_option=default:average_gcell(4.0)+four_pt+average_4pt+average_16pt

Note, however, that this will likely lead to WRF land points that have a zero value for vegetation fraction (the zero value is specified by the fill_missing keyword in the GREENFRAC entry). My suspicion is that this is most likely to happen for WRF grid cells that are permanent snow/ice (e.g, most of Greenland and Antarctica), in which case a zero value for vegetation fraction isn't likely to cause much harm.
 
Top