Veda2.0 Released!


What does dummy import mean?
#16

Well fine;  if you want the STOCK values fading out according to their given technical lifetimes in the years 2020, 2025 and so on, you can just specify a zero STOCK value at the year you want the capacity to be reaching zero, and they will then fade out linearly between 2015 and that year. It is very simple and easy.

TIMES will not do that automatically for you, because in general it would be highly incorrect to assume that capacities would be fading out in the years beyond the user-specified STOCK values. Consider, for example, a plant that came on-line in 1971, has a capacity 500 MW, and has a technical lifetime of 45 years. So, the user sets PRC_RESID(2010)=500 and PRC_RESID(2015)=500, which would be quite correct.  As you should see, in this example, which a typical case, there should be no fading of the capacity beyond 2015. If TIMES would automatically assume that the capacity is fading out after 2015 according to the technical lifetime, the results would be very wrong!

About new capacity: New capacity is allowed in TIMES by default for all processes in all milestone years, unless the user prevents them for some periods. In your case, as the capacities up to 2015 are already known by you, you can well prevent the new capacity from being built up to 2015.


Reply
#17


Dear Antti,
thanks again for your helpful advice. After I've tried out what you said (defining e.g. STOCK~2050=0), the capacities are fading out properly, but I absolutly agree with you that this behaviour would be wrong, regarding your example with the plant commissioned in 1971.
So in general, what would be a better way to model plants that have been commissioned in the past?

Just for your notice: I'm a bit new to the way of thinking behind energy system models. In the past I have been programmining energy market market models in my previous job, so I'm familiar with questions of unit commitment and storage modelling. However, these models work on a very high temporal (mostly hourly) and spatial (plant-specific or grid-node sharp) resolution. Hence, I'm still learning how to work with aggregated models like TIMES.

So, as far as I understand you now, in order to get the plants fading out according to their given TLIFE with respect to their year of commision I need to use PASTI~commissionyear, right?
I tried that, but the capacities PASTI~1970, PASTI~1975, ..., + STOCK sum up and therefore I have way too much installed capacity in the base year.
Therefore I thought it could be something like

without actually defining STOCK~2010 in the model. But how would I then make sure that the installed capacities in 2015 match my statistical values for 2015?

By the way: Would it be easier for you, if we conduct our conversation by email? I know that one of my colleagues has been in email and phone contact with Amit. If yes, I would PN you my email-address, or, if its easier for you, I could also call you in your office in Finland, if you like...

Best regards



Reply
#18



On the relation
between NCAP_PASTI and STOCK
:



NCAP_PASTI and PRC_RESID (alias STOCK) should basically
be considered as two alternative ways to define the existing capacity of a
process. You should thus not use both at the same time for any single process
(unless you know what you are doing).  Internally
in TIMES, STOCK is implemented as a special kind of NCAP_PASTI, which always has
the vintage year B(T1)–1. Therefore, as you have noticed, if both NCAP_PASTI
and STOCK are used for the same process, they will sum up, whenever the vintage
years of NCAP_PASTI(v) are different from B(t1)–1.



How to model
capacities that have been commissioned in the past
:



I would suggest choosing between defining STOCK(y),
y=2010, 2015, 2020, 2025,… or PASTI(v), v=1950, 1951, 1952, …, 2015.  If your TIMES processes are very aggregated (i.e.
each of them represent a large number of existing plant units), I think that with
the STOCK approach it is easier to reach the correct evolution of the total existing
capacity in 2010, 2015, 2020, 2025,… Moreover, the PASTI approach is much more input
data intensive, if the number of plant vintages to be allocated to each process
is large.



For determining the correct values of STOCK(y),
y=2010, 2015, 2020, 2025,…, you should use your power plant database, and sum
up all the capacities still existing in 2010, 2015, 2020, 2025,…, according to
the plant lifetime information in the database, and set STOCK(y) for the corresponding
TIMES processes accordingly. For determining the correct values of PASTI(v), v=1950,
1951, …, 2015, you should again use your power plant database and sum up the
capacities of the plant units installed in those years, according to your aggregation
of plants to each TIMES process. Then set your PASTI(v) (and NCAP_TLIFE(v))
accordingly.



If your database is accurate, in both approaches the resulting
capacities for 2010 and 2015 should match well with the statistics. If they do
not match, you should find out why they do not match: Are there plants in the
database that may have been shut down prematurely or have extended their lifetime?
Do the statistics and the database measure the capacities in a different way
(e.g. gross vs. net capacity, nominal vs. max. hourly MW etc.)?



But if the differences are small, you can easily make a “quick
and dirty” adjustment by using the 2010 statistical value as such for STOCK(2010),
and by scaling the aggregate capacities for 2015, 2020, 2025,… according to the

2015
statistical value. Finally, you should 
 reach a consistent future STOCK trajectory
for the existing capacity, matching the 2010 and 2015 statistics. For the PASTI
approach, full match with the statistics may of course be a bit more difficult
to reach.



Anyway, I think that is mostly a question of input
data processing, not directly related to VEDA or TIMES, but to any energy
system model. Unless you expect that VEDA/TIMES would do that processing?

P.S.
In my case, private support is limited to technical problems with TIMES (if you think that some TIMES feature is not working as it should).



Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Persistent Import Error after Sync Ismail Kimuli 0 597 02-03-2024, 02:54 PM
Last Post: Ismail Kimuli
  Model Import Yan Yan 8 2,897 30-01-2024, 05:45 PM
Last Post: Yan Yan
  Dummy import Emisssions Saad Awan 2 1,415 03-07-2023, 11:30 AM
Last Post: Saad Awan
  IMPNGZ Dummy Issue subhadipbhattacharya 1 2,284 17-09-2021, 06:58 PM
Last Post: Antti-L
  impact of YRFR on dummy imports svecjos 3 4,857 20-07-2020, 11:12 PM
Last Post: svecjos
  Strange behavior of mining and import processes AAgarwal 8 16,376 26-02-2019, 11:32 AM
Last Post: Anna (AKR)
  How exactly is the import of the VFE comment tag “\I:” working? MartinBaumann 4 10,096 02-10-2018, 03:29 PM
Last Post: MartinBaumann
  VEDA does not import all technologies Julia_G 3 8,711 21-02-2018, 07:58 PM
Last Post: Vikrant
  Infeasibility related to Import Dummy Process Raulm 0 3,778 09-12-2016, 10:11 PM
Last Post: Raulm
  Dummy Imports IMPNRGZ fg 9 25,994 10-11-2016, 08:56 PM
Last Post: fg

Forum Jump:


Users browsing this thread: 1 Guest(s)