ml_id is nan when using pvnet_site_datapipe and leads to unnecessary fills

[AUdaltsova]

Describe the issue

In ocf_datapipes.load.pv._load_pv_metadata when ml_id is absent in the metadata file it gets added as np.nan, which when using pv_site with just one site gets saved as np.nan, and then in training gets imputed as 0 each time an observation is loaded.

Does not affect results since in this case ml_id is not used anyway, but leads to a lot of small unnecessary operations.

To Reproduce

Visible when training with batches with pv_site data. Example log:

Epoch 6:  89%|████████▉ | 267/300 [19:05<02:21,  0.23it/s, v_num=only][2024-05-31 13:24:46,228][pvnet_site_datapipe][INFO] - Filtering out samples with no data
[2024-05-31 13:24:46,340][ocf_datapipes.training.common][INFO] - Filled NaNs with zeros - {'BatchKey.pv_ml_id'}
[2024-05-31 13:24:46,426][pvnet_site_datapipe][INFO] - Filtering out samples with no data
[2024-05-31 13:24:46,537][ocf_datapipes.training.common][INFO] - Filled NaNs with zeros - {'BatchKey.pv_ml_id'}
[2024-05-31 13:24:46,616][pvnet_site_datapipe][INFO] - Filtering out samples with no data

Suggested fix

When creating ml_id column here for pvnet and here for windnet fill with 0 instead of np.nan

[AUdaltsova]

Looking at this again, it looks like the other log info ("Filtering out samples with no data") refers to some satellite data operation that is commented out, so essentially logs an event that is not occurring anyway, see:
ConvertToNumpyBatchIterDataPipe, so might want to fix that as well?

[AUdaltsova]

this is true for windnet as well! (just created some sample batches and wind__ml_id is filled with nan). Fairly sure this is where it happens: ocf_datapipes/load/wind/wind.py

[AUdaltsova]

@dfulu do you think there is any downside to doing this? I want to tag it as good first issue but wanted to check-in first

[dfulu]

Yeh that seems reasonable for now. We should think about this all more carefully for the successor to datapipes