Salvage value and the objective function

[ggretton]

We're trying to understand the components of the objective function, along the lines of a few previous forum posts including:

Linking the TIMES undiscounted cost outputs to the objective function (iea-etsap.org)

Using the switches $SET OBLONG YES and $SET ANNCOST LEV things are adding up nicely in a test model. In particular, all of the following add up to ObjZ:

* Discounted sums of Cost_Inv, Cost_Fom, and Cost_Flo
* Sums of Cost_NPV
* Discounted sums of Reg_ACost

The one thing that doesn't seem to fit with the manual (Part 2) is that the salvage value doesn't seem to be included in the objective function reported.

Are we missing something, or is this just the way ObjZ is reported?

[Antti-L]

Thanks for your question, even though I am somewhat confused by it.

I add some quotes from the documentation below that may be of help:

---------
Investments whose technical lives exceed the model’s horizon receive a SALVAGE value for the unused portion of their technical lives. Salvage applies to several types of costs: investment costs, sunk material costs, as well as decommissioning costs and surveillance costs.
[…]
What are the costs that should trigger a salvage value? The answer is: any costs that are directly or indirectly attached to an investment. These include investment costs and decommissioning costs. Fixed annual costs and variable costs do not require salvage values, since they are paid each year in which they occur, and their computation involves only years within the horizon.
[…]
The principle of salvaging is simple, and is used in other technology models such as MARKAL, etc: a technology with technical life TLIFE, but which has only spent x years within the planning horizon, should trigger a repayment to compensate for the unused portion TLIFE-x of its active life.
---------

The total salvage value thus corresponds to a credit for the (discounted) costs attributable to unused portion of the technical lives of investments, and as such, it is included in the objective function as a negative term. Only technologies whose life extends beyond EOH are credited with a salvage value.

So we can summarize the inclusion of the salvage values as follows:

  • Objz includes the salvage value, by excluding the portions of the investment-related costs attributable to the unused portions of their technical lives, by crediting back those portions of the costs. And Objz is reported as is, being exactly the value of that variable in the model solution.

  • The reported annualized costs (Cost_*) also implicitly include the salvage value, by excluding the portions of the investment-related costs attributable to the unused portions of their technical lives, because the annualized costs include only costs paid within the model horizon.

  • The reported total annual costs (Reg_ACost) also implicitly include the salvage value, by excluding the portions of the investment-related costs attributable to the unused portions of their technical lives, because the annual costs include only costs paid within the model horizon.

All annual costs are always reported only for the model periods. Any annualized investment payments falling beyond the model horizon are thus excluded, just like they are (in net terms) excluded also from the objective function (by first including them in the investment cost component and then subtracting the salvage values credited back). And so, in essence both cases are including the salvage values, either explicitly (Objz) or implicitly (annual costs).

Concerning Cost_NPV, there one might have chosen to report the salvage values also in a separate component. But also in that case the total sum should of course be equal to Objz, whether the salvage values are reported separately or not. The salvage value is thus included also in Cost_NPV, by excluding the portions of the investment-related costs attributable to the unused portions of their technical lives.

So, to me the reporting looks all very consistent, and that's why I am a bit confused about the question.  Could you elaborate in some more detail what makes you conclude that "the salvage value doesn't seem to be included in the objective function reported."?  Surely, the salvage value is included by crediting it back, and thus excluding the associated costs beyond the EOH from the total value of Objz, as described in the documentation.

[ggretton]

Many thanks Antti for your comprehensive reply - this does indeed make sense now.

In particular your point:

• The reported annualized costs (Cost_*) also implicitly include the salvage value, by excluding the portions of the investment-related costs attributable to the unused portions of their technical lives, because the annualized costs include only costs paid within the model horizon.

I think my confusion came from the presentation of the REG_OBJ function:

REG\_OBJ(z,r) = \sum_{y \in -\infty, +\infty} DISC(y,z) \times \left( INVCOST(y) + \ldots \right ) - SALVAGE(z)

Of course this is a sum from -\infty to +\infty years, whereas when we sum Cost_Inv we are only summing over the model years B_0 to EOH. If salvage is effectively:

