Bug: Substation

[peterdudfield]

Describe the bug

Two different routes proces slightly different forecast results

To Reproduce

Steps to reproduce the behavior:

1. pull forecasts for on substation
2. pull forecast for all substations at one timestamp

Expected behavior

They results for one substation and one timestamp should be the same

Additional context

• the pull forecast subation, gets the gsp data, rounds it, then scales to primary
• the all susbation routes, gets all the gsp forecast and then scales (no rounding)

Idea

• We should remove the round before it scales to primary substation (here)
• round both routes to 3 d.c.p

[CodeVishal-17]

This looks like a clear inconsistency in the order of operations.

I’m happy to open a PR that:

• Removes rounding before scaling
• Applies rounding once at the response boundary
• Ensures both routes use the same decimal precision

Let me know if that approach works for you and I’ll submit the PR.

[CodeVishal-17]

I’ve opened a draft PR #183 that removes rounding before scaling in the
substation forecast route and standardizes the order of operations.
Happy to update based on feedback.

[Raakshass]

Hi @peterdudfield! I'd like to investigate this substation forecast discrepancy bug.

I'll:

1. Set up the local environment
2. Reproduce the issue with single vs. all substations
3. Debug the forecast processing logic
4. Submit a fix

Will start exploring the codebase today!

[CodeVishal-17]

Hi @Raakshass — just to clarify, I’ve already opened a draft PR (#183) that addresses this issue by fixing the rounding order in the substation forecast route.

Feel free to take a look and share feedback there, or build on top of it if you spot any gaps. Happy to collaborate 👍

[ArkVex]

Hi @Raakshass — just to clarify, I’ve already opened a draft PR (#183) that addresses this issue by fixing the rounding order in the substation forecast route.

Feel free to take a look and share feedback there, or build on top of it if you spot any gaps. Happy to collaborate 👍

I am sorry to interrupt it's none of my matter to jump in this conversation but I feel @Raakshass is just proposing an idea...so that should not be a problem, Though your pr is in draft it will always be in priority.
Thankyou

[CodeVishal-17]

Thanks for jumping in, @ArkVex 🙂

Just to clarify, my intent was only to let Raakshass know that there’s already a draft PR addressing the issue, so efforts don’t get duplicated.

Raakshass is absolutely welcome to investigate further, review the draft PR, or suggest improvements — happy to collaborate and iterate together.

[Raakshass]

thanks for the clarification @CodeVishal-17! i took a look at your draft pr #183 and it looks good.

a couple of observations:

1. the fix correctly removes rounding before scaling
2. both routes should now produce consistent results

happy to test locally if you need another set of eyes. let me know if there's anything specific you'd like reviewed!