Which MPAS settings could make precipitation and snow depth too strongly terrain-controlled?

X1a0wu

New member
Dear MPAS developers,

I am using MPAS-A with a 60–3 km variable-resolution mesh to simulate the January 2024 winter snowstorm. I ran two experiments with the same dynamics and large-scale forcing: one with Thompson and one with WSM6 microphysics. Both are using the convection_permitting physics suite.

On the native MPAS grid, both experiments show a strong positive relationship between terrain height and simulated precipitation/snow depth. For the 36-h evaluation window:

- 36-h precipitation vs terrain height:
- Thompson: area-weighted Pearson r ≈ 0.42
- WSM6: area-weighted Pearson r ≈ 0.35

- End-of-period snow depth vs terrain height:
- Thompson: area-weighted Pearson r ≈ 0.81
- WSM6: area-weighted Pearson r ≈ 0.74

Area-mean precipitation increases from about 7 mm below 200 m to about 14–15 mm above 800 m. Snow depth increases from near 0 cm in low-elevation areas to about 10 cm above 800 m. The two microphysics schemes therefore have similar terrain-dependent behavior.

The observational issue is that most stations are located at low elevations, so the observational sampling is imperfect. However, this event produced widespread heavy snowfall over low-elevation areas, and many low-elevation stations observed substantial precipitation and snow accumulation. The simulated result appears much more terrain-controlled than the observed event.

I am not assuming the terrain correlation is necessarily wrong, since orographic precipitation and colder mountain temperatures can physically enhance snowfall. My concern is whether some MPAS configuration settings may be amplifying this terrain dependence or creating an unrealistic separation between lowland and mountain precipitation/snowfall.

For the static fields, I used the standard WRF/WPS GEOG static datasets, which are commonly used for WRF preprocessing. The terrain is not from a custom DEM. In the MPAS initialization namelist, I set:

- config_geog_data_path = path to the standard WRF GEOG dataset
- config_topo_data = GMTED2010
- config_supersample_factor = 3

Other relevant static/initialization settings include:

- config_nsmterrain = 1
- config_smooth_surfaces = true
- config_blend_bdy_terrain = false
- config_native_gwd_static = false
- 55 vertical levels
- config_ztop = 30 km
- config_dzmin = 0.3
- config_nsm = 30
- config_tc_vertical_grid = true

My main question is: are there known MPAS settings related to terrain generation, terrain smoothing, static fields, vertical coordinate design, gravity-wave-drag static fields, or the convection-permitting physics suite that could cause precipitation and snowfall to become too strongly correlated with terrain height?

In particular, I would appreciate advice on:

1. Whether the standard WRF/WPS GEOG topography, especially the GMTED2010 terrain source, is appropriate for generating MPAS native-grid terrain at 60–3 km, or whether another terrain dataset/static-field option is usually recommended.
2. Which `init_atmosphere` or static-field settings I should test first if I suspect excessive terrain control.
3. Whether `config_nsmterrain`, `config_smooth_surfaces`, `config_blend_bdy_terrain`, or `config_native_gwd_static` can noticeably affect surface precipitation/snowfall patterns.
4. Whether the 60–3 km mesh is generally sufficient for this type of southern-China winter terrain/precipitation interaction, or whether this behavior may indicate that the effective terrain forcing is still too coarse or too steep.
5. Which MPAS diagnostics would help determine whether the terrain-related precipitation/snow signal is physically reasonable or configuration-related.
6. Are there recommended sensitivity tests for separating realistic orographic enhancement from artificial terrain over-amplification?

Thank you very much for your help.
 
This is more like a model performance issue. Please clarify whether this is a regional MPAS run or a global run. What is the data you used to force this case?

To answer your questions,
(1) the standard WRF/WPS GEOG topography (i.e. the GMTED2010 terrain) is appropriate for generating MPAS native-grid terrain at 60–3 km
(2) orographic forcing plays a key role in this case, and thus I would check topography impact first.
(3) default value of config_nsmterrain is 1. Please try to increase its value to 2, which adds more smoothing and reduces small variation feature.
config_smooth_surfaces should be true, and config_blend_bdy_terrain only applies for regional run.
(4) 60-3km mesh is a good option for winter storm study over complex terrain area including south china.
(5) Comparison of model results with observations is an effective way to make sure the model results are physically reasonable or not. I am not sure of other methods. Please refer to the literature.
 
