# HAPs modelling for platform 2022 v2 **URL:** \ **Category:** NEI Modeling Platform\ **Created:** [May 24, 2026, 11:03am UTC](https://forum.cmascenter.org/t/haps-modelling-for-platform-2022-v2/6205 "2026-05-24T11:03:45Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Mark1](https://avatars.discourse-cdn.com/v4/letter/m/e0b2c6/32.png) [@Mark1](https://forum.cmascenter.org/u/Mark1)\ **Post date:** [May 24, 2026, 11:03am UTC](https://forum.cmascenter.org/t/haps-modelling-for-platform-2022-v2/6205/1 "2026-05-24T11:03:46Z")
Hi everyone, I am working with the 2022 v2 modeling platform and need to generate integrated HAP-CAP emissions (similar to the EPA’s pre-processed modeling files) for specific activities at the SCC level (e.g., on-road, EGU, and oil and gas). However, I noticed the platform’s ge\_dat directory does not include the necessary files (such as INVTABLE and GSPRO files). Are those files publicly available elsewhere, or can they be shared? Alternatively, should I try to modify the existing CAP files by adding the hazardous pollutants? Thanks in advance for your help. ---
**Author:** ![karlseltzer](https://avatars.discourse-cdn.com/v4/letter/k/90ced4/32.png) [@karlseltzer](https://forum.cmascenter.org/u/karlseltzer)\ **Post date:** [May 28, 2026, 2:08pm UTC](https://forum.cmascenter.org/t/haps-modelling-for-platform-2022-v2/6205/2 "2026-05-28T14:08:35Z")
Hi, I updated the ftp site to include the necessary ancillary files: > **[Index of /Air/emismod/2022/v2/ancillary\_data](https://gaftp.epa.gov/Air/emismod/2022/v2/ancillary_data/)** See the for\_HAPs\_ge\_dat\* files. Note the info\_additional\_files\_for\_HAP\_processing.txt file in the zip. This includes instructions on what to change in the baseline run scripts. ---
**Author:** ![Mark1](https://avatars.discourse-cdn.com/v4/letter/m/e0b2c6/32.png) [@Mark1](https://forum.cmascenter.org/u/Mark1)\ **Post date:** [May 28, 2026, 4:02pm UTC](https://forum.cmascenter.org/t/haps-modelling-for-platform-2022-v2/6205/3 "2026-05-28T16:02:21Z")
Thanks Karl, this is extremely helpful. ---
**Author:** ![Mark1](https://avatars.discourse-cdn.com/v4/letter/m/e0b2c6/32.png) [@Mark1](https://forum.cmascenter.org/u/Mark1)\ **Post date:** [June 11, 2026, 7:13am UTC](https://forum.cmascenter.org/t/haps-modelling-for-platform-2022-v2/6205/4 "2026-06-11T07:13:08Z")
Karl I was wondering about the amount of memory used to run the HAPCAP onroad RPD subsector (RPHO, RPH, RPS, and RPV seems to run fine so far). Movesmrg seems to fail without an explicit error once it is done reading the EFTABLES right after “Value for SMK\_REPORT\_TIME not defined; returning default: 230000”. I tried increasing the memory up to 300gb and I set the environmental variable “IOAPI\_OFFSET\_64” to yes; However, it still failed. Thanks in advance for your help. ---
**Author:** ![karlseltzer](https://avatars.discourse-cdn.com/v4/letter/k/90ced4/32.png) [@karlseltzer](https://forum.cmascenter.org/u/karlseltzer)\ **Post date:** [June 11, 2026, 1:14pm UTC](https://forum.cmascenter.org/t/haps-modelling-for-platform-2022-v2/6205/5 "2026-06-11T13:14:38Z")
At EPA, SMOKE-MOVES for a HAP/CAP setup can be run with 64gb memory. Based on where your log stops, perhaps it is related to the Movesmrg county-SCC report. Sometimes we’ve seen issues with other sectors where an overflow with the report causes a segmentation fault, either based on a too-high value (like with HFLUX in fire sectors) or too many species (which we’ve seen with CRACMM). I don’t know that we’ve run across that with SMOKE-MOVES though. ---
**Author:** ![Mark1](https://avatars.discourse-cdn.com/v4/letter/m/e0b2c6/32.png) [@Mark1](https://forum.cmascenter.org/u/Mark1)\ **Post date:** [June 12, 2026, 7:27am UTC](https://forum.cmascenter.org/t/haps-modelling-for-platform-2022-v2/6205/6 "2026-06-12T07:27:09Z")
Thanks Karl. Through trial and error, I figured out that the problem seems to be caused when two counties are included: Harris County, TX (Houston) and Maricopa County, AZ (Phoenix). Both counties have significant VMT values, so it might be similar to the high HFLUX from FINN that you mentioned. I will let you know if I figure out the exact bug.