SALVAGE(z) = \sum_{y \in EOH+1, +\infty} DISC(y,z) \times \left( INVCOST(y) + \ldots \right )

then deducting this we end up with:

REG\_OBJ(z,r) = \sum_{y \in -\infty, EOH} DISC(y,z) \times \left( INVCOST(y) + \ldots \right )

Hopefully that makes sense and my interpretation is indeed correct!

Many thanks!

[Antti-L]

Thanks for your clarifications.

> Hopefully that makes sense and my interpretation is indeed correct!

Well yes and no.  Yes, under some simplified conditions/assumptions, but no, not quite in general.  Let me try and explain:

The objective function formulation has been designed by highly qualified experts (such as Richard Loulou, McGill professor of management science and Dr. Denise Van Regemorter, KU Leuven), and, as you should see from the documentation (Part II), the objective function has been very carefully formulated with a high level of detail e.g. in the various different investment cases and their streams of annual payments. Each of those streams consists of ELIFE yearly payments and is equivalent (in terms of present value) to a single payment of the lump-sum investment cost assumed to occur at year k. Note also that these streams of payments include all individual years, and not just the milestone years or the model.

In the objective function, the annual investment payments INVCOST(y) correspond to the sum of the yearly payments of over all streams having a payment at year y. These values INVCOST(t) (for y=t) would indeed be equal to the annual investment cost, Cost_Inv(t) reported for each period t, if we would use the default annual cost reporting. However, with the default annual cost reporting one would not be able to reproduce the objective function from the annual costs, for several reasons:

  • The values INVCOST(y), where y=t, refer to the sum of payments in the individual year y only; the payments in other years of period t (the period with milestone year t) may be different, due to the complex investment cost accounting.

  • In the objective function the annualized investment payments of each stream are spread over ELIFE years, which may be different from the full technical life TLIFE.  And because of that, the annualized payments might all occur within the model horizon, even though the technical life would extend beyond end-of-horizon (EOH). Therefore, with the default annual cost reporting the (implicit) salvage values would not be correctly credited for any technology having ELIFE # TLIFE and TLIFE extending beyond EOH.

Therefore, because the default annual cost reporting would not be consistent with the objective function when discounted and summed together, the option of using levelized annual cost reporting has been introduced (enabled with $SET ANNCOST LEV). And when that is used, the reported annual costs are, of course, no longer equal to the INVCOST(y) values used in the objective function. In the levelized annual cost reporting, all investment costs are assumed to be spread over TLIFE (not ELIFE), and when that extends beyond EOH, the portion of the investment costs not being salvaged is levelized over those years of the lifetime that fall within the active model horizon (the calculation for the salvage value portion is described in detail the Documentation).  In this way we can get annual costs that are consistent with the objective function, and which can be used for reproducing the objective function.  The same levelizing approach is used for all costs that may have a salvage value (investment, decommissioning, and surveillance costs)

Note also that the user can also request more accelerated functional depreciation in the value of the capacity, by defining NCAP_FDR(r,y,p) (representing additional annual depreciation in the value), such that the salvage value will then be smaller than it is according to the default salvage value accounting (based on the discounted portion of TLIFE falling beyond EOH).

Nonetheless, under very simplified assumptions where ELIFE = TLIFE for all investments, and all investments would have only a single stream of payments (to eliminate any additional complexities caused by the cases with multiple streams), and there are no decommissioning or surveillance costs nor NCAP_ILED, your expression SALVAGE(z) = sum{y | y ≥ EOH+1 } ( DISC(y,z) × INVCOST(y) ) would indeed be correct (where  INVCOST(y) refers to the annual investment cost terms employed in the objective function).

I hope the above might clarify most of your remaining doubts?

[ggretton]

Thanks again Antti for another detailed reply.

My main goal was to understand how things add up for a simple case where all model periods are 1 year, ELIFE = TLIFE = 10 years, ILED = 0, no decommissioning or salvage cost, and all investment streams are case 1.a, so thanks for confirming that my understanding is correct in this instance.

Thanks also for explaining some more of the detail behind how $SET ANNCOST LEV affects the reporting of Cost_Inv(t). This is all really useful background on TIMES.

Best wishes from the TIMES team in NZ!