Segmentation fault at mpas_atm_advection.F

[afernandezody]

Hello,
Sorry to have to post about another issue while running 'terrain blending' but I've been more careful this time trying several resolutions and variations. I even upgraded from 8.2.2 to 8.3.1 but it didn't fix the problem. I recompiled using the DEBUG option to pinpoint the potential issue (at mpas_atm_advection.F):

$ ./init_atmosphere_model
At line 724 of file mpas_atm_advection.F
Fortran runtime error: Index '7' of dimension 1 of array 'indx' above upper bound of 6

Error termination. Backtrace:
#0 0xf70b85a6d44b in ???
#1 0xf70b85a6e277 in ???
#2 0xf70b85a6e7cb in ???
#3 0xac28fd662b8f in __atm_advection_MOD_elgs
at /home/ubuntu/MPASS/MPAS-Model/src/core_init_atmosphere/mpas_atm_advection.F:724
#4 0xac28fd663933 in __atm_advection_MOD_migs
at /home/ubuntu/MPASS/MPAS-Model/src/core_init_atmosphere/mpas_atm_advection.F:655
#5 0xac28fd667f7b in __atm_advection_MOD_poly_fit_2
at /home/ubuntu/MPASS/MPAS-Model/src/core_init_atmosphere/mpas_atm_advection.F:605
#6 0xac28fd66c6af in __atm_advection_MOD_atm_initialize_advection_rk
at /home/ubuntu/MPASS/MPAS-Model/src/core_init_atmosphere/mpas_atm_advection.F:288
#7 0xac28fd69d3bb in __mpas_init_atm_static_MOD_init_atm_static
at /home/ubuntu/MPASS/MPAS-Model/src/core_init_atmosphere/mpas_init_atm_static.F:1260
#8 0xac28fd65c8c7 in __init_atm_cases_MOD_init_atm_setup_case
at /home/ubuntu/MPASS/MPAS-Model/src/core_init_atmosphere/mpas_init_atm_cases.F:216
#9 0xac28fd594417 in __init_atm_core_MOD_init_atm_core_run
at /home/ubuntu/MPASS/MPAS-Model/src/core_init_atmosphere/mpas_init_atm_core.F:92
#10 0xac28fd5177f3 in __mpas_subdriver_MOD_mpas_run
at /home/ubuntu/MPASS/MPAS-Model/src/driver/mpas_subdriver.F:416
#11 0xac28fd51618b in mpas
at /home/ubuntu/MPASS/MPAS-Model/src/driver/mpas.F:20
#12 0xac28fd5161ef in main
at /home/ubuntu/MPASS/MPAS-Model/src/driver/mpas.F:10

The problem only occurs when config_blend_bdy_terrain = true but not for global meshes. I took a look at the subroutine but INDX seems to be dimensionalized based on the variables passed along when calling the subroutine. Rather than pulling the thread and trying some quick fixes, it might be a better idea if you could take a look.
Thanks.
P.S. I just saw that yesterday someone posted an error that might be related.

 

[Ming Chen]

This error is more like some issues in the mesh itself.

On which mesh did you run this case? Can you clarify how you create the regional mesh?

 

[afernandezody]

I tried on the 480 km, 240 km and 120 km resolution. Thus far I've only tried a circle. For example, exa2.circle.pts reads:

Name: exa2
Type: circle
Point: 0.0, -100.0
radius: 500000.0

that created exa2.grid.nc:

netcdf exa2.grid {
dimensions:
nCells = 232 ;
nVertices = 516 ;
nEdges = 747 ;
maxEdges = 10 ;
maxEdges2 = 20 ;
TWO = 2 ;
vertexDegree = 3 ;
codeLen = 1 ;
variables:
int bdyMaskCell(nCells) ;
...
// global attributes:
n_a_sphere = "YES" ;
:sphere_radius = 1. ;
}

If the problem were with the mesh, I would think that it would also fail while generating the static file (I don't know maybe it's related to the vertical grid).
P.S. To create the mesh, I used the MPAS-Limited-Area python code.

 

[mgduda]

In your namelist.init_atmosphere file, you have these pre-processing stages set to true:

config_static_interp = true
config_native_gwd_static = true
config_vertical_grid = true
config_met_interp = true

Can you confirm that the input netCDF file that you're using is a grid file (i.e., a mesh on a unit sphere), and not a static file? The only way that I'm able to generate errors in the poly_fit_2 routine is by setting config_static_interp = true when my input file already contains static fields (implying that the sphere radius has also been expanded to 6371.229 km). Expanding the radius by a factor of 6371.229 m a second time leads to errors when computing weights for fitting polynomial curves in the poly_fit_2 routine.

 

[afernandezody]

Your message posted about 1 or 2 minutes after I left for other commitments and haven't been able to test things until returning. Anyway, the grid file is any of the usual ones (e.g. x1.2562.grid.nc), which has the following global attributes:
// global attributes:
:mesh_spec = "1.1" ;
n_a_sphere = "YES" ;
:sphere_radius = 1. ;
:is_periodic = "NO" ;
:x_period = 0. ;
:y_period = 0. ;
:file_id = "5d483ba2"
As far as the config parameters, I'm using the same ones as for generating the initial conditions for global meshes (switching config_blend_bdy_terrain to true). If I switch config_static_interp and config_native_gwd_static to false => The segmentation fault seems to be gone. It seems fixed and generated the init file (I was even able to generate the lbcs files from it). Will double-check everything tomorrow. Thanks.
P.S. Everything seems to be finally clicking. Most of the problems were a self-inflicted wound because I was combining the two steps to generate the I.C. file into one, which the User Guide (chapter 7) recommends NOT to do. Once I split this task into 2, setting up and running the simulations seem to sail more smoothly.