GFS version mismatch and LANDSEA not found error running init_atmosphere

[ep-98d]

I am trying to run init_atmosphere using GFS intermediate data. Running it is giving me following error.

ERROR: Didn't recognize format version of data in GFS:2020-01-01_00.
ERROR: Found version 83886080 but expected either 3, 4, or 5. This could be an endian problem.
ERROR: ********************************************************************************
ERROR: LANDSEA field not found in meteorological data file GFS:2020-01-01_00
CRITICAL ERROR: ********************************************************************************

Here are some info.

1. namelist.init_atmosphere

&nhyd_model
config_init_case = 7
config_start_time = '2020-01-01_00:00:00'
config_stop_time = '2020-01-02_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 = 38
config_nfgsoillevels = 4
config_gocartlevels = 30
/
&data_sources
config_geog_data_path = '/tempo/mpas.static.data'
config_met_prefix = 'GFS'
config_sfc_prefix = 'SST'
config_fg_interval = 21600
config_landuse_data = 'MODIFIED_IGBP_MODIS_NOAH'
config_soilcat_data = 'STATSGO'
config_topo_data = 'GMTED2010'
config_vegfrac_data = 'MODIS'
config_albedo_data = 'MODIS'
config_maxsnowalbedo_data = 'MODIS'
config_supersample_factor = 3
config_lu_supersample_factor = 1
config_30s_supersample_factor = 1
config_use_spechumd = false
/
&vertical_grid
config_ztop = 30000.0
config_hybrid_coordinate = true
config_hybrid_top_z = 30000.0
config_nsmterrain = 1
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_native_gwd_gsl_static = false
config_vertical_grid = true
config_met_interp = true
config_input_sst = false
config_frac_seaice = true
/
&io
config_pio_num_iotasks = 0
config_pio_stride = 1
/
&decomposition
config_block_decomp_file_prefix = 'x1.10242.graph.info.part.'
/

2. GFS data was downloaded from NCAR RDA and it was processed through ungrib.exe, and they are copied into the case directory.

GFS files:
gdas1.fnl0p25.2020010100.f00.grib2
gdas1.fnl0p25.2020010106.f00.grib2
gdas1.fnl0p25.2020010112.f00.grib2
gdas1.fnl0p25.2020010118.f00.grib2
gdas1.fnl0p25.2020010200.f00.grib2

 

[ep-98d]

Hmm. Seems like those GFS grib files don't contain SEALAND field.

 

[ep-98d]

I fixed the problem. It was coming from compilation flag turning big-endian to little-endian.

 

[mgduda]

Thanks for following up. Out of curiosity, which compiler flag was turning big-endian into little-endian output, and in which compilation stanza was this flag? Are you using the default (un-modified) WPS code?

 

[ep-98d]

I am using AMD AOCC 5.2 for the entire workflow, including WPS and MPAS. Soon, I will also be working with MPAS-JEDI.

I explained this issue in detail here. The root of the problem is that one of the libraries required to build WPS (specifically, NGL) has an issue during the final linking stage of ungrib.exe. gfortran allows object files with identical names to be linked without reporting an error, whereas AOCC does not. I did not modify the WPS source code itself, but I did have to make changes to the external libraries, including Jasper and NGL, to get the build to succeed.

Regarding the big-endian and little-endian issue, please disregard it, as it is not an issue as long as both WPS and MPAS are compiled with the big-endian flag enabled. In my case, the problem occurred because I compiled WPS without the big-endian flag, which caused MPAS to encounter file-reading errors.