Is there is a limit on the number of point sources in SMOKE?

SMOKE Emissions Inventory
1

I used SMOKE4.7 and adjusted the coordinate system with m3edhdr. Then I found that the number of point sources would limit the generation of point source manifest files. For example, I use 113 point source parameter files, can successfully generate a point source listing file. But I used 900 point source parameter files, it could not be generated, and an error occurred, as follows:

 File "GRIDDESC" opened for input on unit:  94
 /home/pbwang/models_inst2/smoke_local/data/ge_dat/lanzhou/GRIDDESC_9km

 Value for IOAPI_ISPH:  '20'
 Value for IOAPI_ISPH:  '20'
 INITSPHERES:  input sphere Normal Sphere (MM5 / WRF-ARW) R=6370000
 Reading elevated source configuration file...
 Assigning stack groups...
 Value for SMK_MAXWARNING:  100
 NOTE: No stack groups assigned.
 NOTE: Getting date/time information only for use in STACK_PING file
 Value for G_STDATE:  2019363
 Value for G_STTIME:  0
 Value for G_TSTEP:  10000
 Value for PROMPTFLAG:  N returning FALSE
 Using default value   2019363  for query:
 "Enter simulation starting date (YYYYDDD)|(YYYYMMDD)"
 Using date  2019363
 Using default value         0  for query:
 "Enter simulation starting time (HHMMSS)"
       Start Date: Dec. 29, 2019
       Start Time: 000000 HHMMSS
 Value for IOAPI_GRIDNAME_1:  'CN9NC_342X204'
 Value for IOAPI_GRIDNAME_1:  'CN9NC_342X204'
 INTERNAL ERROR: Expected number of groups was       1  but actual number was       0

 *** ERROR ABORT in subroutine ELEVPOINT

So, I have to split up these 900 point sources and generate point source files separately?

2

900 sources should not be a problem; I suspect the trouble is elsewhere.

If you have enough sources that array-sizes would exceed 2 GB (which is much more than 900 sources), then you need to compile for “medium memory model” – BIN types Linux2_x86_64pg_medium, Linux2_x86_64ifort_medium, Linux2_x86_64gfort_medium, Linux2_x86_64gfort10_medium: see https://cjcoats.github.io/ioapi/AVAIL.html#medium

3

Thank you for your reply, cjcoats. Should I recompile the hole “SMOKE” program? And shoud I need to recompile “CMAQ5.3”, to become “medium memory model” too?

4

There could be some other issues contributing to this.

Can you please provide the Smkinven and Elevpoint logs, and the PELVCONFIG you are using?

5

PELVCONFIG：
/SPECIFY ELEV GROUPS/
HT +/- 3.0 AND DM +/- 1.0 AND TK +/- 1.0
VE < 10.0
/END/
/SPECIFY ELEV/
RISE => 38.
/END/

Does proper grouping help to make the pollution point source file smaller？
Sorry, there were errors uploading elevpoint and smkinven logs.

6

elevpoint.point.log.txt (16.9 KB)
smkinven.point.log.txt (24.0 KB)
pelvconfig.txt (2.7 KB)
I change a network, and I can upload now.
After several point sources, I found that the size of the point source file actually depends on the grid size and the size of the met file, and has little to do with the point source itself. My grid is 342X204. Is that right?

7

Thank you for providing these files.

If you are running stationary point sources (i.e. not fires) for inline processing in CMAQ, then we have two suggestions:

  • Set SMK_ELEV_METHOD to 2 (currently 1)

  • Try using the EPA PELVCONFIG (pelvconfig_elevate_everything_17apr2020_v0.txt) from here

https://gaftp.epa.gov/air/emismod/2020/ancillary_data/other_ge_dat_2020ha2_22sep2023.zip

Although we are confused by the fact that the error that you originally posted was from Elevpoint, but the Elevpoint log that you forwarded was error-free.

If the above suggestions don’t help, then please confirm whether you are running fires or not-fires, and if your goal is to produce inline point source emissions or 3-D layered emissions in SMOKE. It also looks like you are using a pretty old set of data and scripts and a custom inventory.

There are updated scripts available on the EPA FTP for recent emissions modeling platforms such as the 2020 platform:

https://www.epa.gov/air-emissions-modeling/2020-emissions-modeling-platform

8

Thank you for your advices. I tried and find the point source become smaller frome 170G to 11G. Here I have a few questions to ask again:

  1. My point stream is a fixed point source, not a wildfire. Do I need to calculate in a grouping stack? The non-3D point sources do not need MET files.
  2. In-line Plume Rise Calculation, HT => 0. What does that mean?
  3. My point source chimney heights are between 15-210m. Do they apply the advice you provided?
    4.Can the point source in the obtained file， which follow your advice, basically have the emission effect of the point source?
    Due to errors, I tried to reduce the number of point sources to below 700 and it worked. I uploaded the log file after success.
    I’m running not-fires, and need inline point source emissions.
    I use the SMOKE 4.7. Thank you for recommending the new platform, I will try it later.
9

I find there are no stack_groups files and inlnts files. So how to set the “In-line point emissions” in cctm?

10

Some answers that might help:

  1. Our standard is to not apply any stack groupings in the PELVCONFIG file, since this results in a better match when running inline plume rise in CMAQ compared to running plume rise in SMOKE via Laypoint.

  2. HT >= 0 (height) is our way of instructing SMOKE (or CMAQ if running inline) to calculate plume rise for all sources in the inventory. Combined with other settings (see below), this will tell SMOKE to include all point sources in the INLN file, and to not include any sources in the 2-D gridded file. However you do not need necessarily need to process point sources this way if you prefer to have sources in a low level gridded file. We do this to make answers more consistent if we need to do source apportionment or other analyses.

  3. All sources in your inventory will be affected, as long as the settings are right.

Is your question: will the SMOKE output emissions behave like point sources when they are input to CMAQ? The answer is yes, if they are output to INLN files.

When you say “the point source become smaller”, do you mean the gridded file that comes out of Smkmerge, or something else?

Maybe the 170G file was layered and the 11G file is single layer?

If you didn’t get an INLN file at all, maybe that is it.

You may need to adjust some script settings to get an INLN file instead of a gridded file, so seeing the script and logs will help.

If you are still having issues please provide your run script, the standard output, and all of your SMOKE logs.

11

Thanks a lot. I tried the 3d point files and it worked.