MCIPv4.5 fails for inconsistent SIMULATION_START_DATE

I am running MCIPv4.5 for 25 hours, from previous day 00 UTC to next day 00 UTC.

The mcip fails for following 2 cases:

CASE 1. When ‘SIMULATION_START_DATE’ isn’t the same for previous and next day wrf outputs. Ex. wrfout_d01_2016-05-29_00:00:00 and wrfout_d01_2016-05-30_00:00:00 files, the mcip.exe encounters with an error in subroutine: CHKWRFHDR (see below). Please note the WRF outputs are for the same domain, it re-started at different times.


*** FIRST FILE = /t1/LADCO_WRF2016/wrfout_4km/wrfout_d01_2016-05-29_00:00:00
*** VALUE IN FIRST FILE = 2016-04-29-00:00:00
*** NEW FILE = /t1/LADCO_WRF2016/wrfout_4km/wrfout_d01_2016-05-30_00:00:00
*** VALUE IN NEW FILE = 2016-05-29-00:00:00

 *** ERROR ABORT in subroutine CHKWRFHDR
 Date and time  0:00:00   May 30, 2016    (2016151:000000)

I tried setting IOAPI_CHECK_HEADERS off and on in run_mcip.csh, but no effect, nothing changed. How to overpass this inconsistent SIMULATION_START_DATE issue when running mcip.exe?

CASE 2. THE mcip fails with an error message of “MCIP output must start after meteorology start time” when running mcip for a day (ex. 2016-07-11_00:00:00) that WRF output has the same SIMULATION_START_DATE (ex. 2016-07-11_00:00:00).

*** MCIP output must start after meteorology start time
*** User-defined MCIP start date = 2016-07-11-00:00:00.0000
*** Input meteorology start date = 2016-07-11-00:00:00.0000

 *** ERROR ABORT in subroutine SETGRIDDEFS
 Date and time  0:00:00   July 11, 2016   (2016193:000000)

!!— Error occurs in mcip.exe for wrfout_4km on 20160711

Please help me resolving these 2 errors I face with MCIPv4.5.

Tsengel Nergui, LADCO


Both of these “abort” conditions are intentional and appropriate.

In Case 1, MCIP aborts because you are trying to chain together WRF output files from different initializations. The main issue is that precipitation is output by WRF in a running total. That is, the convective rainfall and non-convective rainfall are both set to 0 at the model initialization, and the rainfall totals in those arrays are cumulative. However, CMAQ wants the amount of precipitation that accumulated over the hour (typically), not over the course of the WRF simulation. MCIP calculates this on-the-fly by storing the accumulation from the previous hour and subtracting that from the current hour. If you are mixing-and-matching different WRF runs, you can probably see how subtracting a running total from 0 at that new initialization time is a problem. In addition, even with nudging, the locations and accumulations of rainfall will differ depending on how and when WRF is initialized.

In Case 2, we require that you allow some amount of spin-up time in WRF before you can use the output in CMAQ. The rationale is that there are several key atmospheric fields for air quality modeling (primarily in the clouds, land-surface, boundary-layer realms) that are initialized to 0. In addition,the state variables are often coarsely resolved at the initial time, as they typically reflect the incoming forcing fields (from NAM, ERA, or whatever). We deliberately do not recommend an appropriate length of spin-up for WRF; it is at the user’s discretion.

Hope this helps.

Thank you very much for your explanations. I will follow with WRF modeler for the concerned issues.


Hi Tanya,

We wanted to use MCIP outputs for SMOKE and CAMx runs. Do you see any concerns with precipitation related variables for CAMx run? As I see wrfcamx tool stripes a variable called ‘PRATE_MMpH’ from WRF output. If it is ‘precipitation rate per hour’, I believe that it would be fine for met variables for CAMx run? Nor I would think that SMOKE needed any precipitation related variables. Please correct me if I am off talking.

Greatly appreciated, Tsengel


I have not run CAMx, but I would assume that you will have the same issue with precipitation that MCIP is guarding against for CMAQ.


Biogenic emissionss needs total rainfall rate (per hour), which TMPBEIS3 computes from the convective and nonconvective rainfall rates RC and RN.


Based on what @cjcoats wrote, you will have the same problem in CAMx that you would in CMAQ, so it’s good that MCIP is guarding against this for you.


Thank you all for your invaluable inputs. Tsengel

Hello,TsengeINergui, I am running mcip5.1 in CMAQ5.3.1 and encountered the same problem as you. How can I solve this problem? look forward to your reply.

Hi Lihongli,

I did not resolve the problem, but ended up re-running the WRF to have consistent SIMULATION_START_DATE, which was a faster fix by knowing all these important safeguards built in MCIP source codes. Bottom-line is that a modeler should be mindful of whole modeling chains (WRF, MCIP, SMOKE, Air quality model) processes, then set-up and run WRF. Good luck. Tsengel