To clarify your questions: this is a global MPAS run (not a regional/limited-area run), and it is driven by GFS forecast data.
This is more like a model performance issue. Please clarify whether this is a regional MPAS run or a global run. What is the data you used to force this case?

To answer your questions,
(1) the standard WRF/WPS GEOG topography (i.e. the GMTED2010 terrain) is appropriate for generating MPAS native-grid terrain at 60–3 km
(2) orographic forcing plays a key role in this case, and thus I would check topography impact first.
(3) default value of config_nsmterrain is 1. Please try to increase its value to 2, which adds more smoothing and reduces small variation feature.
config_smooth_surfaces should be true, and config_blend_bdy_terrain only applies for regional run.
(4) 60-3km mesh is a good option for winter storm study over complex terrain area including south china.
(5) Comparison of model results with observations is an effective way to make sure the model results are physically reasonable or not. I am not sure of other methods. Please refer to the literature.
Thank you for your suggestions. Following your advice, we are now trying to regenerate the static file with more terrain smoothing (config_nsmterrain = 2) for our global 60-3 km run (mesh x20.835586).

However, we are running into a memory problem during the static-field generation step. My node memory is 512G, is that enough?It stopped when " Using option 'lapse-rate' for vertical extrapolation of temperature" AI recommend me to set "config_native_gwd_static = false", its that feasible?
=== Job started at: Fri Oct 16 00:03:15 CST 2026 ===
Running on node: b2106r7n8
=== Running init_atmosphere_model (36 tasks) ===
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
init_atmosphere_m 000000000067F094 for__signal_handl Unknown Unknown
libpthread-2.17.s 00002B1DAD52B5D0 Unknown Unknown Unknown
init_atmosphere_m 00000000004A6550 Unknown Unknown Unknown
init_atmosphere_m 000000000043ECF9 Unknown Unknown Unknown
init_atmosphere_m 000000000040E327 Unknown Unknown Unknown
init_atmosphere_m 000000000040E297 Unknown Unknown Unknown
init_atmosphere_m 000000000040E21E Unknown Unknown Unknown
libc-2.17.so 00002B1DADA5C3D5 __libc_start_main Unknown Unknown
init_atmosphere_m 000000000040E129 Unknown Unknown Unknown
=== Job finished at: Fri Oct 16 01:02:55 CST 2026 ===


smoothing out a water point, iCell = 835232
smoothing out a water point, iCell = 835523
Using option 'lapse-rate' for vertical extrapolation of temperature

namelist.init.atmosphere
&nhyd_model
config_init_case = 7
config_start_time = '2024-01-21_00:00:00'
config_stop_time = '2024-01-23_00:00:00'
config_theta_adv_order = 3
config_coef_3rd_order = 0.25
config_interface_projection = 'linear_interpolation'
/
&dimensions
config_nvertlevels = 55
config_nsoillevels = 4
config_nfglevels = 42
config_nfgsoillevels = 4
/
&data_sources
config_geog_data_path = '/data/wangj/wyt/geog/'
config_met_prefix = 'FILE'
config_sfc_prefix = 'SST'
config_fg_interval = 10800
config_landuse_data = 'MODIFIED_IGBP_MODIS_NOAH'
config_topo_data = 'GMTED2010'
config_vegfrac_data = 'MODIS'
config_albedo_data = 'MODIS'
config_maxsnowalbedo_data = 'MODIS'
config_supersample_factor = 3
config_use_spechumd = false
/
&vertical_grid
config_ztop = 30000.0
config_nsmterrain = 2
config_smooth_surfaces = true
config_dzmin = 0.3
config_nsm = 30
config_tc_vertical_grid = true
config_blend_bdy_terrain = false
/
&interpolation_control
config_extrap_airtemp = 'lapse-rate'
/
&preproc_stages
config_static_interp = true
config_native_gwd_static = true
config_vertical_grid = false
config_met_interp = false
config_input_sst = false
config_frac_seaice = false
/
&io
config_pio_num_iotasks = 0
config_pio_stride = 1
/
&decomposition
config_block_decomp_file_prefix = 'x20.835586.graph.info.part.'
 
Last edited:
Thank you for the update. Let's try the options below:

(1) config_native_gwd_static = false and config_nsmterrain=2, let me know whether the model works

(2) config_native_gwd_static = true and config_nsmterrain=1 (I suppose this is the option that works, please let me know if I am wrong)

512 GB should be sufficient for this case. Just in case, if you can run with a larger number of processors, which gives you more memory, please try.
 
Back
Top