Create new parameters for the economic representation in the multi-year investments

[datejada]

Taking as a reference the changes in the file economic_structure in PR #448 we need:

• [x] List the new parameters and relationships with explanations in this issue
• [x] Create the new parameters and relationships with their defaults in the SpineOpt template
• [x] Create a new case study in JSON format from the template with data (maybe future use as the tutorial)
• [x] Create a new file with the economic representation and add the function from #448
• [x] Refactor the code as suggested in #448
• [x] Create the new tests for the economic representation
• [ ] Create migration script for renamed parameters

Notice that with this issue, we just create the parameters and calculations but we don't use them yet in the model

[manuelma]

Here it would be very useful to have a list of the parameters and their meaning.

[gnawin]

@manuelma most of the information is indeed in #476 but they can improved for sure. I can start by listing and explain things here, and later we see where the information is best placed. Note that they may be repetitive to what is there already in #476, but I agree at the moment it is important to explain more without worrying too much about being repetitive.

[manuelma]

Thank you @gnawin - I need to go through https://github.com/spine-tools/SpineOpt.jl/discussions/476 indeed.

[gnawin]

Below is a list of parameters and relationships for current design and the new design. More explanations (including a document with more details) are in discussion #476.

All below that apply to units also apply to storage and connection, but they are omitted for brevity.

Current design

Current parameters

unit_investment_lifetime

New design

Modified parameters

unit_investment_lifetime -> unit_investment_tech_lifetime

New parameters

User-defined parameters

• milestone years: use_milestone_years -> If set to true, the investment models uses milestone years. In other words, operational temporal blocks for one (milestone) year will be scaled up by the discounted duration to represent the entire investment period.

• discount: discount_rate, discount_year, unit_discount_rate_technology_specific

• lead time: unit_lead_time

• life time:unit_investment_economic_lifetime

• decommission: unit_decommissioning_time, unit_decommissioning_cost

Internally calculated parameters

• unit_capacity_transfer_factor(unit, stochastic_scenario, t_vintage, t) Check when a unit is available. The unit_capacity_transfer_factor is a Map parameter that holds the fraction of an investment during vintage year t_v in a unit u that is still available in the model year t

• unit_conversion_to_discounted_annuities(unit, stochastic_scenario, **t_vintage**) Translate the overnight costs of an investment into discounted (to the dicount_year) annual payments, distributed over the total lifetime of the investment. Investment payments are assumed to increase linearly over the lead time, and decrease linearly towards the end of the economic lifetime

• unit_salvage_fraction(unit, stochastic_scenario, **t_vintage**) The unrealised value beyond end of model horizon

• unit_tech_discount_factor(unit, stochastic_scenario, **t_vintage**) Instead of a common discount rate, we can use specific rates to calculate the discounted annual payments:

• unit_discounted_duration(unit, stochastic_scenario, **t_vintage**) Scale operational costs to the corresponding investment period, and discount them to the models discount_year

• unit_decommissioning_conversion_to_discounted_annuities(unit, stochastic_scenario, **t_vintage**) Similarly for discounting decommissioning costs

[gnawin]

Hi @manuelma, I have listed the relevant items for the current design vs the new design.

Maybe it's better that more developers see this, so whoever is more available can provide feedback so it can be merged quicker. So also @Tasqu, here is part of the epic issue for multi-year investment #908 (more detailed info is in discussion #476). The aim of this issue and the corresponding PR #929 is to create the necessary economic parameters (but not yet use them in the model). In later issues of #908, we will introduce them in the model step-by-step.

The tests are yet to be added but I'd like to hear your thoughts before I continue. We kind of arrange the epic issue #908 step-by-step, so it would be very helpful if you can let me know what you think so far. Thank you both very much!

[Tasqu]

I'm not especially experienced with investment optimisation, so I'm hardly the best person to comment on the formulation etc. I can comment on some aspects of the code and model structure, though. For example, in the above message, you claim:

New relationships

model__stochastic_structure: we currently only have default, but we need this to differentiate investment model__temporal_block: we currently only have default, but we need this to differentiate investment

As part of the new design. However, I'm a bit confused as those relationship classes already exist in SpineOpt. The model__default_... relationship classes are there solely for convenience, and the corresponding specific relationship classes are the more "fundamental ones". The default relationship classes are used only in cases where no specific relationships are defined.

I'm guessing you meant that you need to create new model__investment_stochastic_structure and model__investment_temporal_block relationship classes?

[DillonJ]

@manuelma correct me if I'm wrong, but the model_... relatioship classes were removed because they are not needed thanks to the simplification of the structure for using Benders.

The more fundamental relationships are unit_invesment_temporal_block which determines the temporal structure of the unit investments, which can be different for different units. model_dafault_investment_temporal_block will simply trigger creation of unit_invesment_temporal_block relationships where none exist.

[manuelma]

@manuelma correct me if I'm wrong, but the model_... relatioship classes were removed because they are not needed thanks to the simplification of the structure for using Benders.

The more fundamental relationships are unit_invesment_temporal_block which determines the temporal structure of the unit investments, which can be different for different units. model_dafault_investment_temporal_block will simply trigger creation of unit_invesment_temporal_block relationships where none exist.

Yes, this is entirely correct.

[gnawin]

Thank you very much @DillonJ @manuelma @Tasqu. I got the exact feedback I was looking for, indeed that was some legacy code and some misunderstanding of how they work. For our purpose, using model_dafault_investment_temporal_block and unit_investment_temporal_block should be enough. I changed the design accordingly.

If you have further comments regarding the design or whatever that you think would help that leads to the merge of the PR, that would be great!