DER VET User Guide/Model Details/Optimization Horizon

The optimization horizon refers amount of time series data available to a single optimization in DER-VET (see our documentation on perfect foresight optimization). This is set by the model parameter called "optimization window size" or "n" in our notation. This can be a year, a month, or some integer number of hours.

DER-VET always treats separate years as independent optimization problems and also can divide a single optimization year into several independent optimization windows. Doing so generally reduces the overall solve time of the model but reduces the optimality of the result. Breaking the year up into smaller segments requires additional constraints at the transitions between optimization windows that can conflict with other constraints or limit the value-generating potential of the DERs, depending on the timing of the transitions.

The optimization window size is required to be one full year when any DERs are being optimally sized by DER-VET, but can be adjusted when all DER sizes are know beforehand.

Constraints

In order for each optimization window to be independent, the state of the DERs (e.g. state of charge for a battery) at the beginning of each optimization window must be known before solving for that optimization window. DER-VET also constrains the state of the DERs at the end of the optimization window to be exactly what they were at the beginning of the optimization window. This means that storage system in the DER mix will start and end each optimization window with exactly the same SOC.

Note: It would have been possible to leave the state at the end of the optimization window floating, to be solved by the optimization and fed into the next optimization window as the starting state, but this would be equally arbitrary as the solution implemented in DER-VET, would have enabled less user control, and would usually result in storage system SOC reaching a minimum value at the end of each optimization window because this maximizes the energy value of the storage within the optimization window.

Best Practices

Divide a Year

Best practice dictates that the number of hours in an optimization window evenly divides the number of hours in the year. This ensures that all optimization windows are of a consistent length.

Optimization Window Transition Timing

No transition between optimization windows should occur during highly-sensitive times to avoid the (usually arbitrary) transition constraints interfering with the function of the DERs. In many cases, it is best to restrict the optimization window size to some multiple of 24 hours so that the optimization window transitions always occur at midnight (this is a relatively unimportant time for most applications).

Respect Energy Storage Duration

The optimization window size is most important when energy storage systems are included. (see also target SOC for documentation on handling optimization window transitions with energy storage) If a storage system cannot execute a full depth of discharge cycle within an optimization window, then it can not utilize its full energy capacity and its value will be artificially restricted. In general, a storage system should have the ability to execute several (or more) full depth of discharge cycles in every optimization window to avoid problems here.

Minimize Solve Time

The primary objective of reducing the optimization horizon is usually to reduce the overall time the model takes to run. This happens because the number of optimization variables being solved for concurrently is reduced linearly with reduced optimization horizon. The solve time of optimization problems of this type generally grows with the number of optimization variables faster than a linear relationship would, making it faster overall to solve several smaller problems. The magnitude of this effect depends on the exact problem being solved but can be strong enough to make the difference between a problem that is uselessly slow and a problem that solves in seconds or minutes.

It is difficult to estimate the solve time of an optimization problem before solving it and the need to solve a problem quickly varies from user to user, making the "best practice" an art more than a science. It is usually better to start simple in DER-VET, gradually increasing the problem's complexity, and only move on to a more complicated setup after achieving a solution to the simpler case. Not only will this help build intuition around the particular case but will also enable you to identify the change that causes a large increase in the solve time and address it appropriately. If you start with a complicated case and find yourself sitting around waiting for it to solve or iteratively decrease the complexity and start again only to give up before the problem solves, you will have no idea if your actions are making a difference and will have no reference for how long your case should take to solve. Only by starting simply with a case that solves quickly and building up can you take a methodical approach to the problem and save yourself the frustration.

Intentionally Reduce Optimality

In some cases, users have reduced the optimization window size specifically to reign in the perfect foresight assumption in DER-VET. An example of this might be when modeling a storage system participating in an hourly day-ahead energy market. The market itself is solved in 24-hour chunks and beyond 24 hours the ability of the storage system to accurately forecast energy prices might be less than ideal anyway. So, the user could set the optimization horizon to 24 hours. Doing so completely eliminates the storage system's ability to shift energy between days, which might be

Scenario Analysis

When in doubt, scenario analysis is recommended to uncover the sensitivity of the results to the optimization window size. If the optimization window size was selected arbitrarily or to reduce solve time, then the results should not be sensitive to the optimization window size. If they are, it is potentially a problem. Other model parameters may have to be changed to allow for longer optimization windows (to the point where the results are no longer sensitive to the optimization window size) despite their longer solve times.