When reading the SMOKE v4.5 manual, it says in sections 2.3.2.1 and 2.3.2.2.4 that hourly fire emissions with pre-computed plume rise is an option (we used to run this years ago). However, when I go to the section that is linked for PTHOUR (8.2.7), there is no mention of the input file format for hourly fire emissions. I remember needing PTOP, PBOT, and LAY1F … but none of these variables are mentioned in the manual. Is hourly fire emissions still an option in SMOKE? If so, should I just refer to an old SMOKE manual (e.g. v2.7) to set it up?
Hi Farren,
Great question! Well, as of SMOKE v3.0, we have decided not to support any fixed format input files due to the comparability with EPA’s EMF (Emissions Modeling Framwork). EMF is based on SQL database which prefers flat file formats. However, any version of SMOKE can still process that EMS-95 formats. Haven’t been tested for a while so you may run into an issue or two while processing EMS-95 with the latest version of SMOKE like v4.5 or v4.6 (coming out this week).
Since there are still many users using this EMS-95 format for precomputed fire inventory, I will put the EMS-95 manual section back into PTHOUR section in Chapter 8.
Please note that this EMS-95 is the only fixed format still supported in the latest version of SMOKE. Any IDA annual inventory format is no longer supported as of SMOKE v3.0. If you have an IDA annual inventory for this EMS-95 fire inventory, unfortunately you should go back to SMOKE v2.7.
Please give a run of EMS-95 (PTOP, PBOT, LAY1F) with the latest SMOKE v4.5 and let me know how it goes.
Best,
BH Baek
Hi BH,
I’ve been trying to test the hourly fire emissions format but having trouble since it isn’t clear to me which settings need to be switched on. I am using SMOKE-Ready files from BlueSky (with pthour.ems95 and ptinv.ida) After those files are read in successfully, I am getting the warning from smkinven:
WARNING: Skipping pollutant "PTOP" at line 6 - not in annual inventory.
WARNING: Skipping pollutant "PBOT" at line 7 - not in annual inventory.
WARNING: Skipping pollutant "LAY1F" at line 8 - not in annual inventory.
but if I switch the option IMPORT_AVEINV_YN to “N”, then smkinven stops almost immediately and says it can’t find the PNTS file. Is it necessary to provide annual averages of PTOP, PBOT, and LAY1F for smkinven to run properly?
Currently the related switch configuration I have is:
For SmkInven>
setenv FILL_ANNUAL Y
setenv HOURLY_TO_DAILY N
setenv HOURLY_TO_PROFILE N
setenv IMPORT_AVEINV_YN Y
For Laypoint>
setenv EXPLICIT_PLUMES_YN Y
setenv FIRE_PLUME_YN Y
setenv HOUR_PLUMEDATA_YN Y
setenv HOURLY_FIRE_YN N
Multiple Program Controls>
setenv DAY_SPECIFIC_YN N
setenv EXPLICIT_PLUME_YN N
setenv HOUR_SPECIFIC_YN Y
setenv SMK_PING_METHOD 0
Any ideas or help you can provide would be greatly appreciated.
Thank you,
-Farren
Hi Farron,
You need to add those PTOP, PBOT, and LAY1F into the INVTABLE input file and make sure you keep them for your processing.
https://www.cmascenter.org/smoke/documentation/4.6/html/ch08s10s04.html
BH
I already had those in the INVTABLE. However, the BlueSky generated ida file does not have PTOP, PBOT, and LAY1F listed in the DATA portion of the header. Putting those values in the header allowed smkinven to process the variables. I also modified the switches as follows:
For SmkInven>
setenv FILL_ANNUAL N
For Laypoint>
setenv EXPLICIT_PLUMES_YN N
setenv FIRE_PLUME_YN N
Multiple Program Controls>
setenv EXPLICIT_PLUME_YN Y
setenv SMK_AVEDAY_YN N
When testing this setup, there were errors from laypoint complaining that LAY1F cannot be zero. I changed all the zero LAY1F values to 0.0001. Then laypoint complains that PTOP cannot be lower than PBOT. I think this is from instances when PTOP = PBOT because after removing them, laypoint is successful. So, I was able to generate a final emissions file and it appers that the hourly plume information is being used. The BlueSky generated file has “GMT” in the date/time stamp so I had to change this to my local time zone for emissions to go in the proper hour. But now I think it is all working properly!
I wanted to add a couple more details here, regarding this effort.
- BH has confirmed that the units for PTOP and PBOT should be meters (and noted accordingly in the INVTABLE).
- Updating the time zone is not necessary (SMOKE can handle either GMT or local time)
- BH has noted that the format for the fire EMS-95 file is not discussed in the SMOKE manual because EMS-95 was originally designed for point sources, not fire emissions.
- The files created by BlueSky as “SMOKE-ready output” are in the correct EMS-95 format.
Thanks for recording this. Farren!
Hello,
So, I have attempted to do something very similar with precomputed plume rise in smoke using PTHOUR and PTINV. Based on the Manual and Smoke version 4.7 I have ran into some issues with getting it to work. I have some questions regarding this thread and what I have found in the manual.
-
It is unclear to me if IDA formats is supported and accepted for PTINV file? Some places I found that it is not and other, such as the manual, seem to suggest that it is still listed as an option? is this true for 4.7 or later?
-
It is not clear to me how exactly to set up the INVTABLE for the variable additions for PTOP, PBOT, and LAY1F? I assumed its similar to how one would set up ACRESBURNED and FUEL_LOAD etc etc for a normal fires run?
My INVTABLE:
- My PTHOUR file is in EMS-95 format and includes: Variables
CO, LAY1F, NH3,NOX,PBOT,PM10,PM2_5,PTOP,SO2,VOC. following the documentation. But I found no clear indication on PTHOUR file or header file outside of #EMS-95 or #CEM needs to be at the top? and that inside the LIST file there should be #LIST EMS-95 or #LIST CEM at the top?
Doing this produced the error:
SMKINV LOG OUTFILE
Value for SMKINVEN_MONTH not defined; returning default: 0
Processing Annual inventory…
Reading inventory sources…
Value for SMK_MAXWARNING: 100
Value for SMK_TMPDIR: ‘/storage/jwilk363/SMOKE/4.7/data/run_cafire17/static/tmp’
Value for SMK_TMPDIR: ‘/storage/jwilk363/SMOKE/4.7/data/run_cafire17/static/tmp’
ERROR: Could not determine inventory file format due to missing or bad header information.
Valid headers are:
#LIST, #EMS-95, #FF10, #MEDS, #GRID,#ORL, or #CEM
*** ERROR ABORT in subroutine GETFORMT
- Running it with #EMS-95 for both PTINV and PTHOUR leads to the error:
SMKINV LOG OUTFILE
Value for SMKINVEN_MONTH not defined; returning default: 0
Processing Annual inventory....
Reading inventory sources...
Value for SMK_MAXWARNING: 100
Value for SMK_TMPDIR: '/storage/jwilk363/SMOKE/4.7/data/run_cafire17/static/tmp'
Value for SMK_TMPDIR: '/storage/jwilk363/SMOKE/4.7/data/run_cafire17/static/tmp'
*** ERROR ABORT in subroutine RDINVSRCS
Routine rdinvsrc.f not expecting to read file of format code 1
(*not quite sure what that error means)
I used these two as references for setting it up:
But I could have made a mistake? I will attach a screen shot of my PTINV and PTHOUR files with header and few data points visible:
and like suggested I made the changes to the run script for SMKINVEN:
setenv FILL_ANNUAL N
For Laypoint>
setenv EXPLICIT_PLUMES_YN N
setenv FIRE_PLUME_YN N
Multiple Program Controls>
setenv EXPLICIT_PLUME_YN Y
setenv SMK_AVEDAY_YN N
@jwilk363. Check out the response on Mar 19 which answers some of your questions.
-
IDA format is no longer supported as of SMOKE v4.0. I would suggest for you either to use an older version of SMOKE (v3.7 or earlier) or convert your IDA formatted inventory into FF10 point format.
-
Yes, you can follow the ACRESBUREND and other non-pollutant settings for PTOP, PBOT and LAY1F.
-
SMOKE v4.0 or later still support EMS-95 formats and requires the header #EMS-95 in the top of your hourly inventory file. Also, you need to add #LIST EMS-95 into your PHOUR list input file.
@bbaek . Thanks for the response,
-
I found some success with a single fire using the ORL FIRE PTINV format. Is it recommended to convert to the FF10 instead?
-
Thanks, the INVTABLE portion works.
-
EMS-95 format worked for PTHOUR.
#ORL FIRE format is specifically designed for HFLUX and ACRESBURNED values to compute plume top and bottom layers. There are a few conditions implemented to process them correctly. For that reasons, I would strongly recommend you to use the FF10 format instead.
Hey BH,
I have now converted back to version 3.5.1. I believe that I have mostly everything set up correctly. I am running SMOKE 3.5.1 on a 4km domain for Northern California with met files starting at 7. The current issue seems to be that SMOKE is not getting the emissions to be allocated properly into the output file. I am sure there is an error somewhere that I am missing, but none of the log files have any obvious errors, nor do they print any error message. I was hopeful to get some guidance on how best to debug the issues. I will attach some log files here.
[ASSIGNS.airpact.cafire.txt|attachment](uploasmk_point_catest.v1.csh (11.1 KB) temporal.point.cafire.20171003.txt (32.8 KB) laypoint.point.cafire.20171003.us4-ca.txt (17.8 KB) grdmat.point.cafire.us4-ca.txt (13.4 KB) spcmat.point.cafire.cmaq_ecy.txt (21.4 KB) smkmerge.point.cafire.20171003.us4-ca.txt (81.9 KB) smkinven.point.cafire.txt (26.2 KB) d://jNy3AY0XbMESifbkk53w8fFnbDH.txt) (10.4 KB)
Joe, just curious why you would need to run a version of SMOKE as old as 3.5.1?
Hey Alison,
The reason a previous (much older) version of SMOKE is used is because certain input files such as the IDA format are no longer supported, which are what I currently have to work with. Further, running SMOKE with precomputed plume rise in the newer version does not appear to be supported either (I attempted with version 4.7). I am open to ideas from anyone who has had any luck with precomputed plume rise in SMOKE. Particularly seeking to understand what they are doing or have done that was successful.
Joe, as you saw in previous posting between Farren and me, you can process PTOP, PBOT, LAY1B through newer version of SMOKE later than v4.0. You just need to convert your PTINV into FF10 format. Once you successfully process PTINV (FF10) and PTHOUR (EMS-95) to generate PHOUR output file from Smkinven, you need to process it through Laypoint with both flags set to Y (not 100% sure). Once EXPLICIT_PLUMES_YN is set to Y, it will automatically set FIRE_PLUME_YN to Y as well. So as long as you set EXPLICIT_PLUMES_YN to Y, Laypoint should process PHOUR with PBOT, PTOP, and LA1B variables to allocate the emissions into your model layers correctly.
setenv EXPLICIT_PLUMES_YN Y
setenv FIRE_PLUME_YN Y
I just checked your Laypoint program log file and looks like you only set FIRE_PLUME_YN to Y but did not set EXPLICIT_PLUMES_YN to Y. Have you already tried this combination?
Also, I am not quite sure what kind of issue you are having. Are you saying the vertical allocations is done incorrectly? Can you clarify the issue you are currently having?
I have tried this combination before, but I was under the impression that for precomputed plume rise FIRE_PLUME_YN should be set to N as we are not using acres burned and heat flux. The top and bottom are already there? Further we don’t have hourly heat flux from the PTMP file and daily area burned from PTDAY file. Or does that only apply to the HOURLY_FIRE_YN option? I have that set as N.
e.g., the choices related to this issue??
setenv EXPLICIT_PLUMES_YN Y
setenv HOUR_PLUMEDATA_YN Y
setenv FIRE_PLUME_YN Y
setenv HOUR_SPECIFIC_YN Y
Switching on the options you mentioned, results in SMOKE looking for the PLAY_EX file and something about an error with the G_GRIDPATH where the explicit plume rise requires vertical type “ it found -9999” and points you to look at the EMCNST3.EXT file for correct variable names possibilities. It is not clear to me what that means or what it is looking for or where to set that.
Do we need to provide fake variables for STKTK, STKVE, and STKFL?
I did not see anything else in that subroutine mentioning vertical type?
What are vertical types and where does one specify them?
I referred to the Hour-specific or day-specific data (including precomputed plume-rise data) covered in Section 4.4.2.5, “Day-specific and hour-specific point and fire inventories” [132].
I think this is where things are breaking down?? Manual 4.7 2.15.2.3. Using Smkmerge “If EXPLICIT_PLUMES_YN is also set to Y, Smkmerge will read the PLAY_EX file for the explicit plume sources. related to creating possible fake files and sources?
Running with EXPLICT_PLUMES_YN N creates zero emissions output files in the what appears to be the wrong location. So there maybe other issues?
For version 4.7, I kept running into random errors, but as you mentioned it was due to data type IDA and EMS95. I tired to convert to FF10 format, but that did not help, maybe I was off in my attempts, are there examples or guidance for precomputed plume rise for creating PTINV and PTHOUR files? It is not clear to me if I am to add each individual POLID for each pollutant, into the PTINV files and PTHOUR, that I want to keep? Or just one entry per source? Do I need to create a fake PTDAY file as well for this format? What about the annual emissions, does the mean WRITE_ANN_ZERO should be set to Y?
Slight update:
Looking at what Farren did and trying different switches this is the combination that ran relatively cleanly.
For SmkInven>
setenv FILL_ANNUAL N
For Laypoint>
setenv EXPLICIT_PLUMES_YN N
setenv FIRE_PLUME_YN N
HOUR_PLUMEDATA_YN Y
Multiple Program Controls>
setenv EXPLICIT_PLUME_YN Y
setenv HOUR_SPECIFIC_YN Y
setenv SMK_AVEDAY_YN N
I would still like to get answers to the questions above for future references if possible. But, at the moment the run completed… However, It was discovered in the output the reason why I thought this combination didn’t work previously. The output is placed at the top of the model layers 25,26,27, which shouldn’t be the case as those represent heights 8000 m up to 20 km which in our input files the highest PTOP is around 2.6k on average. which should be layer 22 or so. Also, the LAY1F must not have worked properly as there are no emissions at the surface, where inside our files there’s some places where the value is set to 0.3, and not the default 0.0001.
Joe, So you are still seeing the incorrect vertical allocation from your PTOP, PBOT and LAY1F? Still seeing the emissions from layer 25~27? Or now you can process them correctly and allocating the emissions into layers correctly as they are expected?
BH, yes, I am still seeing incorrect vertical allocation from the PTOP, PBOT, and LAY1F in layer 25~27. Could you please provide some guidence on how to trouble shoot this.
