ownership table reporting owner in operator column in 2010.

[cmgosnell]

Describe the bug

For 730 plant/generator/year records (which is about 1.9% of the total), the utility_id_eia column is being reported as the owner_utility_id_eia. See our column description for more details here. For whatever reason, there records are all in 2010.

This problem makes merging this table with the generators difficult because we expect the utility_id_eia to be the operator (not the owner) in both tables.

This is probably also a source of the inconsistencies in the harvested utility_id_eia.

Bug Severity

How badly is this bug affecting you?

• Medium: With some effort, I can work around the bug.

To Reproduce

With a fully loaded database, using the pudl output object:

I also checked pulling directly for the database and saw the same issue.

[zaneselvans]

Proposed solution

• Null the utility_id_eia column for generator-years in which more than one value of utility_id_eia is found. This should happen in the pudl.transform.eia860.ownership() transform function.
• In the end, we should not be retaining that column in this table at all -- it's poorly normalized.
• However, this will not address the case in which there is only one owner, and the operator ID is the same... some of those will be valid, but others may not:

  own_eia860 = pd.read_sql("ownership_eia860", pudl_engine)
  own_eia860[
  (own_eia860.utility_id_eia == own_eia860.owner_utility_id_eia)
  & (own_eia860.fraction_owned == 1.0)
  ].report_date.value_counts()

• To get around this ambiguity, we can also null the utility_id_eia value in the rows where there's only one owner and they are also the operator. There are only ~2500 such records, and this information is redundantly available from other tables as well.

In addition utility_id_eia should not be in the annual generators_eia860 table -- it is entirely determined by the plant_id_eia which the generator_id is associated with. See #1266