MCIPv4.5 fails for inconsistent SIMULATION_START_DATE

MCIP
1

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.

*** SUBROUTINE: CHKWRFHDR
*** WRF FILES DO NOT SEEM TO BE FROM SAME DOMAIN
*** VARIABLE = SIMULATION_START_DATE

*** 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
 ABNORMAL TERMINATION IN 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).

*** SUBROUTINE: SETGRIDDEFS
*** 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
 ABNORMAL TERMINATION IN 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

2

@TsengelNergui –

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.
–Tanya

3

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

Tsengel

4

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

5

@TsengelNergui –

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.

–Tanya

6

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

7

@TsengelNergui –

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.

–Tanya

8

Thank you all for your invaluable inputs. Tsengel

9

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.

10

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

3 Likes
11

Hi,

I have the same problem as given in case 1 here.

Picture2
Picture2822×460 121 KB

Based on this thread I understand that the issue is related to the wrf initialization time. However, at this moment I am unable to get wrf data fixed. So, I was wondering if there is another way to resolve this issue.
I only need the mcip output to use in SMOKE and I do not use CMAQ. I am using MCIPv5.3 version.
Please help me resolve this issue.
Thank you.
Sham

12

@shayamila.gamage -

It seems that you are trying to use the same execution of MCIP to process data from two independent WRF simulations. MCIP is set up to require the same “SIMULATION_START_DATE” (or initialization time) from WRF because the precipitation is usually set as a running total in WRF. MCIP uses the previous time period from the same WRF run to isolate the amount of rainfall for a given hour (or whatever your time increment is). To get around this issue, you can run MCIP separately on each of those WRF simulations without trying to do it all at once. That way, MCIP will only subtract the rainfall from the previous time period from files generated by physically consistent runs.

Hope this helps.
–Tanya

13

Thank you for your response, Tanya.

I tried what you suggested and the issue is that I will be missing an hour of data between the two initializations. For example, if I want to get mcip output starting from 2018-07-01:00:00:00 UTC to 2018-07-02:00:00:00UTC, I have to run mcip twice.
first run from 2018-07-01:00:00:00 UTC to 2018-07-01:06:00:00UTC and second from 2018-07-07:00:00:00 UTC to 2018-07-02:00:00:00UTC. First run works fine as the hour earlier data (2018-06-30-23:00:00UTC) has the same initialization time as 2018-07-01:00:00:00 UTC.
However, the second run doesn’t work as the initialization time for 6utc and 7utc are different.

Maybe there is no other way than getting wrf fixed.

Thanks again,
Sham

14

@shayamila.gamage –

A lot of times, we have WRF output that covers the same time stamp twice, where one file ends with a given time and the second file is from a simulation that is initialized at that time. Is your second file for a simulation that is initialized at 6 UTC or at 7 UTC?

–Tanya

15

@shayamila.gamage –

Also, if you are using these MCIP output data only for SMOKE, then I’m not sure if the precipitation fields matter. Depending on your answer to the previous question, and if you can confirm that you do NOT intend to use these files for CMAQ (or another similar model where the precipitation field is needed), then I can probably help you engineer a solution. It is not a preferred route, but I think I can help you salvage your data for this case.

–Tanya

16

Hi Tanya,
The second file for the simulation is initialized at 7 UTC. I need MCIP output to generate SMOKE layered emissions from point sources. Then that SMOKE output will be converted to bin files and used in the polair3d, the model we are using. This is the first time we are trying to get this working and as long as I can generate the MCIP output for each day everything should work out :crossed_fingers:t4:

I will greatly appreciate it if you can help me engineer a solution.

Thank you.

Sham

17

@shayamila.gamage –

Thank you for your patience. I’m trying to gather a little more information in the background so that I don’t give you a solution that will make mess up your files for polair3d.

Can you tell me if you are using a different processor to read the meteorological data into polair3d? I think you could have some issues with the data at 7 UTC, if that is the case (and depending on what variables you need).

–Tanya

18

Hi Tanya,

We did not get any issues with these WRF data in polair3d and it reads these files independently. We just want to generate layered emissions for point sources using smoke that can be later use as volume emissions in polair3d.

Moreover, polair3d uses a program called meteo to preprocess the met data. Here is the list of input data used in it, surface temperature(167), skin temperature (235), surface pressure (152), temperature (130), specific humidity(133), liquid water content (246), ice water content (247) (if Ice cloud = true), medium cloudiness(187), high cloudiness (188), meridional wind (132), zonal wind (131), zonal friction velocity(180), meridional friction velocity (181), solar radiation (169), boundary layer height (159), soilwater content (39), sensible heat (146), evaporation (182).

I also contacted the group that we obtained the wrf data from as well and this is what I gathered from them.

“Each cycle started from 00 UTC until 06 UTC the very next day (i.e. 30-hour forecast).

In my application, I need a consecutive data for a month. Thus, I discarded first 6-hour forecast (00-06 UTC), assuming that is the spin-up period.

The directory where link files exist thus have 744 files (24 hours x 31 days).

For data transfer, I used the same method, linking 07-30 hour forecasts only.”

Since they have already discarded the overlapping data, we are not able to obtain those. Moreover, at this moment we are unable to request re-processing of wrf data as well.

If there is a way that we can skip the precipitation fields in the MCIP process that would be ideal for us. Once again, thank you so much for taking time to help me solving this issue and really appreciate it.

Thank you.

Sham

~WRD0001.jpg

19

@shayamila.gamage –

Thank you for the important details and clarifications.

I want to emphasize (not for you, but for others who will later refer to help in the Forum) that this solution is tailored specifically for the situation described above. I do NOT recommend following this path just to circumvent error conditions.

That said, in MCIPv5.3.3 setgriddefs.f90, please comment out lines 444-448 to prevent checking the consistency of the start dates in the adjoined WRF output files.

You should NOT use the precipitation values from the 7 UTC processing because they will be garbage. Otherwise you should be good to go.

Please let me know if this solves your issue.
–Tanya

20

Hi Tanya, I am confused about which lines you meant exactly. Did you mean the following lines under,” Check user-defined MCIP output time info against input meteorology”?

~WRD0001.jpg