@Catalyst2682 – I see that you still have INTVL = 180 minutes. Do you have hourly WRF data available?
@tlspero
Yes, I have hourly WRF data. I just ran mcip with the code now using hourly WRF data, yet there was still an error as it’s shown below:
~~~ Processing meteorology for time = 2016-01-31-19:00:00.0000
*** SUBROUTINE: RDWRFEM
*** LOOKING FOR INPUT MET AT TIME 2016-01-31-19:00:00.0000
*** INPUT FILE NUMBER 2 IS BLANK
*** ERROR ABORT in subroutine RDWRFEM
ABNORMAL TERMINATION IN RDWRFEM
Date and time 19:00:00 Jan. 31, 2016 (2016031:190000)
Error running mcip
My end date and time is 2016-01-31-18:00:00.0000, but it’s looking for 2016-01-31-19:00:00.0000 period.
When I used the MCIP script that accompanied CMAQ, there was no any error BUT the results were in bulk form e.g only one METCRO3D file for the whole month was generated. However, I want results that will be a file for each day of simulation. For instance, one METCRO3D for each day, resulting into 31 METCRO3D files for the whole month of simulation.
Is there any way I can run the MCIP script that accompanied CMAQ that will generate my desired result format? I’ll appreciate this a lot.
Thanks so much sir.
Catalyst
WHY?? File-management for lots of single-day files is a PITA (and rather ridiculous, IMNHO).
The I/O API is a direct access file method. To pick one (extreme) example, this means:
Suppose you had a century-long METCRO3D file from 1950001:000000 through 2050001:000000, then it takes exactly the same amount of time to open the file and read the data for the starting time 1950001:000000 as it does to open the file and read the data for Midnight Christmas Day of the last year, 2050359:000000
By the way, all of the file-addressing/ date&time arithmetic is carefully coded not to overflow even for thousand-year-long files…
I apologize for your difficulties with the MCIP script. I did not write the algorithm that apparently is in the released script, so I don’t know how it works. Most people run their days as 00 UTC to 00 UTC, so it is possible that the person who implemented the algorithm used that assumption.
One way to approach the problem is to run MCIP 31 separate times, where you modify the MCIP_START and MCIP_END each time and do not use the autogenerated “sdate” and “edate” variables. That is a suboptimal approach, but it will get the job done with the script you have.
In the meantime, I’ll see what I can do to update the released script with an algorithm that is more flexible.
Tanya
1 Like
Actually, a proper time step may well be shorter than an hour.
Think of (top of the PBL) wind speed as being a conversion factor between spatial resolution and temporal resolution. Then, if 10 meters/second is a reasonable value for that wind speed, then
cell-size / 10
is an estimate of what time step you should be using. Actually, you can relax that by maybe a factor of two, since the met models have actually-delivered spatial resolution worse than double their theoretical resolution).
FWIW
1 Like
@cjcoats @tlspero @cgnolte @rpedruzzi @bbaek Thanks so much for your useful responses. I got this error while running a bioemiss (megan_bio_emiss) script and this has taken a lot of my time while trying to resolve it.
“./megan_bio_emiss: symbol lookup error: ./megan_bio_emiss: undefined symbol: for__b_fmt_table”
Any hint to resolve it would be greatly appreciated.
Thanks
@cjcoats is correct that the ideal output time step for WRF to be used with CMAQ could be (and is likely to be) under an hour. However, I would like to clarify that the original poster was using 3-hourly output (when hourly output was available), and that’s not acceptable. As an aside, MCIP will process input on time scales greater than an hour for the convenience of users who want to treat MCIP as a post-processor to WRF to enable I/O API tools to be used for meteorology model evaluation.
Dear @rpedruzzi,
Have you been able to solve this particular problem?
Thanks and warm regards,
Catalyst
There’s also M3Tools program wrftom3 that can be used for the conversion of WRF output to M3 I/O API – it does “raw” WRF output variables, but does not do the creation of new derived variables for CMAQ the way MCIP does. See https://www.cmascenter.org/ioapi/documentation/all_versions/html/WRFTOM3.html
Hi tlspero
Would you tell me how to set up to run from WRF-Chem output ?
MCIP is not set up to run with WRF-Chem output.
In your future interactions with the Forum, please open a new thread rather than link to an old conversation that has been solved previously. That helps us manage the open issues, and it also helps other users who are searching the archives.
Thank you for your cooperation.
–Tanya
thank you, i got it
bandaoshutiao