Adding day-ahead price data for US-CAL-CISO (CAISO)

[arochaja]

Hi all,

I'd like to propose adding a day-ahead price parser for US-CAL-CISO. Right now the zone has production/carbon intensity data but no price data. I looked through past issues (#787, #959) and it looks like price was just never picked up rather than being blocked for a technical reason — wanted to confirm that's still the case before I start building, and get input on one design decision.

Note: this is about the wholesale day-ahead price (the same metric already shown for other zones on the map), not the end-consumer/retail price breakdown discussed in #4487 — just flagging that distinction so it's clear this is a more contained addition.

Proposed source

CAISO publishes day-ahead LMPs through their public OASIS API (PRC_LMP report, market_run_id=DAM). Example request:

https://oasis.caiso.com/oasisapi/SingleZip?node=TH_SP15_GEN-APND&market_run_id=DAM&queryname=PRC_LMP&startdatetime=20260601T07%3A00-0000&enddatetime=20260602T07%3A00-0000&version=1&resultformat=6

This returns a zipped CSV. I've confirmed the endpoint is live and responds as expected. Since prices settle the day before delivery, this should comfortably meet the freshness requirement in the [Technical Requirements](https://github.com/electricitymaps/electricitymaps-contrib/wiki/Technical-requirements-for-parser-data) doc, and DAM data is hourly, so granularity isn't an issue either.

Open question: which node(s) to use

CAISO prices are set at the pricing-node level, not zone-level, and there isn't a single price for the whole BA. The main candidates are:

• One of the three trading hubs (NP15, SP15, ZP26) as a proxy — simplest, but only partially representative
• An average across all three hubs — more representative of the whole zone, more requests to make and combine
• Some other CAISO-published system-wide reference price, if one exists that I'm missing

Wanted to ask if there's a precedent in the codebase for handling similar multi-node US ISOs, or a preference from maintainers on which approach fits best here, before I commit to one.

Plan if this is a green light

• Build fetch_price following the current parser structure (using PriceList/Price from electricitymap.contrib.lib.models), modeled on the existing US_SPP.py parser for style
• Test locally via uv run test_parser US-CAL-CISO price, including a historical --target_datetime run
• Register the new function in config/zones/US-CAL-CISO.yaml and add the source to DATA_SOURCES.md
• Open a PR once it's passing locally

Happy to take any feedback on scope or approach before I get started. Thanks!

[VIKTORVAV99]

We are actually already collecting the price for all LMP nodes for CAISO internally, but so far there has not been much interest from users and since most of our other data is zonal it's not super straight forward of how we would display this on the app/map.

I'm curious what your use case here would be since there are thousands of LMS in California? It's not as easy to get an overview like it is for zonal prices.

[arochaja]

That's really helpful context, thanks — good to know the data's already flowing internally, so this is more of a "how do we represent it" problem than a sourcing one.

On the thousands-of-LMPs issue — I think there's a way to sidestep node-level granularity entirely. CAISO's LMP at any node breaks into three components: Marginal Cost of Energy (MCE), Marginal Cost of Congestion, and Marginal Cost of Losses. Congestion and losses are what vary by location; the energy component reflects the system-wide marginal cost of serving the next MW of load, and is uniform across the BA absent binding constraints. PRC_LMP returns these components separately, so it's possible to pull just the energy component instead of the full node-level LMP — giving a single, genuinely zonal price rather than an averaged approximation.

Since you already have node-level LMPs internally, it'd be easy to check this empirically rather than take it on faith — e.g. the standard deviation (or min/max spread) of LMP minus MCE across all nodes for a given hour. If that spread is small most of the time, it's a solid case that MCE is a reliable single-number stand-in for the zone. If it's large or frequent, that'd be useful to know too, since it'd mean congestion is binding often enough that a single energy-only number might understate what's actually happening.