# Non-Additive Emission Impacts When Using Zero-Out Method for SNAP Source Apportionment in SMOKE

**URL:** <https://forum.cmascenter.org/t/non-additive-emission-impacts-when-using-zero-out-method-for-snap-source-apportionment-in-smoke/6156>\
**Category:** SMOKE\
**Created:** [March 3, 2026, 12:54pm UTC](https://forum.cmascenter.org/t/non-additive-emission-impacts-when-using-zero-out-method-for-snap-source-apportionment-in-smoke/6156 "2026-03-03T12:54:30Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![nek](https://avatars.discourse-cdn.com/v4/letter/n/47e85d/32.png) [@nek](https://forum.cmascenter.org/u/nek)\
**Post date:** [March 3, 2026, 12:54pm UTC](https://forum.cmascenter.org/t/non-additive-emission-impacts-when-using-zero-out-method-for-snap-source-apportionment-in-smoke/6156/1 "2026-03-03T12:54:30Z")

</div>

Hello SMOKE community,

I’m conducting source apportionment using SMOKE v4.8 for 13 SNAP emission sectors by running the zero-out method (BASE scenario plus 13 scenarios with each SNAP category zeroed via removing one category at a time) for each month of 2019. In my post processing, I’m getting non-additive results where the sum of individual SNAP contributions doesn’t equal the BASE scenario, and I’m seeking guidance on whether this is expected behavior.  
Setup:

SMOKE v4.8, area sources, European domain  
13 SNAP categories (energy, industry, transport, agriculture, etc.)  
Year 2019, monthly SMOKE runs  
Zero-out method: One SNAP category is not taken into consideration for each run, by removing its txt file from arinv.area.lst inside area inventory folder.

For post-processing, I computed total annual emissions per pollutant and per scenario by summing all hourly emission values over all grid cells and over all timesteps from the SMOKE EGTS output files. Specifically:  
For each scenario (BASE and each zero-SNAP run), for each pollutant, I read all .ncf files, summed emissions over all time steps and spatial grid cells, without any averaging or normalization. The resulting value represents the total annual emission mass over the full modeling domain. Sectoral impacts were computed as:  
ImpactSNAPi=BASE−zeroSNAPi. Then, I evaluated additivity by comparing:  
∑ImpactSNAPi vs BASE.

| | **PMFINE** | **PMC** | **PM10** | **NO** | **NO2** | **SO2** | **NH3** | **CO** | **NOx** |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| IMPACTSUM | 620327566 | 351324279 | 971650572 | 48463517 | 47688032.5 | 39428038.75 | 102982685.5 | 373153510 | 96151520.5 |
| BASE-IMPACTSUM | 2584338 | 1943727 | 4529336 | 1797991.5 | 66881.25 | 88870.75 | 29080.5 | 16767804 | 1864914 |
| relative residual % | 0.00415 | 0.00550 | 0.00464 | 0.03577 | 0.00140 | 0.00225 | 0.00028 | 0.04300 | 0.01903 |

Small residual differences (\<5%) were observed, so I am trying to understand the reasons. A colleague supports that successfully used this method some years ago with perfect additivity, so I’m concerned something is wrong with my approach. Does SMOKE distribute emissions, renormalize temporal splits, apply speciation or vertical allocation? When one sector is removed, can temporal redistribution slightly shift how other emissions are written due to floating point ordering, accumulation and minor nonlinearities and introduce small deviations? Is there available documentation on what normalization is performed (if it does) or whether it could cause the remaining non-zeroed profiles to be redistributed differently when one category is removed?

Thank you for any insights!

---

<div class="post-metadata">

**Author:** ![james.beidler](https://avatars.discourse-cdn.com/v4/letter/j/6f9a4e/32.png) [@james.beidler](https://forum.cmascenter.org/u/james.beidler)\
**Post date:** [March 3, 2026, 1:58pm UTC](https://forum.cmascenter.org/t/non-additive-emission-impacts-when-using-zero-out-method-for-snap-source-apportionment-in-smoke/6156/2 "2026-03-03T13:58:30Z")

</div>

Hi,

Depending on the temporal profile type it is common to see aggregate differences less than 5%, particularly when using a representative day approach. Do you have an example temporal profile that you can share?

SMOKE, by default, renormalizes temporal profiles ( [4.17.3.&nbsp;Files and Environment Variables](https://www.cmascenter.org/smoke/documentation/5.0/html/ch04s17s03.html) ). This can be turned off by setting the environment variable RENORM\_TPROF to “N”.

---

<div class="post-metadata">

**Author:** ![nek](https://avatars.discourse-cdn.com/v4/letter/n/47e85d/32.png) [@nek](https://forum.cmascenter.org/u/nek)\
**Post date:** [March 3, 2026, 5:32pm UTC](https://forum.cmascenter.org/t/non-additive-emission-impacts-when-using-zero-out-method-for-snap-source-apportionment-in-smoke/6156/3 "2026-03-03T17:32:47Z")

</div>

Hello,

Thank you for the reply,

I am using standard monthly, weekly, and hourly temporal profiles (APTPRO files) and my ASSIGNS files do not have the variable RENORM\_TPROF.

[amptpro\_weekly.csv](https://forum.cmascenter.org/uploads/short-url/geFrorQHFKMWlTag03gWgdZZagP.csv) (1006 Bytes)

[amptpro\_hourly.csv](https://forum.cmascenter.org/uploads/short-url/9jPRxfTEreV0DgNs0A48O1u5ahh.csv) (2.4 KB)

[amptpro\_monthly.csv](https://forum.cmascenter.org/uploads/short-url/9CEiLt23d1lm58cWw25NRYi86qW.csv) (1.3 KB)

---

<div class="post-metadata">

**Author:** ![james.beidler](https://avatars.discourse-cdn.com/v4/letter/j/6f9a4e/32.png) [@james.beidler](https://forum.cmascenter.org/u/james.beidler)\
**Post date:** [March 4, 2026, 4:31pm UTC](https://forum.cmascenter.org/t/non-additive-emission-impacts-when-using-zero-out-method-for-snap-source-apportionment-in-smoke/6156/4 "2026-03-04T16:31:44Z")

</div>

Thanks, these profiles appear to already sum to 1 so the renormalization setting would not make any difference whether on or off.

The type of temporal profiles that you are using typically map to representative days, or a day of emissions that represents all other of the same day of week in the month. When applying the representative day approach aggregation back from daily to annual can result in differences up to 0.5% because the number of days of each type is not the same for each month. This, however does not completely explain the differences for CO and NO.

Just to verify, when you are adding the emissions from the netCDFs are you only including the first 24 hours from each file?

---

<div class="post-metadata">

**Author:** ![nek](https://avatars.discourse-cdn.com/v4/letter/n/47e85d/32.png) [@nek](https://forum.cmascenter.org/u/nek)\
**Post date:** [March 5, 2026, 10:47am UTC](https://forum.cmascenter.org/t/non-additive-emission-impacts-when-using-zero-out-method-for-snap-source-apportionment-in-smoke/6156/5 "2026-03-05T10:47:21Z")

</div>

Thanks for checking.

In my post-processing, I sum all emissions across the entire domain and across all timesteps in the NetCDF files. For each file I read the pollutant variable and compute the total using `np.nansum`, which sums across all dimensions (time and grid cells). I then accumulate this over all files in the scenario directory. The files start at 01:00 of the first day of the month and extend until 00:00 of the first day of the following month (For example: January: 2019-01-01 01:00 → 2019-02-01 00:00, February: 2019-02-01 01:00 → 2019-03-01 00:00). Therefore each monthly file contains all hours of the month plus one additional hour from the next month, without duplication of timestamps. So the aggregation includes the entire temporal coverage of each file rather than only the first 24 hours.

---

<div class="post-metadata">

**Author:** ![nek](https://avatars.discourse-cdn.com/v4/letter/n/47e85d/32.png) [@nek](https://forum.cmascenter.org/u/nek)\
**Post date:** [March 11, 2026, 12:15am UTC](https://forum.cmascenter.org/t/non-additive-emission-impacts-when-using-zero-out-method-for-snap-source-apportionment-in-smoke/6156/6 "2026-03-11T00:15:36Z")

</div>

Hello,

After rerunning all scenarios - including BASE- using RENORM\_TPROF to N, my final post processing results are:

| | **PMFINE** | **PMC** | **PM10** | **NO** | **NO2** | **SO2** | **NH3** | **CO** | **NOx** |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| IMPACTSUM | 622910814 | 353255638 | 976162036 | 48524077 | 47747734 | 39516680 | 103010630 | 375276354 | 96271418 |
| BASE-IMPACTSUM | -3034 | -494 | 716 | 1730007.5 | -116.25 | 40 | 369.999999776483 | 14572734 | 1730259 |
| relative residual % | -4.87143543309241E-06 | -1.39934083341873E-06 | 7.3372857283021E-07 | 0.034673156584945 | -2.45284125209306E-06 | 1.01326362079622E-06 | 3.59202027624075E-06 | 0.037514716615176 | 0.017784783408187 |

So, now, SO2 and NH3 are now additive to machine precision. However, NO and CO still show ~3–4% residuals. Does it suggest that the non-additivity originates from representative-day temporal allocation rather than temporal renormalization or post-processing aggregation? Can this be due to that CO and NO are emitted strongly by multiple dominant sectors, and when those sectors use representative-day temporal allocation, non-additivity becomes much more visible? Is it an expected SMOKE behavior?

---

<div class="post-metadata">

**Author:** ![james.beidler](https://avatars.discourse-cdn.com/v4/letter/j/6f9a4e/32.png) [@james.beidler](https://forum.cmascenter.org/u/james.beidler)\
**Post date:** [April 6, 2026, 1:30pm UTC](https://forum.cmascenter.org/t/non-additive-emission-impacts-when-using-zero-out-method-for-snap-source-apportionment-in-smoke/6156/7 "2026-04-06T13:30:36Z")

</div>

As noted the residual being higher than 0.5% is abnormal given known differences that occur from the representative day approach in SMOKE. Given that a non-speciated pollutant, CO, is having this issue in addition to NOx I still lean towards an aggregation issue with a high magnitude CO+NOx sector (e.g. mobile sources) that uses a representative-day approach. Another potential source is the spatial allocation.

Have you tried looking at smkreport ([5.4.&nbsp;Reports Created by Smkreport](https://www.cmascenter.org/smoke/documentation/5.0/html/ch05s04.html)) output after smkinven, after smkinven+temporal, and after smkinven+gridding? This may help you pinpoint the source of the discrepency.