backbone issueshttps://gitlab.vtt.fi/backbone/backbone/-/issues2022-05-18T12:52:28Zhttps://gitlab.vtt.fi/backbone/backbone/-/issues/178q_capacityMargin: Add an option for coefficient for consumption units2022-05-18T12:52:28ZTomi J. Lindroosq_capacityMargin: Add an option for coefficient for consumption unitsq_capacityMargin has following section:
// Conversion unit inputs might require additional capacity
+ sum(gnu_input(grid, node, unit),
+ v_gen(grid, node, unit, s, f, t)
) // END sum(gnu_input)
Batteries and o...q_capacityMargin has following section:
// Conversion unit inputs might require additional capacity
+ sum(gnu_input(grid, node, unit),
+ v_gen(grid, node, unit, s, f, t)
) // END sum(gnu_input)
Batteries and other storage chargers are automatically calculated in here. There should be an option to include availabilityCapacityMargin also for gnu_input parts of this constraint.https://gitlab.vtt.fi/backbone/backbone/-/issues/177r_gnuUtilizationRate crashes if unitSize is zero2022-05-02T12:53:00ZTomi J. Lindroosr_gnuUtilizationRate crashes if unitSize is zeroNo check if unitSize is zero. It should not be, but causes a crash if input data has flaws
= r_gnuTotalGen(grid, node, unit)
/ [
+ (p_gnu(grid, node, unit, 'capacity') + r_invest(unit)*p_gnu(grid, nod...No check if unitSize is zero. It should not be, but causes a crash if input data has flaws
= r_gnuTotalGen(grid, node, unit)
/ [
+ (p_gnu(grid, node, unit, 'capacity') + r_invest(unit)*p_gnu(grid, node, unit, 'unitSize'))
* (mSettings(m, 't_end') - (mSettings(m, 't_start') + mSettings(m, 't_initializationPeriod')) + 1)
* mSettings(m, 'stepLengthInHours')
]; // END divisionhttps://gitlab.vtt.fi/backbone/backbone/-/issues/176Conflicting definitions of v_state upbound in 2d and 3d2022-05-02T10:17:52ZTomi J. LindroosConflicting definitions of v_state upbound in 2d and 3d2d_constraints defines q_stateUpwardLimit as constant + timeseries + invest*upperLimitCapacityRatio
![image](/uploads/3bd9a71997375e3cfa6bab43e9dbfc71/image.png)
but 3d_setVariableLimit defines v_state up bound from only the constan...2d_constraints defines q_stateUpwardLimit as constant + timeseries + invest*upperLimitCapacityRatio
![image](/uploads/3bd9a71997375e3cfa6bab43e9dbfc71/image.png)
but 3d_setVariableLimit defines v_state up bound from only the constant or variable upwardLimit
![image](/uploads/1ac0c49a91dcaffbbf0b5c4cec0f26be/image.png)
These definitions should be alignedTomi J. LindroosTomi J. Lindrooshttps://gitlab.vtt.fi/backbone/backbone/-/issues/174Possible mistake in calculating variable costs in the result outputs2022-05-02T09:57:58ZJuha KiviluomaPossible mistake in calculating variable costs in the result outputsErkka has had trouble getting expected results in his hydro power simulations. Based on those results, the problem could be in the variable costs. So, I tried to run through the numbers and it appears that there is a mistake in the way t...Erkka has had trouble getting expected results in his hydro power simulations. Based on those results, the problem could be in the variable costs. So, I tried to run through the numbers and it appears that there is a mistake in the way the variable costs are calculated for unit inputs. The code is from tag v2.0 that Erkka is using.
First, here are the assumptions
```
vomCost = 1
p_price = 10
p_unitEmissionCost = 100
p_stepLength = 1
case a) v_gen for input node = 1
case b) v_gen for input node = -1
```
Then how objective function calculates - including pre-processing
```
From 3c_inputsLoop.gms:
// Node price time series
ts_vomCost_(gnu(grid, node, unit), tt_interval(t))
= + p_gnu(grid, node, unit, 'vomCosts')
// input node cost
+ (
+ p_price(node, 'price')$p_price(node, 'useConstant')
+ sum(tt_aggcircular(t, t_), ts_price(node, t_))$p_price(node, 'useTimeSeries')
/ mInterval(mSolve, 'stepsPerInterval', counter)
)$gnu_input(grid, node, unit)
// output node cost (if price > 0 --> ts_vomCost_ < 0, i.e. considered as revenue)
- (
+ p_price(node, 'price')$p_price(node, 'useConstant')
+ sum(tt_aggcircular(t, t_), ts_price(node, t_))$p_price(node, 'useTimeSeries')
/ mInterval(mSolve, 'stepsPerInterval', counter)
)$gnu_output(grid, node, unit)
// emission cost
+ sum(emission$p_unitEmissionCost(unit, node, emission), // Emission taxes
+ p_unitEmissionCost(unit, node, emission)
); // END sum(emission)
With my example data:
a & b)
= 1 + 10 + 100
= 111
From 2c_objective.gms:
+ p_msft_probability(m, s, f, t)
* p_s_discountFactor(s) // Discount costs
* [
// Time step length dependent costs
+ p_stepLength(m, f, t)
* [
// Variable O&M costs for inputs
- sum(gnuft(grid, node, unit, f, t)$gnu_input(grid, node, unit),
+ v_gen(grid, node, unit, s, f, t)
* ts_vomCost_(grid, node, unit, t)
) // END sum(gnuft)
// Variable O&M costs
+ sum(gnuft(grid, node, unit, f, t)$gnu_output(grid, node, unit),
+ v_gen(grid, node, unit, s, f, t)
* ts_vomCost_(grid, node, unit, t)
) // END sum(gnuft)
With my example data:
a)
= p_msft_probability (assume 1)
* p_s_discountFactor (assume 1) (SIDE NOTE: THIS IS NOT IN THE OUTPUT VARIABLE COST CALCULATIONS!)
* 1 (p_stepLength)
* - 1 (v_gen for input)
* 111
= -111
b)
= 1 (p_msft_probability)
* 1 (p_s_discountFactor)
* 1 (p_stepLength)
* - -1 (v_gen for input)
* 111
= +111
```
Then based on the result calculations:
```
// Unit generation and consumption
r_gen(gnuft(grid, node, unit, f, startp(t)))$sft_realized(s, f, t)
= v_gen.l(grid, node, unit, s, f, t)
;
a) 1
b) -1
// for performance, get rid of any zeros in r_gen and r_reserve. Many zero values missing anyway.
r_gen(gnu, f, t)$((r_gen(gnu, f, t)=0)$r_gen(gnu, f, t))=0;
// Variable O&M costs
r_gnuVOMCost(gnu(grid, node, unit), ft_realizedNoReset(f,startp(t)))
= 1e-6 // Scaling to MEUR
* p_stepLengthNoReset(m, f, t)
* abs(r_gen(grid, node, unit, f, t))
* p_gnu(grid, node, unit, 'vomCosts');
a & b)
= 1 * 1 * 1
= 1
// Fuel and emission costs during normal operation
// Note that this result calculation uses ts_price directly while the
// objective function uses ts_price average over the interval. There can
// be differences if realized intervals contain several time steps.
r_uFuelEmissionCost(gnu(grid, node, unit), ft_realizedNoReset(f,startp(t)))
= 1e-6 // Scaling to MEUR
* p_stepLengthNoReset(m, f, t)
* abs(r_gen(grid, node, unit, f, t))
* [ + p_price(node, 'price')${p_price(node, 'useConstant') and gnu_input(grid, node, unit)}
+ ts_price(node, t)${p_price(node, 'useTimeSeries') and gnu_input(grid, node, unit)}
- p_price(node, 'price')${p_price(node, 'useConstant') and gnu_output(grid, node, unit)}
- ts_price(node, t)${p_price(node, 'useTimeSeries') and gnu_output(grid, node, unit)}
// Emission costs
+ sum(emission, p_unitEmissionCost(unit, node, emission))
];
a & b)
= 1 * 1 * (10 + 100)
= 111
vom + fuel/emission = 111
```
So, in the outputs, the result is always 111, but in objective function positive v_gen leads to -111 while negative v_gen leads to +111. I hope Erkka can check my calculations. The same problem is probably also on the output side - negative v_gen becomes positive in results.Erkka Rinneerkka.rinne@iki.fiErkka Rinneerkka.rinne@iki.fihttps://gitlab.vtt.fi/backbone/backbone/-/issues/169ts_node is ignored in the objective function (bug?)2022-01-28T12:48:09ZTonits_node is ignored in the objective function (bug?)We describe the issue through an example. If we set the following symbols:
```
ts_node(grid, node, 'balancePenalty', f, t) = 10; (A)
p_gnBoundaryPropertiesForStates('elec', 'link_node', 'balancePenalty', 'useTimeSeries') = 1 ; (B)
```
t...We describe the issue through an example. If we set the following symbols:
```
ts_node(grid, node, 'balancePenalty', f, t) = 10; (A)
p_gnBoundaryPropertiesForStates('elec', 'link_node', 'balancePenalty', 'useTimeSeries') = 1 ; (B)
```
then we expect it to have an impact on the objective function, however, this is not case because of the following:
2c_objective.gms
```
+ sum(gn(grid, node),
+ vq_gen(inc_dec, grid, node, s, f, t)
*( PENALTY_BALANCE(grid, node)${not
+ ts_node_(grid, node, 'balancePenalty', s, f,
)
) // END sum(gn)
```
1e_inputs.gms
```
// Nodes with states
gn_state(grid, node)${ gn_stateSlack(grid, node)
or p_gn(grid, node, 'energyStoredPerUnitOfState')
or sum((stateLimits, useConstantOrTimeSeries), p_gnBoundaryPropertiesForStates(grid, node, stateLimits, useConstantOrTimeSeries))
or sum(useConstantOrTimeSeries, p_gnBoundaryPropertiesForStates(grid, node, 'reference', useConstantOrTimeSeries))
}
= yes;
// Existing grid-node pairs
gn(grid, node)${ sum(unit, gnu(grid, node, unit))
or gn_state(grid, node)
or sum((f, t), ts_influx(grid, node, f, t))
or sum(node_, gn2n(grid, node, node_))
or sum(node_, gn2n(grid, node_, node))
or sum(node_, gnn_state(grid, node, node_))
or sum(node_, gnn_state(grid, node_, node))
}
= yes;
```
Hence, setting (B) will not affect gn_state and eventually gn. As a workaround one can set, e.g.:
```
p_gnBoundaryPropertiesForStates('elec', 'link_node','upwardLimit','useTimeSeries') = 1E50;
```
, then we will observe that the values in (A) appears in objective function.
Additional information
```
p_gnBoundaryPropertiesForStates(grid, node, param_gnBoundaryTypes, param_gnBoundaryProperties)
param_gnBoundaryTypes "Types of boundaries that can be set for a node with a state variable" /
upwardLimit "Absolute maximum state of the node (unit of measure depends on energyStoredPerUnitOfState)"
downwardLimit "Absolute minimum energy in the node (unit of measure depends on energyStoredPerUnitOfState)"
upwardSlack01*upwardSlack20 "A threshold after which a specific cost co-efficient is applied (unit of measure depends on energyStoredPerUnitOfState)"
downwardSlack01*downwardSlack20 "A threshold after which a specific cost co-efficient is applied (unit of measure depends on energyStoredPerUnitOfState)"
reference "Reference value for a state that can be used to bound a state (unit of measure depends on energyStoredPerUnitOfState)"
maxSpill "Maximum spill rate from the node (MWh/h)"
minSpill "Minimum spill rate from the node (MWh/h)"
balancePenalty "Penalty value for violating the energy balance of that particular node (EUR/MWh) (can be interpretated as the energy price in certain settings)"
/
```
perhaps, one can define a subset
param_gnBoundaryTypes_gn_state(param_gnBoundaryTypes) that ensures that if any of the values in the set are defined, then it will affect the objective function.Topi RaskuTopi Rasku2022-04-29https://gitlab.vtt.fi/backbone/backbone/-/issues/168Improving naming and definition of sets/parameters2022-01-21T06:26:00ZTomi J. LindroosImproving naming and definition of sets/parametersThe naming logic of sets/parameters is a bit ambiguous or illogical in some cases.
* suft(effSelector, unit, f, t) and sft(s, f, t)
* effGroup(effSelector) is not a group as defined in 'group' set. Typically sets named e.g. sGroup(s...The naming logic of sets/parameters is a bit ambiguous or illogical in some cases.
* suft(effSelector, unit, f, t) and sft(s, f, t)
* effGroup(effSelector) is not a group as defined in 'group' set. Typically sets named e.g. sGroup(s, group)
* up_down(param_policy) / up, down /; as a subset leads to unintuitive definition of reserve capabilities and requirementshttps://gitlab.vtt.fi/backbone/backbone/-/issues/166diag option uses old set indexes2022-01-04T15:34:25ZTomi J. Lindroosdiag option uses old set indexesusing run setting diag=yes crashes the model
* several r_gen(node, unit, f, t) in equations,
* should be r_gen(grid, node, unit, f, t)using run setting diag=yes crashes the model
* several r_gen(node, unit, f, t) in equations,
* should be r_gen(grid, node, unit, f, t)https://gitlab.vtt.fi/backbone/backbone/-/issues/164Integration with pyam-iamc2021-12-07T08:25:42ZJuha KiviluomaIntegration with pyam-iamcpyam-iamc provides a web-interface for browsing results. This can be especially useful for policy related work where there is an audience for the results that would like to explore the results themselves. It should be quite straightforwa...pyam-iamc provides a web-interface for browsing results. This can be especially useful for policy related work where there is an audience for the results that would like to explore the results themselves. It should be quite straightforward to make an exporter in Spine Toolbox for this purpose when someone has the need for it. More info at: https://pyam-iamc.readthedocs.io/en/stable/Wishlisthttps://gitlab.vtt.fi/backbone/backbone/-/issues/152Improve total compilation and execution time2021-11-22T11:48:34ZNiina HelistöImprove total compilation and execution timeThe suggestions made by Antti Lehtilä have been implemented in commits 1ff03e610db6cfcf7401c2c32695db3bef01829f, 3c38c83349c331683c4cc2834c44628af1ebbea9, and 2d671e000d29a3fdbccef8445916d52693a589a8. An additional attempt to improve the...The suggestions made by Antti Lehtilä have been implemented in commits 1ff03e610db6cfcf7401c2c32695db3bef01829f, 3c38c83349c331683c4cc2834c44628af1ebbea9, and 2d671e000d29a3fdbccef8445916d52693a589a8. An additional attempt to improve the execution time was made in commit c9f41b92e71bc7d18cfd1524b76265a5b5333090.
In 3c_inputsLoop.gms, tt_aggregate is still used instead of the apparently faster tt_aggcircular in several calculations: ts_cf_, ts_node_, ts_gnn_, and ts_storageValue_. It would be good to check if these can also be improved by using tt_aggcircular.v2.1https://gitlab.vtt.fi/backbone/backbone/-/issues/150Custom increment for the z index2021-11-22T11:47:32Zjussi ikäheimoCustom increment for the z indexImplement a custom increment for the z (candidate period) index so that it is not necessarily ordered in time according to natural numbers. Thus there would be a parameter dz, which tells the increment, similarly to dt.Implement a custom increment for the z (candidate period) index so that it is not necessarily ordered in time according to natural numbers. Thus there would be a parameter dz, which tells the increment, similarly to dt.v3.0jussi ikäheimojussi ikäheimohttps://gitlab.vtt.fi/backbone/backbone/-/issues/149Add results table for N-1 reserves from transfer links2021-12-02T10:54:21ZTomi J. LindroosAdd results table for N-1 reserves from transfer linksr_resDemandLargestInfeedTransfer missing from the results filer_resDemandLargestInfeedTransfer missing from the results filev2.1https://gitlab.vtt.fi/backbone/backbone/-/issues/145Time resolution treated wrong in ramp constraints2021-11-22T11:52:46ZJuha KiviluomaTime resolution treated wrong in ramp constraints@danakirchem reported a bug with the treatment of time resolution in the ramp constraints. It works fine for hourly time resolution, but will not work correctly if the time resolution changes from that. v_genRamp should be divided by p_s...@danakirchem reported a bug with the treatment of time resolution in the ramp constraints. It works fine for hourly time resolution, but will not work correctly if the time resolution changes from that. v_genRamp should be divided by p_stepLength, but it wasn't. Dana will implement the fix.v2.1Niina HelistöNiina Helistöhttps://gitlab.vtt.fi/backbone/backbone/-/issues/144Time series coefficients for p_unitConstraintNode2021-11-22T11:51:25ZDana KirchemTime series coefficients for p_unitConstraintNodeCoefficient in p_unitConstraintNode can determine the relationship between multiple inputs or outputs of a node according to a fixed coefficient. commits 9390e03f222c469aebf848b95e6c4b8f1e33f018 , ffa8277f0b569e57a5a0a59984be4033daf1f933...Coefficient in p_unitConstraintNode can determine the relationship between multiple inputs or outputs of a node according to a fixed coefficient. commits 9390e03f222c469aebf848b95e6c4b8f1e33f018 , ffa8277f0b569e57a5a0a59984be4033daf1f933 , fb6bcd58323d81d6670bb19b4372623d4d326bfa and d4689f544010e00fb4be6f30e1ed385699de8bc8 introduce a flag for using a times series for this coefficient and the new parameter ts_unitConstraintNode.v3.0Dana KirchemDana Kirchemhttps://gitlab.vtt.fi/backbone/backbone/-/issues/143Bi-directional diffusion co-efficient2021-11-22T11:45:23ZJuha KiviluomaBi-directional diffusion co-efficientCurrently there is only one co-efficient for a diffusion between two nodes. However, this co-efficient can be different in the two different directions in some applications. @danakirchem has implemented this in her wastewater branch.Currently there is only one co-efficient for a diffusion between two nodes. However, this co-efficient can be different in the two different directions in some applications. @danakirchem has implemented this in her wastewater branch.v3.0Juha KiviluomaJuha Kiviluomahttps://gitlab.vtt.fi/backbone/backbone/-/issues/142Storage units providing reserve during several time steps2021-11-22T11:49:28ZNiina HelistöStorage units providing reserve during several time stepsShould more time intervals of reserve provision be considered in the state constraints? For example, should a unit with storage be able to provide upward reserve for three (or 12 or 8760) consecutive hours without getting empty?Should more time intervals of reserve provision be considered in the state constraints? For example, should a unit with storage be able to provide upward reserve for three (or 12 or 8760) consecutive hours without getting empty?v2.1https://gitlab.vtt.fi/backbone/backbone/-/issues/128Get rid of p_gnReserves2021-11-22T11:43:42ZJuha KiviluomaGet rid of p_gnReservesReserves are nowadays based on p_groupReserves. However, we are still using p_gnReserves in the code for convenience. It is obfuscating to have p_gnReserves in the debug.gdx and in the code - we should replace all cases of p_gnReserves w...Reserves are nowadays based on p_groupReserves. However, we are still using p_gnReserves in the code for convenience. It is obfuscating to have p_gnReserves in the debug.gdx and in the code - we should replace all cases of p_gnReserves with something more transparent (might be enough to check if the unit can provide reserve).v2.1Juha KiviluomaJuha Kiviluomahttps://gitlab.vtt.fi/backbone/backbone/-/issues/126Different values for boundStart and boundEnd not possible2020-08-17T10:22:13ZDana KirchemDifferent values for boundStart and boundEnd not possibleIf flags are selected in p_gn (e.g. boundStart, boundEnd, boundAll,...), values can only be assigned uniformly via 'reference' in p_gnBoundaryPropertiesForStates. It should be possible to assign different reference values.If flags are selected in p_gn (e.g. boundStart, boundEnd, boundAll,...), values can only be assigned uniformly via 'reference' in p_gnBoundaryPropertiesForStates. It should be possible to assign different reference values.WishlistDana KirchemDana Kirchemhttps://gitlab.vtt.fi/backbone/backbone/-/issues/125Renaming results2022-01-07T11:49:41ZJuha KiviluomaRenaming resultsAs I've been looking at the results for the RPG paper, I've felt the results could be named in more useful manner. I tend to look at the results mostly in GAMSIDE, where they are in alphabetical order. When I'm looking for e.g. cost resu...As I've been looking at the results for the RPG paper, I've felt the results could be named in more useful manner. I tend to look at the results mostly in GAMSIDE, where they are in alphabetical order. When I'm looking for e.g. cost results I'd like to have all cost results near each other.
Another matter is that right now we sometimes have dimensions named in the parameter name and sometimes not (e.g. r_gen is not r_gnu_gen as one might assume).
Hence, I'd propose something like:
```
r_cost_gn
r_cost_gnu
r_cost_unittype_invest
r_cost (total cost)
...
r_gen_gnFuel
r_gen_gnu
...
```
Maybe this should be made together with the v_gen --> v_flow change.WishlistJuha KiviluomaJuha Kiviluomahttps://gitlab.vtt.fi/backbone/backbone/-/issues/118q_genRamp probably creating constraints for unnecessary units2021-11-22T11:44:49ZJuha Kiviluomaq_genRamp probably creating constraints for unnecessary unitsv2.1Juha KiviluomaJuha Kiviluomahttps://gitlab.vtt.fi/backbone/backbone/-/issues/114Tighter and more compact formulation of unit commitment equations2021-11-22T11:46:46ZJuha KiviluomaTighter and more compact formulation of unit commitment equationsThe aim is to speed up integer decisions using state-of-the-art UC formulations
- good source is http://www.optimization-online.org/DB_HTML/2018/11/6930.html and related work
- Covers e.g. unit state (on/off/start) variables, start costs...The aim is to speed up integer decisions using state-of-the-art UC formulations
- good source is http://www.optimization-online.org/DB_HTML/2018/11/6930.html and related work
- Covers e.g. unit state (on/off/start) variables, start costs, ramps, piecewise linear production costs
- We should identify which formulations we are using and how to change to a better configuration
- We should aim to make the configurations selectable (even so that different units can use different formulations as currently, but expanded)
Would partially address #13.Wishlist