FINN fire emission process

Hello CMAQ community,
I am trying to figure out using FINN fire emission with my CMAQ modeling over CONUS but I have no clues how SMOKE could process the FINN.
Any comments are highly appreciated!
Could you please find a free moment to reply to me?
@wyat.appel
@bbaek

You need to process FINN fire emissions and convert them into SMOKE-ready FF10 formats. I do believe there are scripts that could assist you to covert them into these FF10 formatted files. @eyth.alison probably can assist you on that.
Point annual FF10 file and Point daily FF10 file

I have also tinkered with FINN for CMAQ in the past to create a non-SMOKE system. The goal was to create a simple pathway to go from publicly available data to make CMAQ-ready emissions. I call it finn2cmaq[1]. It is probably not as good as the SMOKE approach, but it might be useful for users without SMOKE because it is a quick method that can be run in the cloud. To date, I have primarily used the 2D data as an alternative data source for comparison. There is no warranty expressed or implied…

An example Jupyter Notebook that applies the system is available in the github project. Look in the examples folder. Right now, the PM speciation is a little simplistic. The EC, OC, SO4 and NO3 are explicit, but all the rest is in PMOTHR. This could certainly be improved, and should be QA’d during any application…

[1] GitHub - barronh/finn2cmaq: Fire emission pre-processor for CMAQ.

6 Likes

Thanks so much for providing this and it is super helpful. May I ask whether there are any species mapping for GEOS-Chem to SAPRC mechanism? Because I find that currently, it supports the CB mechanism.
Thanks again!

The finn2cmaq processor uses the GEOS-Chem speciated inputs by default, but it is mechanism agnostic. You could instead use the SAPRC99 speciated inputs. You’d just have to replace the speciation converter file used by the daily2hourly3d.py script. By default, it uses the aux/gc12_to_cb6r3_ae7.txt file. Assuming you want to speciate for SAPRC07TC with AE6, you would basically create a similar file aux/saprc99_to_saprc07tc_ae6.txt where the species names match the names used by CMAQ.[1,2]

If you do, please make an issue on the github issue site and share your script. I’ll include it in the distribution.

[1] CMAQ/saprc07tc_ae6_aq_species_table.md at master · USEPA/CMAQ · GitHub
[2] CMAQ/saprc07tc_ae6_aq_species_table_aerosol.md at master · USEPA/CMAQ · GitHub

Thanks for your quick reply! Sure, I would like to write the txt file with SAPRC07TC with AE6 (it is also the mechanism which we currently used.)
I will post the issue on GitHub when I finish.

hi barronh
An error occurred when I used your method.

This is a domain I set up myself
(base) [/data2/sunzhixu/CMAQv5.3.2/PREP/finn/finn2cmaq-master/scripts]$ python3 txt2daily.py …/aux/GRIDDESC CN36KM 2018 FINNv1.5_2018.GEOSCHEM.tar.gz /data4/sunzhixu/outdata/emis/finn/mid/FINNv1.5_2018.GEOSCHEM.nc
**PNC:/data/home/sunzhixu/.local/lib/python3.8/site-packages/PseudoNetCDF/pncwarn.py:24:UserWarning:
SDATE was -635; using 1970001
Traceback (most recent call last):
File “txt2daily.py”, line 118, in
gf = pnc.pncopen(args.GRIDDESC, format=‘griddesc’, GDNAM=args.GDNAM)
File “/data/home/sunzhixu/.local/lib/python3.8/site-packages/PseudoNetCDF/_getreader.py”, line 153, in pncopen
outfile = reader(*args, **kwds)
File “/data/home/sunzhixu/.local/lib/python3.8/site-packages/PseudoNetCDF/cmaqfiles/_griddesc.py”, line 132, in init
self.setgrid(withcf=withcf)
File “/data/home/sunzhixu/.local/lib/python3.8/site-packages/PseudoNetCDF/cmaqfiles/_griddesc.py”, line 185, in setgrid
grd = self._grd[key]
KeyError: ‘CN36KM’

