MCIP is expecting the WRF output for the time period before your initial time so that it can properly handle the precipitation. WRF accumulates precipitation in a running total (or a “bucket”) in the RAINC and RAINNC (convective and non-convective rainfall, respectively) variables. Generally those variables are available in the WRF output. (There are some other variables available now that can be activated in the WRF output that would eliminate this need, but they would need to be in your WRF history file already.)
CMAQ needs to know the amount of rain that fell during the time interval (i.e., INTVL). MCIP captures the precipitation totals from the prior time increment and subtracts them from the current time increment’s totals to isolate the precipitation over the time increment. That’s why the prior time is needed.
The 5-minute vs. 1-minute issue is a little different, and it’s based on an assumption that I made within MCIP on the time tolerance for data to be valid. That is, the advection time step in WRF is user-definable, and sometimes it does not force data to be output/saved in the WRF history file so they are exactly aligned with the desired temporal frequency in CMAQ (i.e., the INTVL for MCIP). My assumption was that most users are taking WRF output at hourly frequency for CMAQ, but it could be 30-minute or 15-minute, realistically, depending on how fine the grid spacing is. I used a 5-minute tolerance, assuming that users probably would not go more granular than 15-minute output to balance the pragmatism and the data quality. That’s why your 1-minute request is displaying as 5 minutes instead.
Hi! Tanya:
Thank you for your patient explanation, that helps me a lot to understand why mcip try to deal with the prior time. I have another problem is that the history file at prior time (wrfout_d01_2019-10-01-00:00:00) do exist in the InMetDir, but i still get this error (the date i want to run in mcip is 2019-10-01-01:00:00.0000, INTVL = 60, my WRF output at hourly frequency):
*** SUBROUTINE: RDWRFEM
*** LOOKING FOR INPUT MET AT TIME 2019-10-01-00:00:00.0000
*** INPUT FILE NUMBER 2 IS BLANK
Thanks a lot!
Let’s check two things. First, make sure your script is linking in the WRF output files with the data in chronological order. You can check the file, namelist.mcip, that is created by your script to see whether the desired WRF output files are listed and that they are in the correct order. Assuming that you are correctly feeding your data to MCIP, you also need to ensure that you actually have the specific times as part of your output. You can use some options on “ncdump” to scan the Times that are present in the file. It may sound unnecessary to do the second step, but there are some options in the WRF namelist that (to save disk space) will not output the initial time period in the WRF output file. One possible scenario is that you have the WRF namelist option invoked to do that.
Hope this helps. If you have the files correct and the times available in your files, then we will dig a little more deeply.
Thanks for your kind help! According to your guidance, I did the following two checks:
(1). I have checked the namelist.mcip to ensure that the wrfout file i want to run exists in the InMet File.
(2). I have checked the wrfout_d01_2019-10-01_01:00:00 to ensure the variable Time =" 2019-10-01_01:00:00" has been written in this file.(ncdump -v Time)
But i still got this error:
*** SUBROUTINE: RDWRFEM
*** LOOKING FOR INPUT MET AT TIME 2019-10-01-00:00:00.0000
*** INPUT FILE NUMBER 2 IS BLANK
*** ERROR ABORT in subroutine RDWRFEM
ABNORMAL TERMINATION IN RDWRFEM
Date and time 1:00:00 Oct. 1, 2019 (2019274:010000)
Error running mcip
I post four scripts (the run_mcip.csh, namelist.mcip, log.run.mcip and namelist.input) as below.
Thank you for providing these extra pieces of information. It looks like you want to run MCIP starting at 01 UTC 1 October 2019. The script and the MCIP namelist that you provided have this time appropriately listed as the start date in “mcip_start”. It also looks like you would like to run MCIP to process hourly data through 01 UTC 2 October 2019 (24 hours later, which would create 25 time periods of output), because “mcip_end” is set for that date and “intvl” is set to 60 [minutes]. This is all fine.
The WRF output file that you are using has a name that indicates that it is associated with 01 UTC 1 October 2019, which is also good. However, as I mentioned earlier in this thread, you also need to supply the data for 00 UTC 1 October 2019 so that MCIP can isolate the precipitation that fell at each grid cell between 00 UTC and 01 UTC. Furthermore, the warning message in your MCIP log shows that you only have a single time period in the WRF output file (presumably 01 UTC).
I suggest that you set up MCIP so that your InMetFiles script variable contains the chronological list of WRF output files to cover 00 UTC 1 October 2019 through 01 UTC 2 October 2019. This assumes that you have created and saved all of these data AND that these data (all 26 hours) are from the same WRF simulation.
To add to @tlspero’s advice, here is an example of how you could modify your run_mcip.csh script to accomplish this.
set SYYYm1 = 2019
set SMMm1 = 09
set SDDm1 = 30
set SYYYY = 2019
set SMM = 10
set SDD = 01
set SHH = 01
set EYYYY = 2019
set EMM = 10
set EDD = 02
set EHH = 01
set InMetFiles = ( $InMetDir/wrfout_d01_${SYYYYm1}-${SMMm1}-${SDDm1}_${SHH}:00:00 \
$InMetDir/wrfout_d01_${SYYYY}-${SMM}-${SDD}_${SHH}:00:00 )
As @tlspero wrote, this assumes that these wrfout files exist and are from the same WRF simulation.
Of course you could employ different scripting approaches to calculate the year, month and day of the previous day from SYYYY, SMM, and SDD dynamically, but as @tlspero wrote, the key is to list all wrfout files needed to cover the entire desired MCIP processing period plus the time step just prior to the start date in the InMetFiles array. The example run script distributed with MCIP shows how to do that for an MCIP run covering July 2, listing 3 wrfout files with 24 hours each for July 1 - 3.