Posts: 8
Threads: 4
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: May 2016
Hello everyone,
I am modeling processes whose maximum output (say commodity A) is decreasing during their lifetime. As a consequence the intrinsic value of those processes is mostly concentrated in the early years after investment.
I encounter the following problems:
The salvage value is overestimated because it is calculated only on the basis of the technical lifetime (TLIFE) of the processes, without considering the production profile along their lifetime.
As a consequence, the marginal cost of producing the commodity A decreases starting from EOD-TLIFE due to the overestimation of the salvage value.
Using time-stepped runs with a step < TLIFE, the marginal costs are underestimated all along the time horizon.
This is only my understanding of the decreasing marginal cost. Has anyone another understanding of the matter ?
And if the understanding is correct, maybe a solution to avoid the effect of the salvage value (deactivation possible ?) ?
Thank you in advance.
François
Posts: 1,984
Threads: 26
Likes Received: 68 in 59 posts
Likes Given: 20
Joined: Jun 2010
Yes, you are right of course.
If you model a process whose maximum output (say commodity A) is decreasing during its lifetime, and the lifetime exceeds the model horizon, then the salvage value is indeed overestimated. This has nothing to do with the time-stepped option as such. It works as designed, and is fully documented in the documentation, Part II.
Under the time-stepped option, the salvage value is calculated in the same way as with any (shorter) model horizon lengths, to get consistent results with similar runs without the time-stepped option but just using shorter model horizons.
Should you propose some other way of calculating the salvage value, I think it should then be applied to both cases: time-stepped and not time-stepped. That would imply a major change in the design of the objective function (by professor Richard Loulou), and should be discussed among ETSAP partners. Therefore, please submit any such proposal to the ETSAP Project Head for consideration.
Posts: 1,984
Threads: 26
Likes Received: 68 in 59 posts
Likes Given: 20
Joined: Jun 2010
You also asked about the possibility of "deactivating" the salvage value accounting.
Such an option is currently not supported, but could certainly be added, if there is general interest in it.
However, it would probably affect the results quite strongly in the time-stepped mode; for example, investments into hydro power would hardly be made at all.
Posts: 8
Threads: 4
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: May 2016
(25-06-2016, 06:08 PM)Antti-L Wrote: You also asked about the possibility of "deactivating" the salvage value accounting.
Such an option is currently not supported, but could certainly be added, if there is general interest in it.
However, it would probably affect the results quite strongly in the time-stepped mode; for example, investments into hydro power would hardly be made at all.
Thank you Antti for your answers.
From what I understand, the current way of calculating the salvage values is totally satisfying in 95% of the cases. What could be maybe added is the possibility of adjusting the calculation for some selected processes, like those we are currently talking about (with a pre-defined and shaped output profile along the lifetime). Examples of technologies that fall into this category of processes would be: PV and wind turbines (declining performances along years), oil & gas wells (declining production along years, particularly for shale gas and tight oil wells).
In my specific case, having the possibility to deactivate the savalge values calculations for some chosen processes would suffice.
But I guess that one way of taking into account all cases would be to be able to input an explicit salvage coefficients curve, function of the number of years outside of the optimization period, to be applied instead of the existing salvage values calculation (I am not an optimization expert, but I guess that the explicit curve should follow some convexity constraints).
As I certainly lack the academic skills to formulate a proposal to update the salvage values calculation, I would trust the advanced users/developers of the TIMES community to assess the the value and the best way of adding such features.
Posts: 1,984
Threads: 26
Likes Received: 68 in 59 posts
Likes Given: 20
Joined: Jun 2010
27-06-2016, 08:52 PM
(This post was last modified: 27-06-2016, 08:55 PM by Antti-L.)
Ok, what you describe sounds essentially equivalent to functional depreciation.
>>FUNCTIONAL DEPRECIATION:
>>Reduced productivity of a capital asset due to obsolescence. Decreased capability and throughput of an asset.
I think one could say that TIMES now assumes zero functional depreciation within the salvage value accounting.
But I also think that we could easily generalize this, by allowing the user to specify a new input parameter, say NCAP_FDR(r,y,p), which defines an optional Functional Depreciation Rate. It would, of course, not be perfect, as it assumes only a standard exponential form for the decay in the process capability, but maybe it could be satisfactory for many cases? Defining a very high NCAP_FDR for a process would essentially lead to a zero salvage value.
If this would seem sensible to TIMES users, I could implement it in the next version of TIMES.
Therefore, should anyone read this post, please comment: Would this seem theoretically sound and/or useful or not?
Posts: 8
Threads: 4
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: May 2016
Thank you Antti for your clarification, and for your proposal.
I believe your proposal of implementation would be very beneficial to model more precisely the investment near the end of horizon for certain technologies, and would ease the use of time-stepped solutions (which increases the number of times investment is calculated near the end of horizon).
Posts: 67
Threads: 11
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: Jun 2010
Dear Antti and Francois,
thanks for this interesting discussion. Recently other users during the training courses where asking for a parameter like this. I think could be quite useful.
Best regards,
Maurizio
Maurizio Gargiulo
<br />
|