Skip to content
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

Survey sanity checks #137

Open
25 of 26 tasks
Erikvv opened this issue Oct 9, 2024 · 8 comments
Open
25 of 26 tasks

Survey sanity checks #137

Erikvv opened this issue Oct 9, 2024 · 8 comments
Assignees

Comments

@Erikvv
Copy link
Member

Erikvv commented Oct 9, 2024

In module "Zummon" add sanity checks and

  • design a class interface to implement sanity checks.
  • display sanity checks after uploading and parsing excel file.
    • Red for error
    • Green for OK
    • Yellow for warning (unlikely but not impossible inputs)
    • Grey for missing data?
  • ask colleagues to specify sanity checks from their experience:
    • Gillis
    • Ate
    • Naud

Sanity checks

Capacities and annual totals:

  • contracted delivery capacity should be less or equal to physical capacity
  • contracted feed-in capacity should be less or equal to physical capacity
  • annual pv production should be more than annual feed-in
  • grootverbruik should have physical connection more than 3x80A
  • kleinverbruik should have physical connection less than or equal to 3x80A
  • power per charge points should be between 3 and 150 kW
  • total power of charge points should be below contracted delivery capacity + battery power
  • km per vehicle should be between 5k and 100k (4x: cars, vans, trucks, other)
  • number of electric vehicles should be less than or equal to total number of vehicles (4x: cars, vans, trucks, other)

Booleans:

  • hasPV true -> should have annual production
  • hasBattery true -> should have power and capacity
  • hasNaturalGasConnection true -> should have annual delivery

Quarter-hourly data:

  • annual feed-in should match total of quarter-hourly feed-in
  • annual gas delivery should match total of hourly delivery
  • quarter-hourly delivery data should not have "holes" longer than 4 days. Display duration of hole in message.
  • quarter-hourly production data should not have "holes" longer than 4 days. Display duration of hole in message.
  • quarter-hourly feed-in should not be all zeroes if hasPv is true
  • every time step in quarter-hourly feed-in should be be less than or equal to production + battery power
  • peak of delivery should be less than contracted capacity
  • peak of feed-in should be less than contracted capacity

Best IDE to use is https://www.jetbrains.com/idea/nextversion/

@Erikvv Erikvv changed the title Sanity checks Survey sanity checks Oct 9, 2024
@naudloomans
Copy link
Member

naudloomans commented Oct 9, 2024

  • peak of delivery should be less than contracted capacity -> should be warning, compnaies can sometimes exceed contracted capacities

@AteZenmo @GillisHommen punt van aandacht: wat zijn de minimale inputs die we nodig hebben om een bedrijf te accepteren (jaarverbruik, opwek, en aansluitcapaciteit) of is aanlsuitcapaciteit niet per se nodig?

Erikvv added a commit that referenced this issue Oct 9, 2024
Erikvv added a commit that referenced this issue Oct 9, 2024
Erikvv added a commit that referenced this issue Oct 9, 2024
Erikvv added a commit that referenced this issue Oct 9, 2024
Erikvv added a commit that referenced this issue Oct 9, 2024
Erikvv added a commit that referenced this issue Oct 9, 2024
@GillisHommen
Copy link
Collaborator

GillisHommen commented Oct 15, 2024

  • km per vehicle should be between 10k and 300k (4x: cars, vans, trucks, other)

I would put the upper limit much lower, at 100k, and the lower limit also lower, at something like 5k or even less.

  • power per charge points should be between 3 and 50 kW
    Chargers for heavy duty vehicles can have higher powers, I think we can allow up to ~150kW for normal cases, but this will go up further in the future. Maybe it's better to check that it's not bigger than the physical connection capacity. (unless there is a big battery, in which case the charger can have more power than the local connection capacity!)

For these two:

  • quarter-hourly delivery data should not have "holes" longer than 4 days.
  • quarter-hourly production data should not have "holes" longer than 4 days.