When I use domian in example, it also report an error
(base) [/data2/sunzhixu/CMAQv5.3.2/PREP/finn/finn2cmaq-master/scripts]$ python3 txt2daily.py …/aux/GRIDDESC 108NHEMI2 2018 /data4/sunzhixu/outdata/emis/finn/FINNv1.5_2018.GEOSCHEM.tar.gz /data4/sunzhixu/outdata/emis/finn/mid/FINNv1.5_2018.GEOSCHEM.nc
**PNC:/data/home/sunzhixu/.local/lib/python3.8/site-packages/PseudoNetCDF/pncwarn.py:24:UserWarning:
SDATE was -635; using 1970001
**PNC:/data/home/sunzhixu/.local/lib/python3.8/site-packages/PseudoNetCDF/pncwarn.py:24:UserWarning:
IOAPI_ISPH is assumed to be 6370000.; consistent with WRF
**PNC:/data/home/sunzhixu/.local/lib/python3.8/site-packages/PseudoNetCDF/pncwarn.py:24:UserWarning:
IOAPI_ISPH is assumed to be 6370000.; consistent with WRF
Traceback (most recent call last):
File “txt2daily.py”, line 119, in
outf = process(gf, args)
File “txt2daily.py”, line 102, in process
outf.updatemeta()
File “/data/home/sunzhixu/.local/lib/python3.8/site-packages/PseudoNetCDF/cmaqfiles/_ioapi.py”, line 746, in updatemeta
self.getVarlist(update=True)
File “/data/home/sunzhixu/.local/lib/python3.8/site-packages/PseudoNetCDF/cmaqfiles/_ioapi.py”, line 593, in getVarlist
varliststr_old = getattr(self, ‘VAR-LIST’)
AttributeError: ‘griddesc’ object has no attribute ‘VAR-LIST’

What’s the problem
I look forward to your reply
zhixu

I replied to this in the finn2cmaq issues.

2 Likes

Hi

Sorry to bother you.
Have you finished SAPRC07TC speciated inputs?~~

Hi barronh,

I am using program you coded to process FINN to pre-CMAQ data. But I met some problems. I tried to merged this file with other emis files processed by layalloc program from SMOKE which uses height for layering rather than sigma value. I am wondering can I change way of layering to height rather than sigma with your program code?

yan2024,

Conceptually, layalloc and finn2cmaq both output 3D files on the native layers. It should not matter whether they allocation to layers was based on height, pressure, sigma, or something else. Once the files are on layers, if the structures match, they should be mergable.

I’m not sure, but I would guess that the outputs have different vertical structures which is complicating the merge process. To better understand, I would need at a minimum:

  • the script that is failing,
  • the error from the script,
  • the ncdump -k output from the files that are failing to merge,
  • the ncdump -h output from the files that are failing to merge.

Even better would be for you to post a minimum example where it can be downloaded. A minimum example would include:

  • a script that is failing to merge just two files,
  • the two files that are failing to merge,
  • the error that the script outputs.
1 Like

Hi Barron,

I am also working on this topic. I have two questions regarding the FINN data. If you have also encountered before, I would like to have your suggestions.

  1. The current FINN provides FRP. What is the FRP detection time in the FINN dataset? Since FINN uses both MODIS and VIIRS, which have different overpass times, I’m wondering what a good way would be to estimate detection time for FINN product. Additionally, does the product include nighttime FRP detections in its reported values?

  2. Are the daily total emissions reported in FINN based on local day or UTC day?

Thanks,
Zongrun

The FRP value included in FINN is an average of the FRP associated with a fire for the day, which indicates that the value could include data points from multiple overpass times and instruments. To get the overpass times you will need to pair the source data with the inventory.

The timing information is documented in the FINNv2.5 manuscript (GMD - The Fire Inventory from NCAR version 2.5: an updated global fire emissions model for climate and chemistry applications):
“The active fire products report the time of acquisition in Coordinated Universal Time (UTC). In contrast to previous versions of the model, the FINNv2.5 preprocessor uses local time in the specification of the date of a fire detection in order to facilitate comparisons of emissions estimates with observational data.”

3 Likes

Thanks a lot for your comment. I also asked the same questions to FINN. However, it seems they use the UTC time rather than local time when they create the data. Here is the discussion:

As they also mentioned, the FRP is averaged value from different products.

1 Like

Hi barronh,

Sorry for late reply. After that, I tried to merge all layers from this emisstion file to one layer and use SMOKE to do vertical layer alloc again to meet merging with other files. I think I resolved by this way.