-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix CAISO timestamp correction #300
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! I would just run this and manually inspect the timestamps (if you haven't already / if that's possible) since there aren't tests for these cleaning functions.
So for CAISO specifically, I was able to compare the EIA-930 data with the data that CAISO reports directly on its website. If we look at the below charts, the green line shows the "benchmark" data from CAISO, and the red line shows the cleaned EIA-930 after implementing this time shift. We can see that the data generally aligns before June 16, and then continues to align even better after the 16th (I believe that when CAISO fixed this timestamp issue, they simultaneously fixed an issue where they had been reporting instantaneous MW rather than hourly average MW, which is why the post 6/16 data looks even better. However, one thing you notice is that CAISO seems to have "fixed" this issue on June 14, then went back to the old method on June 15, then permanently implemented the change on June 16. Maybe this suggests that to be the most accurate, we should end the correction on 6/14, restart it for one day on 6/15, then end it again on 6/16. |
…ngularity-energy/open-grid-emissions into fix_ciso_timestamp_correction
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice if there was a way to refactor this code into a helper function, and just define the correction_start
and correction_end
for each region. Maybe in a future PR?
For example, we implemented a common format for specifying timestamp corrections in the EIA scraper: https://github.com/singularity-energy/scrapers/blob/master/scrapers/eia_genfuelmix.py#L87
CAISO had previously been reporting start-of-hour values to EIA-930, instead of end-of-hour, as instructed, so we had been applying a timestamp correction to shift the values by +1 hours. However, it looks like starting on June 16, 2022, CAISO started correctly reporting end-of-hour values, so we want to end the correction on this date.
Since we have not yet published 2022 OGE data, this should not affect any of our current outputs.