I understood 'holes' are defined as extended periods with a delivery of production of 0kWh per timestep? I don't think checking for 0.0 is really a way to identify 'missing data'. Basically all timeseries data should be complete (valid doubles) and it is the responsibility of Energieke Regio to make sure the data is correct or at least feasible. We can do checks on the sum and the min/max values of a timeseries though.

  • quarter-hourly feed-in should not be all zeroes if hasPv is true

FeedIn can be zero despite having PV; it just means all the production is consumed directly, and not fed back into the grid. Instead you can check that quater-hourly production should not be all zeroes if hasPv is true.

  • every time step in quarter-hourly feed-in should be be less than or equal to production.

For companies with a battery system this is not necessarily true. (but so far we have had no companies with a battery system)

@Erikvv
Copy link
Member Author

Erikvv commented Oct 15, 2024

I think for some of the points we can have "severity one" and "severity two" thresholds.

I would put the upper limit much lower, at 100k, and the lower limit also lower, at something like 5k or even less.

Done.

Chargers for heavy duty vehicles can have higher powers, I think we can allow up to ~150kW for normal cases, but this will go up further in the future.

Changed it to max 150 kW for now.

Maybe it's better to check that it's not bigger than the physical connection capacity. (unless there is a big battery, in which case the charger can have more power than the local connection capacity!)

Changed it to "total power of charge points should be below contracted delivery capacity + battery power"

I understood 'holes' are defined as extended periods with a delivery of production of 0kWh per timestep? I don't think checking for 0.0 is really a way to identify 'missing data'. Basically all timeseries data should be complete (valid doubles) and it is the responsibility of Energieke Regio to make sure the data is correct or at least feasible. We can do checks on the sum and the min/max values of a timeseries though.

I think it deserves a warning as I find it unlikely they'll check the entire time series.

FeedIn can be zero despite having PV; it just means all the production is consumed directly, and not fed back into the grid.

I've removed this check.

Instead you can check that quater-hourly production should not be all zeroes if hasPv is true.

I'm not sure if we should assume a production meter is always present.

For companies with a battery system this is not necessarily true. (but so far we have had no companies with a battery system)

Changed it to "every time step in quarter-hourly feed-in should be be less than or equal to production + battery power"

Erikvv added a commit that referenced this issue Oct 16, 2024
@macano
Copy link
Contributor

macano commented Oct 18, 2024

if kleinverbruikOrGrootverbruik is Grootverbruik includes Grootverbruik data
if kleinverbruikOrGrootverbruik is Kleinverbruik includes Kleinverbruik data

@GillisHommen
Copy link
Collaborator

GillisHommen commented Oct 21, 2024

Additional check:

  • PV installed power should not be larger dan 5000kW.

This will help detect when people fill in 'Watt-peak' in the field where they should fill in kiloWatt-peak. Buildings with more than 5000kW (5MW) PV on the roof are extremely rare, as good as non-existent, while almost any PV installation has more than 5kW (which would be 5000W, if it is filled in incorrectly). Failing this check should lead to a 'hard reject' of the data; this is the most basic sanity check that Energieke Regio should do (but still often miss). We should not accept the data if they missed this superbasic thing.

@AteZenmo
Copy link

(Future) additional check :

  • PV installed power [kW] should be lower than: selected roofSurfaceArea_m2 * 0.2 : To prevent companies having more pv than their roof can support. (this 0.2 [W/m2] is a factor that is already (much) to large in reality so could be scaled down as well).

-> Prevents to much solar installed aswell.

@macano
Copy link
Contributor

macano commented Oct 30, 2024

When the gridconnection has PV and quarter hourly production data and installed PV kWp (pvInstalledKwp), we can estimate the total sum of the list (around 900 hours of peak production in a year) = soort profiel

@macano
Copy link
Contributor

macano commented Oct 31, 2024

hasPV comes from electricity.hasConnection or supply.hasSupply?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants