Fix Cost Implementation

[oakca]

Usually energy-system-models have following costs for energy generators (for oemof case it is transformer-objects); investment costs, maintenance costs, and variable costs of the units.

With the investment-mode of oemof, investment costs are modeled. Variable costs can be defined also inside transformer-object. However; since for the maintenance costs there is none attribute in transformer-objects, you have to find an other way to implement them. One approach is shown in following code-piece (adding the maintenance costs to ep_costs):

solph.Transformer(label='coal',
    inputs={bus['coal']: solph.Flow(
        investment=solph.Investment(
            ep_costs=invest + maintenance,
            maximum=100000,
            existing=0),
        variable_costs=0.1)},
    outputs={bus['Elec']: solph.Flow()},
    conversion_factors={bus['Elec']: 0.75})

However in some cases this trick won't work. Assume you got a transformer, which has a maximum investment capacity of 100000 and existing capacity of 50000. If the demand can be satisfied by 50k power, then the model will not invest more of the transformer. So the ep_costs even after adding the maintenance costs will not matter, and you will not be able to calculate the maintenance costs of the power plant.

This is also important for the optimization. (e.g.: If the maintenance cost of a power plant is too expensive, maybe model will not invest in that power plant)

For the sake of the mentioned reasons, it would be best if the transformer objects have an attribute called fixed_costs, which eventually calculates amount of maintenance cost with multiplying the 'existing_capacity' and the `maintance_cost' of the power plant.

[uvchik]

I cannot see how adding fixed_cost will help to solve your problem, because existing_capacity * fixed_costs will always be the same and therefore won't affect the solution.

What you need is a shutdown attribute with cost you will save if the power plant is totally shut down (never used).

shutdown_total = shutdown_costs - maintenance

if shutdown_totalis negative you could have the case that an existing power plant is not used and a new one will be build instead due to a difference in maintenance costs.

At the moment we do not have something like this in oemof but you could implement that similar to the Investment object as an negative investment.

[jnnr]

In earlier versions of oemof, there has been a fixed_costs attribute. It was discussed and decided to be removed here PR396 and here PR407.

The argument was that in operational optimization, fixed costs do not enter the objective function. In investment optimization, fixed costs play a role. As I understand it, the common practice at the moment is to add them to the annualized investment costs and pass them as ep_costs to the InvestmentFlow, as both have the same unit [Eur/(MW*a)]. This can be confusing. Therefore I see 2 options:

• Keep combining both investment_costs and fixed_costs, but make clear that they both enter ep_costs. Maybe a different name?

• Reintroduce a fixed_cost attribute for investment optimization.

[oakca]

I cannot see how adding fixed_cost will help to solve your problem, because existing_capacity * fixed_costs will always be the same and therefore won't affect the solution.

This won't effect the optimization as you said. But it will change the value of the objective. Of course you can always manually add the maintenance costs in the end and calculate the objective. However, why bother doing this, if you can simply add the maintenance costs into the objective calculation?

What you need is a shutdown attribute with cost you will save if the power plant is totally shut down (never used). if shutdown_totalis negative you could have the case that an existing power plant is not used and a new one will be build instead due to a difference in maintenance costs.

Works, but this is only if you have the start-stop-binary variables in your model.

Finally, what about the following case:

Transformer1[invest] = 1500 € // Transformer1[fixed] = 100 €
Transformer2[invest] = 1000 €  // Transformer2[fixed] = 500 €

So if you have to invest one of the above transformers, and if you optimize for 1 year, then the model should choose Transformer2, but if you optimize for 2 years then the model should choose Transformer1, since the fixed cost of Transformer2 is way higher than Transformer1. With adding fix costs to ep_cost, you can't model this. Since the model won't think, that it needs to pay some costs for second year.

Year 1:
Transformer1 = 1500 + 100 €
Transformer2 = 1000 + 500 €

Year 2:
Transformer1 = 100€
Transformer2 = 500€

Total:
Transformer1 = 1700€
Transformer2 = 2000€

[jnnr]

After some discussion, I understand that the term equivalent periodical costs is meant to be quite general. If you check Wikipedia, you find equivalent annual costs that include maintenance:

https://en.wikipedia.org/wiki/Equivalent_annual_cost

[uvchik]

I understand your idea @oakca but solph is a very generalised framework, so it is always difficult to name the attributes. To use solph you need an application.

We decided to have just one attribute for each functionality. That means that we do not have two attributes that do the same. The following lines will illustrate that.

not oemof solph objective = .... + maintenance * invest1 + annuity * invest1 + ....

oemof.solph ep_costs = maintenance + annuity + ... objective = .... + ep_costs * invest1

On the application level you can easily add all the costs you want a calculate them to annual cost however you want.

[p-snft]

I see the point in both arguments. It is true that adding different options to implement on thing into the model decreases maintainability and adds confusion. Also, for the optimization, fixed costs are of course only relevant when investments are considered. Still, user-friendliness should also be considered. Take the following example:

total_costs = results_meta['objective'] + el_price_base + gas_price_base

As an alternative, one could add fixed_cost=el_price_base and fixed_cost=gas_price_base to the sources for electricity and gas, respectively. This way, all costs would be in results_meta['objective']. I tend to rate this second option more intuitive.

[uvchik]

This way, all costs would be in results_meta['objective']. I tend to rate this second option more intuitive.

In some cases the result of the objective function is equal to the total costs of the system, in these cases it would help to have a fixed_costs attribute.

On the other hand it caused confusion in the past especially together with investment objects. Different users found a different behaviour as 'intuitive'. That's why we removed it.

We came to the conclusion that it did more harm than good.

[p-snft]

Maybe, my confusion is due to the "objective-function-value-fetish".

[uvchik]

Maybe, my confusion is due to the "objective-function-value-fetish".

I do not understand, what confuses you, the phrase itself or the comment of @simnh?

[p-snft]

I have that fetish and feel that the objective value should have alls costs in.

[oakca]

I have that fetish and feel that the objective value should have alls costs in.

+1, and it makes the model comparisons easier... Otherwise you have to remove fix-costs from the other model.

[uvchik]

+1, and it makes the model comparisons easier... Otherwise you have to remove fix-costs from the other model.

That's right. If the objective function of the other model has fixed costs included you have to subtract them from this objective function or you have to add them to solph's objective function.

For the second variant you could add fixed_costs as a kwarg to the Flow, sum up all fixed_costs and add them to the objective function.

[jokochems]

This one has been pending for quite a while now.

I also like the idea of having an objective value reflecting full system costs (but excluding sunk costs). Therefore, I re-integrated it in the draft for #750 since especially for long-term optimization integrating fixed costs into ep_costs can become really tedious and also some kind of generalizability had to sacrificed on in #750. But I also pointed out that it has been decided to drop the fixed_costs back in the days.

[jokochems]

Maybe, a decision could be taken at the next dev meeting?

[brizett]

Hallo Johannes, liebe OEMOF-ler,

da ich inzwischen nicht mehr OEMOF arbeite, möchte ich mich gern vom Newletter und den Notifications abmelden. Ich erinnere mich jedoch nicht mehr an mein Github-Passwort und kann dies vom Homeoffice aus auch nicht nachvollziehen, da ich zudem nicht sicher bin, ob ich mit dieser Email-Adresse oder mit der auf unseren alten Institutsnamen laufenden angemeldet war (genauso wie diese, aber „iwes“ statt „iee“). Könntest Du/Ihr mich bitte manuell abmelden?

Vielen Dank und viele Grüße

Britta Zimmermann Gruppenleiterin Geschäftsmodelle und Marktintegration Fraunhofer-Institut für Energiewirtschaft und Energiesystemtechnik IEE FuE-Bereich Energiewirtschaft und Netzbetrieb Königstor 59, | 34119 Kassel Telefon: +49 561 7294-203 mailto:[email protected] http://www.iee.fraunhofer.dehttp://www.iee.fraunhofer.de/

Von: Johannes Kochems [email protected] Gesendet: Sonntag, 7. März 2021 17:27 An: oemof/oemof-solph [email protected] Cc: Subscribed [email protected] Betreff: Re: [oemof/oemof-solph] Fix Cost Implementation (#556)

Maybe, a decision could be taken at the next dev meeting?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/oemof/oemof-solph/issues/556#issuecomment-792305726, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHCT7VROSMPEELJ6CQMWR5LTCOSLZANCNFSM4GR262BQ.

[fwitte]

Moin @brizett,

meines Wissens kann der repository-owner/admin nicht den Notification-Status von anderen Personen ändern (jeder angemeldete GitHub Nutzer entscheidet selber, ob er einem öffentlichen Repo folgt oder nicht). Insofern wirst du darauf angewiesen sein, dir deinen Zugang zu GitHub zurück zu holen. Temporär würde ich mir einen entsprechenden Filter einrichten.

Was den Newsletter von oemof.org angeht gibt es in den E-Mails immer einen Link zum Austragen aus dem Newsletter. Ich weiß leider nicht, wie man Personen aus dem Newsletter austrägt, vielleicht kannst du helfen @p-snft?

Viele Grüße

[jokochems]

Maybe, a decision could be taken at the next dev meeting?

Has this been discussed in one of the sessions I missed? If not, should we have a poll on it or something like that? As I said, I'll be utilizing it for the MultiPeriodModel anyways and am a fan of having all cost terms included in the objective function, because postprocessing can become rather tedious and error prone if you have to add terms afterwards.

[p-snft]

We did not talk about this explicitly. (If MultiPeriodModel works well with just one period, this problem will be solved, won't it?)

[jokochems]

I guess, this issue can be closed due to the design decisions

• not to include fixed costs into standard investments modelling (see contributions from @uvchik above) as well as
• the design choice to re-integrate a fixed_costs argument only relevant for multi-period modelling and also raising a warning to create awareness.