[Meta] Plan :)

[JackKelly]

The broad aim is to build an ML model which is more like an evolution of the models we built in December, rather than a radical departure :slightly_smiling_face: (I've taken on board @peterdudfield's comments about my previous plans being a bit too complicated! :slightly_smiling_face:). So the idea is a single model which predicts multiple PV systems per example and predicts GSP PV power (without using separate models to predict individual PV power, then combine predictions from multiple PV systems, and finally predict GSP power).

This new plan is related to our original ideas (back in July 2021) of using the Perceiver as an RNN (see https://github.com/openclimatefix/perceiver-pytorch/issues/1 and https://github.com/openclimatefix/predict_pv_yield/issues/68).

The most recent plan is to merge ideas from Hierarchical Perceiver (Carreira et al. 2022) with ideas from MetNet (Sønderby et al. 2020) (see this discussion for more details of the model):

And then to experiment with a slightly more complicated - but possibly more computationally efficient - encoder/decoder model, inspired by thinking about graph neural networks (#34):

Detailed plan

Split these into separate issues as I progress :slightly_smiling_face:

• [x] #24
• [x] #25
• [x] #26
• [x] #27
• [x] #28
• [x] #30
• [x] #31
• [x] #32
• [x] Plot the outputs of all the above steps, to check it's sane!
• [x] #35
  • [ ] Inputs: HRV satellite. Each query element: PV location, embedding of PV system ID, Sun's angle and elevation, clearsky irradiance and/or pvlib prediction of PV given clearsky? This query definitely needs to go to the decoder. Also try giving this query to the encoder (alternatively try a learnt query into the encoder).
  • [x] First, directly predict PV yield (without bothering with clearsky irradiance).
  • [ ] Then wire up the model so the output of the ML model goes through a ReLU (so it can't go negative and because clouds can increase irradiance above the clearsky irradiance. The increase can be 2x in very extreme cases, but is more often an increase of about 30%) and then multiplied by the PV power predicted by pvlib, given clearsky irradiance.
  • [ ] Mixture density network (multiply the "means" of the MDN by pvlib's PV power prediction).
  • [x] Investigate the attention matrix.
  • [x] Try to figure out if the model is learning the shading properties of each PV system.
  • [x] Is the model predicting ramps?!
  • [ ] Try predicting GSP power and PV power.
    • [ ] Need to think how to tell the model the size and shape of each GSP. Maybe, like before, add a GSP ID to each spatial encoding element, or a boolean "is in GSP" flag to each pixel?
  • [ ] Try making it easier for the model to understand the direction of the sun by using "rotated x,y axes" for the spatial encoding. i.e. always align the y-axis with the direction of the Sun's rays.
  • [ ] Then tell pvlib the NWP air temperature and wind speed at the surface.
• [x] #14 Read Hierarchical Perceiver, as perhaps the "hierarchy" could be re-framed as timesteps?!
• [x] #48
• [ ] "Hierarchical Perceiver x MetNet": Historical inputs: PV and satellite. Each "PV element" in the historical input should probably include, say, three timesteps of power data (centered on the current timestep) so the model can see rapid fluctuations. Future inputs: "cheating" actual satellite imagery. Future outputs: PV and GSP.
  • [ ] Try giving each "input perceiver" at least 2 consecutive timesteps of satellite imagery in each patch (to make it easier for the model to see changes across time) (perhaps using PatchSatellite #32?)
  • [ ] Need to also provide absolute time of each input. Maybe give every inputs (including satellite pixels) an absolute time-of-day position? Or maybe it's better to give, say, the Sun's elevation and angle (but use the Sun's angle and elevation at the center of the image, because it's almost certainly too slow and not informative to give Sun's location for every pixel!)
  • [ ] Try looping each timestep of future PV prediction into the model (as the "output query"?) for predicting the next timestep
  • [ ] Try adding in the full ~25,000 PV systems, and use the "day-behind" PV systems as training targets for the history and the future timesteps (so the history timesteps have something to aim for)
  • [ ] Remove the "cheating" actual satellite imagery from the future timesteps. How does the model perform without any "future satellite" images?
  • [ ] Try with optical flow predictions of future satellite imagery
• [ ] Try predicting future satellite images.
  • [x] #45
  • [x] #46
• [ ] Try encoder / decoder Hierarchical Perceiver model inspired by graph neural nets (#34)
• [ ] Feed in gridded NWPs (mostly the cloud cover fields). (temperature and wind-speed effects at the PV system should already be accounted for using pvlib)
• [ ] Try feeding in the multiple-vertical-level NWPs of temperature, humidity and wind speed (see issue #21). The hope is that we might be able to learn a better "parameterisation" of NWP humidity to cloud cover, and so predict for days into the future.
• [ ] Experiment with different satellite channels (so see which are most relevant for PV power prediction, which has quite big implications for how much the service will cost to run!)
• [ ] Create new pre-prepared training dataset (dependent on the findings from above. e.g. do we want to jointly train on satellite imagery from the full geographical extent (to predict future satellite images); do we want NWPs with multiple vertical levels?)
• [ ] Try separately predicting individual PV power; and then predict GSP PV from predictions for individual PV

[peterdudfield]

Would it be worth trying putting elevation in too?

Im not sure where this where this goes on the priority list, perhaps lower down

[JackKelly]

Good idea! Thanks! After your suggestion, I've just added elevation after include land/sea mask :slightly_smiling_face: