search

quintel / etmoses

Online decision support tool to create local energy situations for neighbourhoods, cities and regions with a time resolution of 15 minutes created and maintained by Quintel – Not maintained
https://moses.energytransitionmodel.com
MIT License
11 stars 3 forks source link

The initial conditions should not dominate the load for weekly calculations #902

Open ChaelKruip opened 8 years ago

ChaelKruip commented 8 years ago

This is an issue that we have chosen to come back to whenever the weekly calculator was working properly. I think this is a good time to address it.

When starting a weekly calculation, batteries, buffers and EV batteries are assumed to be empty (right @antw?). This results in a spike in the load in the first day of the week. This spike often dominates the load in the whole week: etmoses

This is ugly and distracts the user (who should not be looking at artefacts of the initialisation but rather at the correct load further in the week.

I see two main ways to solve this issue:

  1. Initialise the buffers, EVs and batteries with half (or more?) of their volume filled
  2. To calculate an extra day (from the previous week) to let the system 'settle'.

Personally, I like option 2 better but it is technically more challenging (I think) as you need to make an exception for the first week of January. Also, the caching needs to be adjusted.

@antw @grdw can you make an estimate of how much time these two options would take to implement?

ChaelKruip commented 8 years ago

Including @dennisschoenmakers @Sanne512

antw commented 8 years ago

Starting buffers half-full is super-easy: a couple of hours once you add in some time for testing.

Computing an extra day is certainly more work, but I agree it's the more correct option. We'd provide the calculator with a profile containing eight days of data instead of seven, and then chop off the first day. Presumably for the first week of January we'd use profiles for 31st December as the "initialisation day".

antw commented 8 years ago

I took a quick look into this. The spike at the start of the week is not just because the storage is empty, but because it is permitted to take energy from the grid. Technologies which cannot take from the grid also produce an effect (provided there is an excess of local production), but don't result in a sudden load spike.

Starting the time period with buffers half full doesn't eliminate the anomaly; it just halves its duration. We'd have to start with buffers completely full to resolve this.

A compromise might be to start half full when a tech may only charge using local excess, and completely full when it can use the HV network. Feels like an awkward solution though, since there'd be no way for a visitor to know this was happening except by reading documentation.

I'm leaning towards the harder solution of calculating eight days – a warmup day, and seven "real" days – then chopping off the warmup data.

ChaelKruip commented 8 years ago

I'm leaning towards the harder solution of calculating eight days – a warmup day, and seven "real" days – then chopping off the warmup data.

Me too. Putting this on-hold until we have planned it into a sprint.

dennisquintel commented 8 years ago

I'm leaning towards the harder solution of calculating eight days – a warmup day, and seven "real" days – then chopping off the warmup data.

We might also consider doing this for the yearly calculations while we're at it? It reduces the weird behaviour in week 1.

ThomBuijs commented 8 years ago

When is the fix for this expected. Or is there a workaround available?

ChaelKruip commented 8 years ago

When is the fix for this expected.

This is not planned yet.