Hi everyone,
Does anyone know if I can run CMAQv5.3.1 in a different timezone? I currently have my emission input in PST timezone, while my met files and icbc files are in UTC timezone. I want to change my met files and icbc files to PST timezone because it’s difficult to adjust my emission files to UTC timezone. I wonder if running in a different timezone, will CMAQ still produce good results? Is there anything that is hard coded in CMAQ script and must use UTC time?
Thanks
By convention the entire modeling system works in terms of UTC. Note that most applications involve multiple time zones, hence need a standardized notion of time. And SMOKE converts from local to UTC on a source-by-source basis (using its TZONES input file (and I/O API routine ISDST() to determine whether or not local time is daylight-savings or not) as it runs.
If you have local-time emissions from some other source, you can use M3Tools program m3tshift to put them into UTC…
I tried to modify the TFLAG value in my emission files. But the issue is when I want to put two files into one-day emission file, for my inline pt source emissions, different days have different number of rows, which makes me unable to merge two PST timezone emission files into one UTC timezone emission file.
I tried to modify the TFLAG value in my emission files…
From the I/O API Home Page (The EDSS/Models-3 I/O API or https://cjcoats.github.io/ioapi/index.html:
The Models-3 I/O API is A programming interface, not a data format !!
I/O API files are not synonymous with “netCDF files” !!
It is not supported to bypass this programming interface by manipulating the internal data structures directly; you almost certainly will fail to do it correctly. If MS Word .docx is just a data-format, does that mean you try to edit Word-files with a hex editor ??
I see. So in this case, if I want to use the inline pt emission in UTC for a whole 0-24 hr, is there any tool I can use?
And another question, for a emis file that starts from 0:00 to 24:00 in PST, if I use m3tshift to convert the file to UTC, do I get a file that starts from 16:00 to 16:00 in UTC?
Yes. As a hack, you could then do another m3tshift run to add another day of 16:00-16:00 to the file. unless you have day-specific data, for point and area sources, all the weekdays are repetitions of the same 24 hours of data (and likewise for the weekends).
And why has this idea of confining runs to 24 hours come about? The original requirements were that one should be able to do even seasonal or annual runs (and as a matter of fact, I have done multi-decade runs – that needed some I/O API updates around 2010 to avoid problems past the 25-year mark).
And the I/O API gives random access to the data: with a century-long file, it takes the same amount of run-time to access any day in the file – the first day, the middle day, the last day, or any other day. All this artificially having to manage many single-day files in order to do a summer-long study makes no sense to me.
Carlie J. Coats, Jr., Ph.D.
I/O API author/maintailner
Thanks for your answer. I do have day-specific data. The reason why I wanted to get the 24-hour files in a single file was I needed to apply ISAM method in the model run. I need each type of the emission sources stay in one file so that I could track them. But from your answer, it seems that I can just run 8-hr each time and get the same results. Am I understanding correctly?
That’s the way it’s supposed to work, but I understand there have been difficulties (scripting problems?) trying to run CMAQ other than starting at 0Z. Haven’t tried it myself…