thegreenwebfoundation / grid-intensity-go

A tool written in go to help you factor carbon intensity into decisions about where and when to run computing jobs.
Apache License 2.0
61 stars 7 forks source link

Day-ahead and other forecast functions in CLI #13

Open mrchrisadams opened 2 years ago

mrchrisadams commented 2 years ago

I'm putting @mrchrisadams's original work here, so we don't lose it, as it has some really cool ideas in it, that some API providers support but some don't.

Call the grid-intensity binary to get an idea of the current carbon intensity of electricity, on the machine you're calling it on.

You'll receive an estimated figure for your location.

$ grid-intensity # get data back as formatted JSON

### estimated carbon intensity for compute will be low on this machine for next 30 mins, until HH-MM:00

You can also use this to get an idea of the expected intensity of the next 24 hours. This allows your job scheduler to account for this in allocating jobs your cluster(s).

$ grid-intensity 

### estimated carbon intensity for compute will be low on this machine for next 24 hours, but peak between 7 and 10pm today

Append --json for a machine readable version of the same data, consumable by other services in your cluster.

ofpiyush commented 2 years ago

Oii it was you! https://github.com/thegreenwebfoundation/grid-intensity-go/commit/fbc0059b90bfb2d534fe16a756c37d3026661a35

Spiderman

I removed it from the readme and copy pasted it into an issue because we hadn't implemented it at the time 😄

mrchrisadams commented 2 years ago

hahah! Oops, I totally forgot about that. thank for clearing that up. Also, top quality good meme-age 👍

rossf7 commented 1 year ago

Hey @mrchrisadams like I mentioned in DM I'd like to have a go at this.

I think we could implement getting the 24h ahead forecast for all existing providers except Ember.

For the CLI the 2 best options I can see are

My preference would be option A as I think its simpler. What do you both think?

For the Go library I'd propose adding this method to the interface.

GetForecast(ctx context.Context, location string) ([]CarbonIntensity, error)

The exporter is tricky as I can't see a good way of exposing the forecast as prometheus metrics. So I'd propose leaving this for now.