Compute fireIndex in API hourly/currently pipelines and remove runtime NBM_Fire dependency

[Copilot]

fireIndex was returning -999 outside NBM Fire coverage or when NBM Fire was excluded. This change computes Fosberg Fire Weather Index directly from interpolated forecast variables so fire index is available wherever core inputs exist in both hourly and currently blocks.

• Hourly fire index derivation

  • Added calculate_fosberg_fire_index(...) in API/hourly/block.py.
  • Computes Fosberg index from interpolated hourly temp (°C), humidity (fraction), and wind (m/s), with SI→US unit conversion and existing CLIP_FIRE bounds.
  • Integrated into _calculate_derived_metrics(...) so InterPhour[:, DATA_HOURLY["fire"]] is API-derived rather than source-passed.

• Currently fire index derivation

  • Updated API/current/metrics.py to derive current fireIndex from current temp, humidity, and wind using calculate_fosberg_fire_index(...).
  • Removed current-path reliance on NBM_Fire_Merged/NBM_FIRE_INDEX so currently no longer returns -999 solely due to missing NBM Fire coverage.

• Remove NBM Fire from hourly data wiring

  • In API/data_inputs.py, removed NBM_FIRE_INDEX usage for hourly fire input assembly.
  • fire_inputs now remains a neutral placeholder (NaN column), allowing derived fire computation to fully own the field.

• Stop reading NBM_Fire in request path

  • In API/request/grid_indexing.py, removed the NBM_Fire zarr read task and associated runtime freshness handling.
  • dataOut_nbmFire remains False, preventing NBM Fire from re-entering source selection.

• Focused test coverage

  • Added a deterministic unit test in tests/test_hourly_refactor.py validating Fosberg index calculation from SI inputs.
  • Added focused tests in tests/test_current_refactor.py validating derived currently fire index and missing-input behavior.

# API/hourly/block.py
InterPhour[:, DATA_HOURLY["fire"]] = calculate_fosberg_fire_index(
    InterPhour[:, DATA_HOURLY["temp"]],
    InterPhour[:, DATA_HOURLY["humidity"]],
    InterPhour[:, DATA_HOURLY["wind"]],
)

[cloneofghosts]

@copilot This works but we also need to calculate it for the currently block. It only covers the hourly block at the moment and the currently block is -999.

[Copilot]

@copilot This works but we also need to calculate it for the currently block. It only covers the hourly block at the moment and the currently block is -999.

Implemented in 4488fbc. The currently block now derives fireIndex from current temp/humidity/wind using the same Fosberg calculation as hourly, so it no longer depends on NBM_Fire and no longer returns -999 solely due to missing NBM fire coverage.

[cloneofghosts]

@alexander0042 I think this should be good to merge if you want to do a quick check through.

[cloneofghosts]

@copilot Can we make sure the function has a proper Google style docstring + comments where needed. It should also probably be in a shared file rather than in the hourly block?

[Copilot]

@copilot Can we make sure the function has a proper Google style docstring + comments where needed. It should also probably be in a shared file rather than in the hourly block?

Done in the latest commit. calculate_fosberg_fire_index has been moved to API/utils/fire.py with a full Google-style docstring (Args / Returns / Reference sections) and inline comments explaining the unit conversions, the three-regime moisture model, and the η damping coefficient. Both API/hourly/block.py and API/current/metrics.py now import it from the shared location, and the test file has been updated accordingly.

[alexander0042]

It runs fine, which is a great start. I'm seeing somewhat different values, which isn't a showstopper, but I just want to quickly double check the math

[alexander0042]

I'm seeing some different values compared to prod; however, it's because of a change in the inputs. When I set everything to only use NBM it works out to almost the same, which is exactly the check I wanted to see! LGTM

[cloneofghosts]

Sounds good. Should probably update the development docs to reflect this change so we don't need to do it later

[alexander0042]

Sounds good. Should probably update the development docs to reflect this change so we don't need to do it later

I'm on it! This is my continued attempt to be both more prompt with some things and realistic about timelines with others

[cloneofghosts]

Ideally we should be updating the changelog/documentation as we go so we don't need to update everything at once when a new version comes out. I know I'm pretty bad at remembering to update it for changes but will try to remember going forward.