backbone issueshttps://gitlab.vtt.fi/backbone/backbone/-/issues2024-03-22T11:55:32Zhttps://gitlab.vtt.fi/backbone/backbone/-/issues/263add ts_node_vert and similar options for prices2024-03-22T11:55:32ZTomi J. Lindroosadd ts_node_vert and similar options for pricesCurrently user can give 2+ year data of ts_cf and ts_influx via ts_cf_vert and ts_influx_vert, but similar options should be added for other time series.Currently user can give 2+ year data of ts_cf and ts_influx via ts_cf_vert and ts_influx_vert, but similar options should be added for other time series.https://gitlab.vtt.fi/backbone/backbone/-/issues/262merge categories in objective2024-03-15T14:43:51ZTomi J. Lindroosmerge categories in objectiveUnit FOM cost could include emission FOM cost instead calculating them separately, as well as investment cost the invEmissionCostUnit FOM cost could include emission FOM cost instead calculating them separately, as well as investment cost the invEmissionCosthttps://gitlab.vtt.fi/backbone/backbone/-/issues/259rethink and update param_gn, param_gnBoundaryTypes, and param_gnBoundaryPrope...2024-02-27T12:20:31ZTomi J. Lindroosrethink and update param_gn, param_gnBoundaryTypes, and param_gnBoundaryPropertiesparam_gn, param_gnBoundaryTypes, and param_gnBoundaryProperties need rethinking and update.
Some problems:
* Different activation logic -> upwardLimit, downwardLimit, maxSpill do not require separate activation, but boundXX require sepa...param_gn, param_gnBoundaryTypes, and param_gnBoundaryProperties need rethinking and update.
Some problems:
* Different activation logic -> upwardLimit, downwardLimit, maxSpill do not require separate activation, but boundXX require separate activation
* BoundaryTypes are split between p_gn and param_gnBoundaryTypes, e.g. boundStart is declared in p_gn, but upwardLimit in param_gnBoundaryTypes
* reference is boundaryType instead of BoundryProperty. Currently it is impossible to use two different reference values
* 3d_setVariableLimits uses ts_node or ts_node_ depending on the case. Proper fix would likely require different aggregation methods
Some ideas:
* Should param_gnBoundaryTypes be instead a dimension gnBoundaryType? And param_gnBoundaryProperties -> param_gnBoundaryType. Then ts_node would be **ts_node(grid, node, gnBoundaryType, param_gnBoundaryType)**
* Different aggregation methods could be under param_gnBoundaryType, either switches or aggregationMethod = [1-4] style with 1 (average) as default.
* param_gn could include constant influx? Or influx could be one of the params in general and then have constant or ts values?
* is storageValueUseTimeSeries necessary? Could it be active if data exists and storage value model property is activated?
![image](/uploads/bb1c71f9ce66e33886505590fe8e1a61/image.png)v4.0https://gitlab.vtt.fi/backbone/backbone/-/issues/258Delayed dynamics across converging forecasts2024-02-21T07:40:39ZTomi J. LindroosDelayed dynamics across converging forecasts**Delayed dynamics (e.g. startup/shutdown categories, and startup/shutdown times) across converging forecasts:** In simulations containing multiple forecasts `f` converging into the central forecast `mf_central` at some point in the mode...**Delayed dynamics (e.g. startup/shutdown categories, and startup/shutdown times) across converging forecasts:** In simulations containing multiple forecasts `f` converging into the central forecast `mf_central` at some point in the modeled horizon, only the `mf_central` is used to enforce constraints with delayed dynamics across the forecast converging boundary. The following figure attempts to illustrate the issue, if **blue represents a required downtime** of a unit in the central forecast, the **red downtime technically violates it** since it is not subject to a similar constraint (the *Forecast 2* branch "ends" when they converge, and no minimum downtime is enforced). Another way to handle this might be to require that no forecast branches violate these types of delayed dynamics across the forecast convergence boundary, but that would require significant redoing of the forecast-time structure.
![image](/uploads/32d254fde566ced6e4410c7fb2a50a30/image.png)Wishlisthttps://gitlab.vtt.fi/backbone/backbone/-/issues/257minor updates for v4.02024-03-26T12:01:10ZTomi J. Lindroosminor updates for v4.0Collecting a list of minor breaking changes for v4.0
- ms_central, used in one specific place. Check if really needed now when scenarios are gone.
- param_unit, param_gnn names
- outputCapacityTotal is unused
- unitOutputCapacityTotal is...Collecting a list of minor breaking changes for v4.0
- ms_central, used in one specific place. Check if really needed now when scenarios are gone.
- param_unit, param_gnn names
- outputCapacityTotal is unused
- unitOutputCapacityTotal is unused
- p_u_maxOutputInLastRunUpInterval is unused
- p_u_maxRampSpeedInLastRunUpInterval is unused
- p_u_maxOutputInFirstShutdownInterval is unusedv4.0https://gitlab.vtt.fi/backbone/backbone/-/issues/255move reserves from gn_forecasts to group_forecasts/reserve_forecasts2024-02-27T12:01:00ZTomi J. Lindroosmove reserves from gn_forecasts to group_forecasts/reserve_forecastsReserves are now group property and should be moved away from gn_forecasts
* current situation requires complicated sums, such as `df_realization_t(f, t)${not sum(gnGroup(grid, node, group), gn_forecasts(restype, node, 'ts_reserveDemand'...Reserves are now group property and should be moved away from gn_forecasts
* current situation requires complicated sums, such as `df_realization_t(f, t)${not sum(gnGroup(grid, node, group), gn_forecasts(restype, node, 'ts_reserveDemand'))}`
* such sums could be easily replaced with group_reservesv4.0https://gitlab.vtt.fi/backbone/backbone/-/issues/253updated ts_price and ts_priceChange logic2024-02-12T07:13:05ZTomi J. Lindroosupdated ts_price and ts_priceChange logicCurrently
- user must choose between ts_price and ts_priceChange
- single value in ts_price is given for the whole data serie
- singe value in ts_priceChange is given for the whole data serie
Should we update the logic to following
- t...Currently
- user must choose between ts_price and ts_priceChange
- single value in ts_price is given for the whole data serie
- singe value in ts_priceChange is given for the whole data serie
Should we update the logic to following
- ts_priceChange is added to ts_price
- single value in ts_price is actually a single value
- singe value in ts_priceChange is activated only from that hour onwards
This is a breaking change and cannot be implemented in 3.xv4.0https://gitlab.vtt.fi/backbone/backbone/-/issues/252Add unitConstraints for groups of units2024-02-08T11:48:54ZTomi J. LindroosAdd unitConstraints for groups of unitsThe new version of unitConstraints could be extended to groups of units, but should check first how much work it might requireThe new version of unitConstraints could be extended to groups of units, but should check first how much work it might requirehttps://gitlab.vtt.fi/backbone/backbone/-/issues/251add constant selfDischargeLoss2024-02-08T11:49:00ZTomi J. Lindroosadd constant selfDischargeLossAdd constant self dischargeloss in addition to current relative one. Ts version can already be implemented with ts_influx. Could be named p_influx?Add constant self dischargeloss in addition to current relative one. Ts version can already be implemented with ts_influx. Could be named p_influx?https://gitlab.vtt.fi/backbone/backbone/-/issues/249reserve ramping constraint2024-01-30T14:49:57ZTomi J. Lindroosreserve ramping constraintAdd reserve ramp variable and ramp constraintAdd reserve ramp variable and ramp constrainthttps://gitlab.vtt.fi/backbone/backbone/-/issues/248reserve vomCost2024-01-30T14:48:10ZTomi J. Lindroosreserve vomCostAdd reserve provision vomCost to unitsAdd reserve provision vomCost to unitshttps://gitlab.vtt.fi/backbone/backbone/-/issues/240constraint for min_max utilization rate2024-01-08T07:58:26ZTomi J. Lindroosconstraint for min_max utilization rateAdding a constraint for min_max utilization rate
* We currently have q_energyLimit
* should utilization rate limit be separate equation or expand the energyLimit by taking into account the capacity?Adding a constraint for min_max utilization rate
* We currently have q_energyLimit
* should utilization rate limit be separate equation or expand the energyLimit by taking into account the capacity?https://gitlab.vtt.fi/backbone/backbone/-/issues/239add grid dimension to r_gen_unitStartupConsumption_nuft2024-02-08T11:50:06ZTomi J. Lindroosadd grid dimension to r_gen_unitStartupConsumption_nuftAdd missing grid dimension to
r_gen_unitStartupConsumption_nuft
r_gen_unitStartupConsumption_nuAdd missing grid dimension to
r_gen_unitStartupConsumption_nuft
r_gen_unitStartupConsumption_nuv4.0https://gitlab.vtt.fi/backbone/backbone/-/issues/237Add min,fx,max constraints for v_gen and v_transfer2024-02-08T11:36:10ZTomi J. LindroosAdd min,fx,max constraints for v_gen and v_transferAdding min,fx,max constraints to v_gen and v_transfer requires at least following features
* constant min and max bound
* time series min and max bound
Few things need to be solved and tested
* if we need a new dummy variable in case ...Adding min,fx,max constraints to v_gen and v_transfer requires at least following features
* constant min and max bound
* time series min and max bound
Few things need to be solved and tested
* if we need a new dummy variable in case user gives infeasible input?
* Adding this feature without adding yet another useTimeseries flag
we should simplify the syntax to activate time series. Currently e.g. `param_unit` has
```plaintext
useTimeseries "A flag to use efficiency time series form input for unit parameters whenever possible (empty or 1)"
useTimeseriesAvailability "A flag to use availability time series form input for unit parameters whenever possible (empty or 1)"
```
As the number of ts_unit options increase, we could replace the current approach with a version where
* model checks what time series are given in ts_unit
* uses available time series
* user does not give any useTimeseries flags
In addition, few things with time series should be aligned in the model behaviour
* some time series are forcing, e.g. unit availability time series overrides constant availability when `useTimeseriesAvailability` is 1. Then 0 in time series is 0 to solver.
* Some time series are supplementing, e.g. ts_effUnit is used when available and otherwise p_effGroupUnit. In this case, model uses constant value if user gives 0 in time series. Eps in time series works
```plaintext
+ p_effGroupUnit(effGroup, unit, 'section')${not ts_effUnit_(effGroup, unit, effDirect, 'section', s, f, t)}
+ ts_effUnit_(effGroup, unit, effGroup, 'section', s, f, t)
```
We should agree one default behaviour, and build new features according to that. Other methods cannot be updated before 4.0 as it is a breaking update.https://gitlab.vtt.fi/backbone/backbone/-/issues/233rename r_gen_unitStartupConsumption2024-02-08T11:50:41ZTomi J. Lindroosrename r_gen_unitStartupConsumptionProbably more clear if `r_gen_unitStartupConsumption` is renamed to `r_start_consumption` or similarProbably more clear if `r_gen_unitStartupConsumption` is renamed to `r_start_consumption` or similarv4.0https://gitlab.vtt.fi/backbone/backbone/-/issues/232Add a parameter to fix node states at pre-defined time steps2023-11-22T07:48:06ZNiina HelistöAdd a parameter to fix node states at pre-defined time stepsFor long-term storage modelling (e.g. hydro reservoirs), it can be beneficial to be able to fix the node state at the end of the year. There hasn't been a parameter to do that in models with a rolling horizon.
A parameter called `boundS...For long-term storage modelling (e.g. hydro reservoirs), it can be beneficial to be able to fix the node state at the end of the year. There hasn't been a parameter to do that in models with a rolling horizon.
A parameter called `boundSumOverInterval` has now been added. If the flag is on (equals 1) and a timeseries reference is given for the node, the node state is fixed at each interval to the sum of the reference value at corresponding time steps. State is not fixed if a reference value is not given for the corresponding time steps (i.e. equals zero).
Reference timeseries are circulated. For example, if data length is 8760, values of time steps t8760 and t1 may be summed when using aggregated time steps. Should the timeseries not be circulated in this case?https://gitlab.vtt.fi/backbone/backbone/-/issues/230check that backbone.log is written if solve crashes2023-11-10T11:03:13ZTomi J. Lindrooscheck that backbone.log is written if solve crasheshttps://gitlab.vtt.fi/backbone/backbone/-/issues/229simplified batteries2023-11-09T07:12:43ZTomi J. Lindroossimplified batteriesWe should check how much additional code/features would be required to add simplified batteries.
Simplified batteries would make Backbone easier for new users and maybe speed up the work of experienced users. The biggest drawback would...We should check how much additional code/features would be required to add simplified batteries.
Simplified batteries would make Backbone easier for new users and maybe speed up the work of experienced users. The biggest drawback would be additional testing and maintenance.
A simplified battery might require negative v_gen that can become a showstopper.Wishlisthttps://gitlab.vtt.fi/backbone/backbone/-/issues/227new result tables for consumption and transfer losses2023-11-01T09:07:30ZTomi J. Lindroosnew result tables for consumption and transfer lossesResult tables for
* consumption: ts_influx at least, maybe also diffusion, selfdischarge, and gen
* transfer losses: for easier checking of balancesResult tables for
* consumption: ts_influx at least, maybe also diffusion, selfdischarge, and gen
* transfer losses: for easier checking of balanceshttps://gitlab.vtt.fi/backbone/backbone/-/issues/223aggregated units gets v_shutdown for the last non-aggregated timestep2023-10-11T12:02:15ZTomi J. Lindroosaggregated units gets v_shutdown for the last non-aggregated timestepSeems that aggregated units gets v_shutdown for the last non-aggregated timestep. Check if true and create an if condition to avoid this?
Seems that aggregator does not get start-up for the first time step it is active.Seems that aggregated units gets v_shutdown for the last non-aggregated timestep. Check if true and create an if condition to avoid this?
Seems that aggregator does not get start-up for the first time step it is active.