electricitymaps / electricitymaps-contrib

A real-time visualisation of the CO2 emissions of electricity consumption
https://app.electricitymaps.com
GNU Affero General Public License v3.0
3.37k stars 911 forks source link

Consumption of imported nuclear missing from US-SW-PNM (and nearby zones) #6320

Closed nmgeek closed 5 months ago

nmgeek commented 6 months ago

When did this happen?

2016-05-01 12:00

What zones are affected?

US-SW-PNM

What is the problem?

I just discovered electricitymaps. It's awesome so I want it to be correct for zones I follow closely!

I understand that this zone is estimated. I have not yet taken the time to understand how the estimation is done, however the nuclear baseload is easy-peasy to estimate as it can be assumed to be running 24/7.

The nuclear generation capacity for this zone is currently at least 194MW baseload, higher before Jan 2023. If the solution is to hard-code the contracted nuclear MWs each time the contract changed I can dig up the accurate history. On the other hand, I assume you get your data from EIA and EGRID and this is just a matter of correctly categorizing some data type (or "exchange" attribute?). The plant's ID is EGRID 426, ORIS 6008.

I see that the EGRID PLNT file does not cover export of power to other balancing authorities so if this info is to be automatically derived, it has to come from somewhere else like EIA or FERC.

The 3,810 MW plant is called Palo Verde Nuclear Generating Station and it sits outside of the balancing area in Arizona, the state to the West. The power is imported to New Mexico from Arizona so it is definitely in FERC's transmission data.

I see that other zones consuming power from that plant also show zero nuclear and the Salt River Project zone shows 4GW of nuclear, ie the data from the PLNT file (which should be 3.8GW unless there is another nuclear plant providing another 200MW). So it looks like consumption of electricity produced by the Palo Verde plant is all being incorrectly attributed to US-SW-SRP.

If you do need exact numbers to hard-code into the config file I can help with that. But hopefully there is a more robust solution which re-qualifies consumption data when it is imported into the balancing area.

The config file is: https://github.com/electricitymaps/electricitymaps-contrib/blob/master/config/zones/US-SW-PNM.yaml

VIKTORVAV99 commented 6 months ago

Hi and thanks for opening the issue!

The way we do things is that we assign the electricity production in each zone to that zone and then we flow trace the exchanges between zones. So you are correct that all power produced are assigned to US-SW-SRP.

Now the problem here is that the exchange data is also delayed, just as the production data and right now we only estimate production data. We are working on exchange models as well though and should have some ready to be deployed soon, we will however start small with just a few exchanges.

Normally this gets corrected as soon as we get data from EIA but it seems we have no exchange data for US-SW-PNM->US-SW-SRP for some reason. So we will have to dig into that.

Just to add some details to why we do it this way can be found here: How to trace back the origin of electricity

nmgeek commented 6 months ago

I did some digging. I ran the fetch_exchange() function against US-SW-PNM->US-SW-SRP. There is no data for this path because the two balancing areas are not adjacent (This explains a comment in EIA.py about this path).

Power has to flow through one or more other balancing areas to complete the path. Most likely the nuclear power is going through US-SW-AZPS or US-SW-WALC or US-SW-TEPC. (To complicate matters, wind power contracted to balancing areas to the west of NM also flows between these balancing areas so the net flow is often toward the nuclear plant rather than away from it. In essence, while NM is paying for nuclear electricity it is mostly using "other people's" wind power generated inside the state. But this is tangential to the original issue.)

The results of fetch_exchange() are net transmission flow values. There is no attribution of which plant the power came from: it's all lumped together. Does the system prorate the net flow to get power generation technology (nuclear, wind, etc.) or is it using other EIA data to attribute the generation technology from the net flow? If it is the former, that explains what is going on ... and it makes me sad.

nmgeek commented 6 months ago

After rereading @VIKTORVAV99 's response about "exchange models" I am confused.

I also re-read the page on flow tracing and now believe the system is not simply pro-rating the technology mix. It is using the flow tracing algorithm to attribute the technology mix. That would 100% explain why the PNM zone shows as consuming no nuclear power: power from wind plants, exporting power from the PNM zone, are assumed to be the source of the power by the flow tracing algorithm even though a party outside the zone is paying for that wind power (which makes it exported power).

It seems that flow tracing tries to determine where the power really flows rather than how the power is paid for. That is an interesting approach but it is not how the CO2 is attributed to balancing areas. Emissions are attributed to the consuming party who is paying the plant to produce the power, i.e. commercial contracts drive CO2 attribution.

VIKTORVAV99 commented 6 months ago

The reason for using flowtracing based algorithm instead of just assigning values based on the reported bought power (contracts) are primality for 3 reasons:

As for exchange models, this is a way for us to apply different strategies to estimate the exchange flows in the cases where it is delayed (like in the most of the US), temporarily missing and in theory if it's completely missing. This will be done so we can increase the accuracy of our data.

Now to this particular exchange, I will look into why we have an exchange_config for it but no data. If this is a misstake it should be removed, otherwise we need to find out why it's not working and fix it if possible.

nmgeek commented 6 months ago

I did some more digging and found that EIA reports exchange from US-SW-PNM to/from US-SW-AZPS and US-SW-TEPC but not to/from US-SW-SRP and US-SW-WALC. This indicates that there are no transmission ties to the latter two zones. The former two exchange pairs are configured in EIA.py so I think all exchanged power is accounted for.

This leads me to believe that the contracted nuclear power does not flow into US-SW-PNM because of the abundance of contractually-exported wind (plus coal) power generated inside US-SW-PNM. Although it's hard to believe this happens 8,760 hours per year and that it happened 6 years ago when there were considerably less wind turbines. Coal power is also exported so that might explain this. If you went through every hour of the 7-year history maybe you could find an hour with a coal outage and low wind production when nuclear power would flow into the zone?

So, unless energymaps has a way to override part of the flow results with contracted baseload I don't think it will show the CO2 which is legally attributed to US-SW-PNM. Does this make sense? It appears to, instead, show the CO2 which physically leaves the boundaries of the US-SW-PNM zone.

nmgeek commented 5 months ago

After looking around I found that RMI is reconciling the purchased power part of the data. They say,

...we were able to close the data gap [between produced and purchased power], by cleaning up and combining datasets from EIA and FERC to produce detailed, machine-readable data on purchased power.

So it looks like for electricitymaps to attribute emissions to zones based on purchase contracts it would have to also import FERC form 1.

VIKTORVAV99 commented 5 months ago

Electricity Maps mission is to provide an accurate representation of the grid both in time and location to provide others with the ability to reduce their carbon impact and electricity usage. (Somewhat simplified).

This does not really work if we instead start to account for legal attributions instead of physical usage, another example of this is that you can buy 100% solar energy contracts. But this is both physically and theoretically impossible as the sun don't shine all the time.

That is why we are instead collecting the actual energy produced for each hour (or better) for every zone and the flows between them. This allows to accurately determine the carbon intensity of the power actually drawn from the grid.

I do hope you understand the reasoning behind this.