GitLab

Fixing a bug in ramp tier limits: For units with shutdown trajectories, the ramp tier limit was twofold at the interval when the shutdown begins.

Resolved conflicts in inc/2d_constraints.gms (e.g. start-up and shutdown variables).

Adding an example of a post-processing file: 4d_postProcess_invest2schedule_temp.gms. The contents of the file can be copied to a 4d_postProcess.gms file and saved in the input folder so that it is read by Backbone. The contents of the file is meant for saving the invest model results in a format that can be directly used by the schedule model. The results transfer works when running Backbone using Titan and when the schedule setup is a child of the invest setup in the Titan setup tree. The invest model writes and outputs a changes.inc file which is then read by the schedule model.

# Conflicts:
#	inc/3c_inputsLoop.gms

#65: *v_startup* divided into *v_startup_LP* and *v_startup_MIP* variants to avoid undesired behavior when using integer online variables.

Replacing *IntervalStepCounter* with *tt_aggregate* due to the poor performance of *intervalStepCounter*.

*intervalStepCounter* now uses (counter, t) instead of (counter, counter_) due to the counter set being too limited in size.

Some time steps in the initial sample where also linked to the central sample.

Commenting out a couple *v_startup* and *v_shutdown* limits due to them being extremely slow, and not strictly necessary.

The removed limits only aim to ensure that no startup and shutdown is performed if the unit online variable horizon doesn't extend far enough to cover the consequences. This is already ill-adviced, but should'nt have a significant impact on the model anyhow.

Rewriting large portions of *3c_inputsLoop.gms* to make it more compact, and hopefully increasíng performance as well.

Also a minor speedup for setting model dimension (set `msft` etc.)

Changed behaviour of `mSetting` 't_perfectForesight' so that it’s defined from zero (not after 't_jump')

The setting does not have any effect if 't_perfectForesight' is less than 't_jump'.

Allow perfect foresight beyond realization horizon

See merge request !5

New model setting `t_perfectForesight` gives number of time steps after `t_jump` where realization foreast is used