Dumps with no recorded depth use the IPCC uncategorised MCF (0.6), from a single MCF table

[HughRunyan]

What changes

Methane correction factors are now defined once, in a new SWEET_python.mcf
module, and both dump types take the IPCC "uncategorised SWDS" default of 0.6.

Site type	MCF before	MCF after
Sanitary landfill	1.0	1.0 (unchanged)
Controlled dumpsite	0.7	0.6
Open dumpsite	0.4	0.6
Any dump, depth > 5 m	0.8	0.8 (unchanged)
Any dump, depth ≤ 5 m	0.4 (by fallthrough)	0.4 (explicitly)

IPCC 2006 Vol. 5 Ch. 3 Table 3.1 splits unmanaged sites by waste depth — deeper
than 5 m is "unmanaged deep" (0.8), shallower is "unmanaged shallow" (0.4) — and
prescribes 0.6 where the depth is unknown. SWEET applied the 0.8 bump
wherever a depth was supplied but fell back to 0.4 when it was not, which treats
"we do not know the depth" as "we know it is shallow".

In practice no dump carries a depth at all. In the August 2026 Climate TRACE
input table, depth is populated for 450 of 4,635 sanitary landfills (MCF 1.0
regardless) and for 0 of 8,067 dumpsites and 0 of 959 controlled dumpsites.
"Controlled dumpsite" is not an IPCC category and takes the same uncategorised
value for the same reason: the rows it could plausibly sit in span a wide range
depending on how well a site is run, which is exactly what our inputs do not
record. 0.7 was asserting a management standard we have no evidence for.

Four related pieces come with it:

1. The depth rule now works in both directions. It was one-directional —
   raise to 0.8 above 5 m, otherwise fall through to the type default — so once
   that default became 0.6 there was no way to reach 0.4 even for a site known
   to be shallow. Now: > 5 m → 0.8, ≤ 5 m → 0.4, absent (None/NaN) → 0.6.
   The comparison is strict, so exactly 5.0 m reads shallow.
2. No caller fabricates a depth any more. That distinction only works if a
   caller with no depth says so, and several substituted a plausible number
   instead: City.sdst_prepopulate returned 100 m for a landfill or controlled
   dump and 3 m for a dumpsite, derived purely from the site type;
   City.sinar_city_and_site and City.site_only_estimate hardcoded 3 m. All
   pass None now. WasteMAP's paired branch removes the same fabrication on its
   side (the DST form's '3' default and the prepopulate endpoint's 3.0
   fallback).
3. CityLandfillSpec.depth is new. The city-level advanced DST was the only
   DST path with no way to express depth at all, which is why WasteMAP's advanced
   DST had a Deep/Shallow/Unknown control that could not be sent anywhere.
   Omitted by default, so existing city-adst calls are unchanged.
4. Ten copies collapse to one. The table and the depth rule were duplicated
   across four site-type-name tables, three landfill-type-index tables,
   dst_common.MCF_BY_TYPE, the dump conversion in
   City.implement_dst_changes_simple_v1_5, and the generic city dumpsite bucket
   in City._calculate_divs — and had drifted into two families, dict-keyed
   (controlled dump 0.7) and list-keyed (0.6). All ten now call
   mcf.mcf_for_site(site_type_idx, depth). dst_common re-exports
   MCF_BY_TYPE, SITE_TYPE_NAMES, DEEP_SITE_DEPTH_M, DEEP_DUMP_MCF and
   DEEP_MCF_DUMP_TYPES, so existing importers are unaffected.

Model-output impact

MCF multiplies generation linearly, so the effect is proportional and easy to
predict:

• +50% modelled methane generation at every open dump
• −14% at every controlled dumpsite
• +50% for any /sdst run on a site with no recorded depth (0.4 → 0.6)
• −33% for a /sdst run on a dump with a recorded depth at or below 5 m
  (0.6 → 0.4), which previously could not be expressed
• Sanitary landfills and dumps recorded deeper than 5 m are unchanged

Two consequences worth carrying forward:

• MCF no longer distinguishes the two dump types, so a scenario that converts
  an open dump to a controlled dump now changes emissions only through cover
  oxidation and gas capture, which SWEET models separately. The strategy of
  raising MCF by reclassifying a site is gone from the DST.
• Because open dumps outnumber controlled dumpsites roughly 8:1 in the Climate
  TRACE input table, the net direction for a full TRACE run is up, on the
  order of +16% global CH4.

Bug fixed along the way

City.sinar_city_and_site tested site_type in (1, 2) against a site-type
string in its second per-landfill branch, while the first branch correctly used
site_type_idx, so the deep-dump MCF bump could never fire there. The hardcoded
3 m depth on that path meant the condition was already always false, so nothing
changes in output; the defect would have surfaced the moment a real depth reached
it. Both branches call mcf.mcf_for_site now.

mcf.mcf_for_site also tolerates a None/NaN depth, so
City.advanced_baseline no longer raises TypeError on its own
depth: float = None default.

Paired branches

Same branch name in each repo, per our cross-repo convention:

• RMI_Climate_TRACE_Waste_Methane — msw-ai-data-source-review (PR #93). The
  TRACE deploy workflow resolves SWEET by matching branch name, so this branch
  must exist on the remote for a TRACE run to pick the change up.
• WasteMAP — msw-ai-data-source-review (backend + SDST) and
  adst-depth-reaches-the-model (ADST, off the proto line).
• This repo also carries adst-depth-reaches-the-model as an alias at the same
  commit, so WasteMAP's ADST branch resolves a matching SWEET ref.

Acceptance Criteria

• Every MCF value and the depth rule resolve through one module,
  SWEET_python.mcf; no other module hardcodes an MCF table
• Both dump types return 0.6 when no depth is supplied
• A supplied depth selects 0.8 (> 5 m) or 0.4 (≤ 5 m) on both dump types, and
  never applies to a sanitary landfill
• None and NaN depths are accepted everywhere and mean "unknown"
• No SWEET call site invents a depth from the site type
• CityLandfillSpec.depth threads a per-landfill depth into
  dst_common.mcf_series, defaulting to omitted
• dst_common still exports its previous MCF names for existing importers
• Changelog records the change and its model-output effect

Definition of Done

• Acceptance criteria met
• Tests pass — tests/test_mcf.py is new (22 cases; MCF had no coverage at
  all before), full suite 114 passed
• Docs updated — changelog/2026-08.md and changelog/README.md
• Reviewed and merged, together with the paired branches above