Skip to content

Gas-capture flag gates the site-type default in both trace paths - #68

Open
HughRunyan wants to merge 1 commit into
mainfrom
the-gas-capture-flag-gates-the-default
Open

HughRunyan wants to merge 1 commit into
mainfrom
the-gas-capture-flag-gates-the-default

Conversation

@HughRunyan

Copy link
Copy Markdown
Collaborator

Output

landfill_gas_collection now gates the site-type gas-capture default in both trace paths, not just one. A site with no recorded collection system is modelled at zero capture wherever it lives.

The defect

site_only_estimate_trace and citysite_estimate_trace carried copies of the gas-capture logic and the copies drifted. The citysite copy applied the site-type default (0.60 / 0.45 / 0.0) with no check on the flag, while still reading that same flag to pick ox_cap vs ox_nocap. The resulting Landfill was internally contradictory — constructed with gas_capture=False and gas_capture_efficiency=0.6 on the same object.

The rule it broke is not invented here. Two modules already state it:

  • build_gas_capture_rates.classify_assets — "gccs NaN & lgc True → has a system, efficiency unknown. Emphatically NOT zero"; False → a genuine 0.
  • uncertainty.recovery_and_oxidation_components — "Mirror SWEET's gate, not just its tables: city_params.py applies the site-type capture default ONLY when gas-capture presence is true."

Reproduction

10_05_26 submission archive, run_id 20260921T231117Z, SWEET 1c98d59 (city_params.py byte-identical to main, so this is the code that ran). Join site, site_year and city_site_year on asset_identifier at year = 2024:

city-linked flag gce ox sites
BRA Controlled Dumpsite False 0.45 0.05 (ox_nocap) 959
BRA Sanitary Landfill False 0.60 0.10 (ox_nocap) 1,035
BRA Sanitary Landfill True 0.60 0.22 (ox_cap) 15
non-BRA Sanitary Landfill False/NULL 0.00 0.10 6,290

Expected: capture 0 wherever the flag is not a yes.
Actual: 1,994 sites at 0.45/0.60 while flagged False. Every one is city-linked; nothing outside that set is affected.

The symmetry is the argument: False is an unverified default in both Brazil and Mexico (the repo's own diagnostic says so), yet Brazil's 1,994 ran with full capture and Mexico's 1,938 ran at zero — decided only by whether the site is attached to a city record.

There was also a latent crash. citysite's gas_capture_presence == True raises TypeError: boolean value of NA is ambiguous on a null flag; it has not fired only because all 3,886 city-linked assets carry a real True/False.

The fix

Same history as the MCF table, same fix: one definition, two callers.

  • _resolve_gas_capture is now the single home of the rule; both methods call it.
  • GAS_EFF_OPTIONS / OX_OPTIONS move to module level; the two per-method copies are deleted.
  • site_only's semantics are preserved exactly. citysite additionally picks up the pd.NA guard and the empty-gascap_df fallback.
  • sinar_city_and_site and site_only_estimate are untouched — neither is on the Climate TRACE path.

Expected change in output

Derived by rescaling the archive against emissions = ch4 * (1 - gce*0.98) * (1 - ox); not yet confirmed by a run.

  • 1,994 Brazilian sites: 2024 FOD 655 → 1,534 kt CH4 (2.34x)
  • Global: +879 kt, +5.1% of the 17,323 kt all-site total; Brazil 1.51x
  • Only 4 of the 1,994 are fusion-published, so the published change is essentially the FOD change
  • Their published uncertainty also rises, 0.254 → ~0.446, because uncertainty.py already assumed the gated behaviour and was therefore charging no recovery-error term

Labelled model-output-change, not breaking-change: nothing stops running, the numbers move.

Acceptance criteria

  • A flag that is not a yes (False, None, NaN, pd.NA, 0, "No") yields zero capture in both paths
  • A yes yields the site-type default in both paths, with ox_cap
  • A measured gas_collection_efficiency still overrides the flag in both directions
  • A null flag no longer raises in the citysite path
  • Capture data with no reported_emissions_year falls back to the gated default, not NaN
  • Oxidation and capture can never disagree about presence
  • Neither _trace method keeps its own copy of the tables (guard test)
  • site_only's behaviour is unchanged

Definition of Done

  • Acceptance criteria met
  • Tests pass — 241 SWEET, plus 1,633 + 247 in the pipeline repo against this branch
  • Docs updated — GAS_CAPTURE_LINKAGE.md in the pipeline repo carries the full investigation
  • Reviewed & merged

Pairing

Must be merged and run with RMI/RMI_Climate_TRACE_Waste_Methane branch the-gas-capture-flag-gates-the-default, which carries the investigation write-up and the companion skiptop fixes.

🤖 Generated with Claude Code

`site_only_estimate_trace` and `citysite_estimate_trace` carried copies of the
gas-capture logic and the copies drifted. The citysite copy applied the
site-type default (0.60 / 0.45 / 0.0) with no check on
`landfill_gas_collection`, while still reading that same flag to pick
`ox_cap` vs `ox_nocap`. So a city-linked landfill was built with
`gas_capture=False` and `gas_capture_efficiency=0.6` on the same object.

On the 10_05_26 submission that hit 1,994 sites: every Brazilian city-linked
asset and nothing else. 959 controlled dumpsites at 0.45 and 1,035 sanitary
landfills at 0.60, all flagged False. Mexico's 1,938 equally-unverified False
sites ran at zero, because they take the site_only path.

Same history as the MCF table, same fix. `_resolve_gas_capture` is now the
single definition of the rule and both methods call it; `GAS_EFF_OPTIONS` and
`OX_OPTIONS` move to module level and the two per-method copies are deleted.
`site_only`'s semantics are preserved exactly. citysite additionally picks up
the pd.NA guard (its `== True` raised "boolean value of NA is ambiguous" on a
null flag) and the empty-gascap_df fallback.

The copies in `sinar_city_and_site` and `site_only_estimate` are untouched --
neither is on the Climate TRACE path.

Model output moves: Brazil's modelled FOD rises ~2.34x on those 1,994 sites,
about +879 kt CH4 in 2024. Their published uncertainty also rises, from 0.254
to ~0.446, because `uncertainty.py` already assumed the gated behaviour.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@HughRunyan HughRunyan added bug Something isn't working python Pull requests that update python code model-output-change Changes model OUTPUT values (expected progress, not breaking); results differ from prior runs test Adds or modifies tests labels Sep 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working model-output-change Changes model OUTPUT values (expected progress, not breaking); results differ from prior runs python Pull requests that update python code test Adds or modifies tests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant