Problems on Create Initial and Boundary Conditions from Seasonal Average Hemispheric CMAQ Output

i`ve been trying to create IC and BC file from “Seasonal Average Hemispheric CMAQ Output” which is available at my run aborted with the following error:

File name “/public/home/cmaq/zjr/two_way/CMAQ-5.3/data/hemisphere/”
File type GRDDED3
Execution ID “???”
Grid name “WRF_CMAQ_2WAY”
Dimensions: 187 rows, 187 cols, 44 lays, 254 vbles
NetCDF ID: 196608 opened as READONLY
Starting date and time 2015001:000000 (0:00:00 Jan. 1, 2015)
Timestep 010000 (1:00:00 hh:mm:ss)
Maximum current record number 2
Differences found between files CTM_CONC_1 and MET_CRO_3D_CRS :
Checking MET_BDY_3D_FIN File for consistent header data
No file header inconsistencies for MET_BDY_3D_FIN
Input SDATE equals zero; SDATE reset to MET_BDY_3D_FIN file start date
Input STIME equals zero; STIME reset to MET_BDY_3D_FIN file start time

 Input RUNLEN not set or equal to zero.                                          
 Resetting RUNLEN to correspond to MET_BDY_3D_FIN file ending date & time.       

 NCOLS_IN:          187
 NROWS_IN:          187
 NLAYS_IN:           44
 NSPCS_IN:          254
 NBNDY:             688
 NLAYS:              27

 Value for IOAPI_ISPH:  '20'
 INITSPHERES:  input sphere Normal Sphere (MM5 & WRF-ARW) R=6370000
 >>--->> WARNING in subroutine LAMBERT/SETLAM
 Bad origin latitude Y =    90.000
 *** ERROR ABORT in subroutine LAT_LON
 Lambert projection setup error for CTM CONC file

Is there someting wrong with projection mapping?whether BCON con not convert the polar projection to Lambert projection?
I would be grateful if anyone can help me with this issue.


could you please provide some additional details on what you did prior to running BCON and could you please also post your BCON run script?

Looking at the portion of the log file you posted above, it appears you may have downloaded the seasonal average H-CMAQ file “”, renamed it as, and then set MET_CRO_3D_CRS in the BCON run script to point to that file. However, the start date/time and number of time steps reported in your log file don’t exactly match those in the original file, so I’m wondering if you may have modified the downloaded file in some fashion before attempting to run BCON. If you did, what did you attempt to modify and which tools did you use?



Dear Christian,

Yes i downloaded the seasonal average H-CMAQ file,and used ‘m3tshift’ tool shifted time stamps in the downloaded file,which means the shifted file only contain one-time stamps(2015001), otherwise bcon run would aborted with the following error messages:
*** ERROR ABORT in subroutine M3_INBNDY
Requested starting time is not in the CTM_CONC_1 file
Date and time 1:00:00 Jan. 1, 2015 (2015001:010000)

Attached are the BCON run script, and c-shell script for using m3tshift to shift time stamps.
run_bcon.csh (5.1 KB) timeshift.csh (1010 Bytes)

Thanks a lot !

Thanks for this additional information.

Could you please post the header attributes, particularly the projection information, for your CTM_CONC_1 (i.e. $CMAQ_DATA/hemisphere/ and MET_BDY_3D_FIN (i.e. $CMAQ_DATA/mcip/output01/METBDY3D_d01) files?

In addition, while this shouldn’t be related to the projection problem, I suggest that you update your timeshift.csh script to exactly follow the sample script posted at, only updating “set TARGET_YEAR = 2014” to “set TARGET_YEAR = 2015”. The values in this file are six quarterly averages, and you want BCON to take care of the temporal interpolation to a particular day rather than handling this via m3tshift. The only thing m3tshift should be used for in this approach is to shift all six quarterly averages forward or backward by one or more years to cover the intended modeling period.

Dear Christian,

Thanks for your suggestion and it will be great helpful!
Attached are the header file for CTM_CONC_1 and MET_BDY_3D_FIN.
header_attributes_BDY.txt (6.0 KB) header_attributes_CONC.txt (9.9 KB)
Thanks a lot !

Do you really want a projection relevant to Mongolia? the XCENT=105 seems to suggest that.

It is customary to follow the ISO 6709 Standard, according to which Western Hemisphere longitudes are negative, between 0 and -180. -105 cuts across the western Great Plains in the US…

[BTW, beware, of course, of WMO data, for which longitudes are between 0 and 360 (and which is a PITA to manipulate in standard geographic tools ;-( ) ]

Thanks for posting the projection parameters for CTM_CONC_1 and MET_BDY_3D_FIN.

It seems the underlying problem is that GDTYP is set to 2 (Lambert conformal) in your CTM_CONC_1 file while it was 6 (polar stereographic) in the file you downloaded and ran through m3tshift. All the other projection parameters are still unchanged from the downloaded file, in particular YCENT is still set to 90 which causes the error in SETLAM. Put differently, the BCON code should be calling SETPOL rather than SETLAM when processing CTM_CONC_1 but gets tripped up by the incorrect setting of GDTYP.

Did you do any manual editing of this attribute? Processing the downloaded file through m3tshift should not have caused this, so I’m wondering what other processing might have been done to this file.



Dear Christian,

As you suggested, I manually revised the ‘GDTYP=2’ to ‘GDTYP=6’ and it worked !
Thanks for your useful detailed feedback,i will re-download it from google drive and doublecheck the file.But i did not do other modify to seasonal average H-CMAQ file before attempting to run BCON.

Thanks a lot !

Hi Zunyir,

I’m glad this worked. I’m still puzzled how GDTYP was changed to 2 in the H-CMAQ seasonal average file you initially tried to use as input to BCON. I downloaded the H-CMAQ file from the CMAS data warehouse yesterday and confirmed that in that file the value of GDTYP is correctly set to 6 (polar stereographic). If you are able to trace back what happened, maybe you can post your experience in this thread to help other users avoid this potential pitfall.


Dear Christian,

I think the only one questionable step is the way to download the H-CMAQ file from the CMAS data warehouse, in China mainland we can not directly access the google drive so i have to download it via mobile VPN application, then copy it from phone memory card to computer, and i also find that raw data only contain three-time stamps (10/16/2015 12:00 (2015289, 120000), 1/16/2016 0:00 (2016016, 0), 4/16/2016 12:00 (2016107, 120000)), the other three-time stamps( 7/17/2016 0:00, 10/16/2016 12:00, and 1/16/2017 0:00)turned ito ( 0, 0).Maybe an exception might occur when i transfer the data from phone to PC ……?
I swear did not do anyother modify to this file after i downloaded,i will re-download it from google drive again and doublecheck it.


This is really interesting, thank you for posting your experience.