WRF-MCIP Observation Nudging


I am having a problem runnning MCIP after running WRF. I keep getting this error when running MCIP

*** NCF: NetCDF: Attribute not found

 *** ERROR ABORT in subroutine CHKWRFHDR
 Date and time  13:00:00  March 6, 2017   (2017065:130000)

Error running mcip

I dont mean to have any observation nudging in my WRF and I believe I dont have any settings that would indicate this in my namelist.input. I have attached both the mcip run script and the namelist.input file.

namelist.input.txt (3.7 KB) run_mcip.csh.txt (19.4 KB)


What version of WRF were you using for this MCIP run, and what version of MCIP were you using?


Please use the ncdump -h command on your WRF file to determine if there is a variable named OBS_NUDGE_OPT and attach the output to this report.

ncdump -h subset_wrfout_d01_2016-07-02_00:00:00 > subset_wrfout_d01_2016-07-02_00:00:00.txt

Thank you

MCIPv5.1 and WRFv4.0

Note: It looks like OBS_NUDGE_OPT is a global attribute in the benchmark data.

Here is the output from the first subset of data

wrfout_d01_2017-03-01_12:00:00.txt (52.4 KB)

I noticed from your run script that you have several wrfrst files listed for InMetFiles
I don’t believe MCIP processes WRF’s restart files. It could be that this error is due to the subroutine not finding the expected attributes because it’s a different file type.
If you only input wrfout files, does the error occur?


I then get the following output error

 ~~~ Processing meteorology for time = 2017-03-16-12:00:00.0000

*** LOOKING FOR INPUT MET AT TIME 2017-03-16-11:00:00.0000

 *** ERROR ABORT in subroutine RDWRFEM
 Date and time  12:00:00  March 16, 2017  (2017075:120000)

You need to provide the last wrfout file prior to your startime as well as the wrfout files for the time period you’re interested in. So if MCIP_START is set to 2017-03-16 12Z, then the first wrfout file should contain data for 2017-03-16 11Z. This is done so that variables that accumulate over the wrf run, like some precipitation fields, can be properly computed.


It should contain the data. I have included all the wrfout files that wrf.exe produced. The first wrfout starts at 2017-03-01-12Z so it should be good to go.

I think you need to have a start time of 13Z then, so that you have at least one hour of WRF output prior to when MCIP is supposed to run.


I just did that and it stops at 2017-03-05-12 and says the input file is not there but the next wrfout file starts at 2017-04-12_04:00:00 so the data should be there.

I was also told that two weeks was necessary for MCIP to spin up properly.

I think it’d be helpful to share the run script you’re currently using and the exact error (as above) so that I can better understand the problem.

Here is the run script and log file

runmcip.log.txt (5.8 KB) run_mcip.csh.txt (18.8 KB)

Thanks, I’d suggest doing a quick check on your wrfout files (ncdump -h filename) and seeing if the number of timesteps stored in each files fully covers the simulated period. Most modelers set up WRF such that each simulated day produces one output file with 24 output times in each file, which doesn’t seem to be the case here as you only have 2 files to cover the entire period. I think that MCIP is flexible about the number of output times in a file (correct, @tlspero ?) but of course missing data would be a problem.


The run script is set up to produce a single set of output files containing hourly time steps from 2017-03-15_13:00:00 to 2017-05-05_06:00:00. This should not be a problem, provided that you have WRF outputs (preferably hourly) for that entire period. MCIP is a Processor of meteorological data, it is not a meteorological model itself.


A few things…

  1. MCIP does not need any spinup time. Not sure where that came from. You may want some science processes in the meteorological model to spin up, such as clouds need a few hours and some land-surface interactions (if they are “cold started”) could require several days to a few weeks. These are a function of the meteorology and not of MCIP itself.
  2. @mmallard is correct the MCIP is not set up to handle WRF restart files (“wrfrst”). You must use the WRF history/output files (“wrfout”).
  3. As @mmallard mentioned, MCIP does not care how many output time steps are in any given file. They can certainly vary. MCIP only wants you to list them in order in the script in the “InMetFiles” variable that is used to build the namelist. MCIP will search that list for the time it wants, and it will create an error condition if it cannot find the next time to process (based on INTVL, in minutes).
  4. Finally, one of the nuances of using WRF data is that the precipitation is partitioned into buckets of convective and non-convective liquid-equivalent precipitation that continue to accumulate from the initialization of the WRF simulation. CMAQ requires a total over its “time step” (nominally one hour, but technically that should be flexible). We use WRF data for CMAQ at some point after the model is initialized (to allow key fields like PBL height and clouds to be non-zero). Consequently, we need to provide the WRF output data that covers one CMAQ time step (typically one hour, which seems to be what you used here) prior to the start of the data that you want MCIP to process so that the precipitation increment can be calculated by subtracting off the previous accumulated total.

**The answer to your question is in #4.


  1. I believe it came from you in an earlier post MCIP Run Error SETGRIDDEFS
  2. Sounds good will only use wrfout from now on
  3. Sounds good I will look into INTVL to make sure they are good
  4. Yes I did set it to one hour before but then it still stops and produces the same error with missing input files. Im starting to think this is a WRF issue and following up on that side.

I am using the standard WRF settings and that last time I ran this the output files worked just fine for MCIP. Is there a specific place in the namelist.input file to make sure it is outputting as you have stated?

This is not the same as the reply you referenced in “MCIP Run Error SETGRIDDEFS”. I never said anything remotely close to that.