Can CMAQv5.3.3 run data for one month?

Hello, I am trying to use CMAQv5.3.3 to run the data for one month, I have generated mcip, icbc and emis files, among which, mcip lasts for one month, icbc and emis files last for one day (as far as I know, When running cctm, you can use emis and icbc files for one day. When cctm is running for more than one day, these two types of files will be cycled in.)
I first tried to set the NSTEPS= 240000 of the cctm script, which could run normally and output the result file successfully, and then I tried to set the NSTEPS=7440000 (31 days =31*24h=744h) of the cctm script, but the run would end in a few seconds. I guess the number 7440000 does not meet the format requirements of NSTEPS (the requirement of NSTEPS is HHMMSS), so I tried to set NSTEPS=480000 to check whether the emis file and icbc file can circulate normally after the format error is eliminated. The answer is no. After calculating the data for the first day, cctm will report an error and will not generate the result file with the same size as NSTEPS= 240,000.
This is one of the log files at NSTEPS= 240,000:
NSTEPS=240000.txt|attachment (791.8 KB)
This is one of the log files when NSTEPS=7440000:
NSTEPS=7440000.txt|attachment (1.4 KB)
This is one of the log files at NSTEPS=480000:
NSTEPS=480000.txt|attachment (793.5 KB)
Here is my cctm run script:
run_cctm_Bench_2016_12SE1new.csh (34.8 KB)
How can I run the data for 31 days? How to solve the formatting problem of NSTEPS and the looping problem of files such as emis?

1 Like

The benchmark run scripts are configured to use emissions, mcip, and icbc files that start at GMT time of 00 hours, and use 24 hours for NSTEPS. The START_DATE and END_DATE specify how many days to run, depending on how many days of input data you have. The START_DATE and END_DATE are used to determine how many times to run CMAQ for the NSTEPS period of time.

#> Set Start and End Days for looping
 setenv NEW_START TRUE             #> Set to FALSE for model restart
 set START_DATE = "2016-07-01"     #> beginning date (July 1, 2016)
 set END_DATE   = "2016-07-02"     #> ending date    (July 1, 2016)

#> Set Timestepping Parameters
set STTIME     = 000000            #> beginning GMT time (HHMMSS)
set NSTEPS     = 240000            #> time duration (HHMMSS) for this run
set TSTEP      = 010000            #> output time step interval (HHMMSS)

Beginnning of the day loop in the run script:

while ($TODAYJ <= $STOP_DAY )  #>Compare dates in terms of YYYYJJJ

End of the day loop in the run script:

  #> The next simulation day will, by definition, be a restart
  setenv NEW_START false

  #> Increment both Gregorian and Julian Days
  set TODAYG = `date -ud "${TODAYG}+1days" +%Y-%m-%d` #> Add a day for tomorrow
  set TODAYJ = `date -ud "${TODAYG}" +%Y%j` #> Convert YYYY-MM-DD to YYYYJJJ

end  #Loop to the next Simulation Day

If you would like to run for 48 hours you would change the NSTEPS setting and you would also need to use combine or another tool to ensure that the inputs provide 49 hours worth of data. You would also set the END_DATE equal to the START_DATE so that you only run 1 48 hour period.

If you wanted to run multiple 48 hour periods, then you will need to modify the script. I am not sure the best way of doing that

#> Set Start and End Days for looping
 setenv NEW_START TRUE             #> Set to FALSE for model restart
 set START_DATE = "2016-07-01"     #> beginning date (July 1, 2016)
 set END_DATE   = "2016-07-01"     #> ending date    (July 1, 2016)

#> Set Timestepping Parameters
set STTIME     = 000000            #> beginning GMT time (HHMMSS)
set NSTEPS     = 480000            #> time duration (HHMMSS) for this run
set TSTEP      = 010000            #> output time step interval (HHMMSS)

Using 48 hours would then require boundary conditions for 49 hours as shown below:

BCON:

netcdf BCON_20160701_bench {
dimensions:
	TSTEP = UNLIMITED ; // (49 currently)
	DATE-TIME = 2 ;
	LAY = 35 ;
	VAR = 215 ;
	PERIM = 364 ;

ICON or the initial conditions does not need to be more than 1 hour

netcdf ICON_20160630_bench {
dimensions:
	TSTEP = 1 ;
	DATE-TIME = 2 ;
	LAY = 35 ;
	VAR = 222 ;
	ROW = 80 ;
	COL = 100 ;

       :SDATE = 2016183 ;
       :STIME = 0 ;
:TSTEP = 10000 ;

MCIP output contains 49 hours

ncdump METCRO3D_160702.nc | more
netcdf METCRO3D_160702 {
dimensions:
	TSTEP = UNLIMITED ; // (49 currently)
	DATE-TIME = 2 ;
	LAY = 35 ;
	VAR = 16 ;
	ROW = 80 ;
	COL = 100 ;

		:SDATE = 2016183 ;
		:STIME = 0 ;
:TSTEP = 10000 ;

Emissions contains 49 hours

ncdump  emis_mole_all_20160701_cb6_bench.nc | more
netcdf emis_mole_all_20160701_cb6_bench {
dimensions:
	TSTEP = UNLIMITED ; // (49 currently)
	DATE-TIME = 2 ;
	LAY = 1 ;
	VAR = 62 ;
	ROW = 80 ;
	COL = 100 ;
		:SDATE = 2016183 ;
		:STIME = 0 ;
		:TSTEP = 10000 ;

One recommendation is to use m3xtract to extract the hours required for MCIP output to be the same 25 hour periods as your Emissions, and BCON files.

3 Likes

Thank you for your patience! !!
My understanding of your reply is that if I want to study the data for a whole month, I need to generate an mcip file every day, and generate 31 files in total, so that the mcip file is currently the same as that of emis and icbc files, both of which are 25, and then input these files into cctm. Set NSTEPS== 240,000, and then loop through the results for a month by adjusting START_DATE and END_DATE to the beginning and end of the month, respectively, right?

The above method is used currently by most groups. Mainly due to the need to keep the input file sizes reasonable.

I think you can use the month-long MCIP files, for all of the days.

Set NSTEPS=24 hours, and by adjust START_DATE and END_DATE to the beginning and end of the month, with the emissions, and bcon file names set to loop over each day.

#> Emis file
set EMISfile  = emis_mole_all_${YYYYMMDD}_[your_filename].ncf
#> Boundary conditions
  set BCFILE = CCTM_BCON_${YYYYMMDD}_[your_filename].nc
set NSTEPS     = 240000            #> time duration (HHMMSS) for this run

The model will be able to find the correct data in the MCIP file, it is just a matter of how you instruct the run script to find the files.

  #> MCIP meteorology files 
  setenv GRID_BDY_2D $METpath/GRIDBDY2D_[your_month_long_file].nc  # GRID files are static, not day-specific
  setenv GRID_CRO_2D $METpath/GRIDCRO2D_[your_month_long_file].nc
  setenv GRID_CRO_3D $METpath/GRIDCRO3D_[your_month_long_file].nc
  setenv GRID_DOT_2D $METpath/GRIDDOT2D_[your_month_long_file].nc
  setenv MET_CRO_2D $METpath/METCRO2D_[your_month_long_file].nc
  setenv MET_CRO_3D $METpath/METCRO3D_[your_month_long_file].nc
  setenv MET_DOT_3D $METpath/METDOT3D_[your_month_long_file].nc
  setenv MET_BDY_3D $METpath/METBDY3D_[your_month_long_file].nc
  setenv LUFRAC_CRO $METpath/LUFRAC_CRO_[your_month_long_file].nc
1 Like

Hello, professor, I would like to ask you a question. The CMAQ5.3.2 version I am using now uses MEGAN3.1 to estimate the BVOC emission, and I have now put the BVOC emission into the Grids emissions files。
报错信息为

Could you please post your CCTM run script?

Your error message suggests that you did not specify the LUFRA_CRO environment variable in your run script to point to the relevant MCIP output file so the code will look for land use fractions in the GRID_CRO_2D file, but that you also used an MCIP version that is new enough to store the land use fractions in the LUFRAC_CRO rather than the GRID_CRO_2D file.

Please also note that your post does not seem to be related to the topic of this existing thread. For future posts covering a new topic, please open a new thread and follow the forum posting guidelines.