Veda2.0 Released!


Early retirement for each year
#1
Dear VEDA community

Within a model coupling exercise, I receive the number of vehicle sales and vehicle scrappage on an annual level. While it works fine to implement the sales for each year via NCAP_PASTI, I am struggling with implementing the annual scrapping:

I tried to define the annual scrapping via RCAP_BND for each year (e.g. 2028, 2029, 2030, 2031, and 2032). With RCAP_BND(2028), I intend to define how many cars must be scrapped in the year 2028 without wanting to specify the vintage-year of the cars that have to be scrapped. After my model gave a matrix error (see at the bottom), I had a closer look into the documentation. 

If I understand it correctly, RCAP_BND can only be defined for a milestone year of a period (in my case: 2030) and the defined value is the "same bound for all vintages" (Source: documentation, Table with user input parameters in TIMES). So, what my model seems to do is that it wants to apply the RCAP_BND defined for 2030 separately for the cars with vintage 2028, 2029, etc. but this is not want I want. What I want is that the scrappage value in 2030 is applied for cars with all vintages together.


Is there a possibility to model the scrappage in the way I intend, i.e. defining for each single year how many cars are scrapped in total from all previous years together?

Alternatively, I was wondering if the SCAP_BND might provide a workaround solution for my problem: If I understand SCAP_BND correctly, it represents the total amount of capacity that has been retired in and before the period for which I define SCAP_BND for the milestoneyear (e.g., I define SCAP_BND for the milestoneyear 2030 with a value that contains the sum of all cars being scrapped until 2036, which is the last year that belongs to the period of the 2030 milestoneyear). With this I would not be able to define the scrapping on an annual level, but at least I can tell the model how many cars are scrapped is total within and before each period. Thus, I could sum-up the scrappage from all years within the period plus all years before the period (which I get from the external model) and feed this to TIMES with SCAP_BND for the respective milestone year. Is my understanding of how I could use the SCAP_BND in my situation correct?
Kind regards,
Sandro

Matrix error from initial trial:
Lower bound > upper bound, because:
  • Lower bound = RCAP_BND defined for milestoneyear 2030

  • Upper bound = NCAP_PASTI defined for vintage year 2028


These are the error messages from the .lst-file:
[...]
*** Matrix error - lower bound > upper bound
VAR_SCAP(CH,2024,2030,T_C-ICE-GSL_BHIO-S3)   (.LO, .L, .UP = 0.004134, 0, 0.001508)
**** Matrix error - lower bound > upper bound
VAR_SCAP(CH,2024,2030,T_C-ICE-GSL_BHIO-S4)   (.LO, .L, .UP = 0.002829, 0, 0.000337)
**** Matrix error - lower bound > upper bound
VAR_SCAP(CH,2024,2030,T_C-ICE-GSL_BLIO-S1)   (.LO, .L, .UP = 0.000247, 0, 0.000232)
[...]
Reply
#2
> Is there a possibility to model the scrappage in the way I intend, i.e. defining for each single year how many cars are scrapped in total from all previous years together?

An exogenous "scrapping" profile by vehicle age can be defined by using NCAP_CPX(r,v,p) with a SHAPE index.
For some earlier discussion, see: New vehicles retirement
But there is no way to define for each single year how many cars must be retired in total from all previous years, unless you would use single-year periods, simply because there are no variables in the model for each single year, unless the periods are single-year periods. Moreover, it is not even clear to me what exactly you mean by "in total from all previous years".

> Is my understanding of how I could use the SCAP_BND in my situation correct?

As far as I know, there is no such attribute (SCAP_BND) in TIMES.  There is a variable VAR_SCAP(r,v,t,p), which represents the cumulative amount of retirements for vintage v in period t, but there is no input attribute for bounding this variable, and you did not want to bound retirements by vintage anyway.

In principle, a new attribute for bounding the cumulative retirements over all vintages in a given period would be possible to implement, if such would be considered useful.  However, I have some doubts about its usefulness, because the "over all vintages" is somewhat ambiguous and would depend on the period definition, if limited to those vintages that happen to have their original lifetime overlapping the period or including the milestone year...
Reply
#3
Some additional remarks:

As you say that you "receive the number of vehicle sales and vehicle scrappage on an annual level", would that mean that you can calculate the remaining amount of vehicles for each year by subtracting the cumulative scrappage from the cumulative sales?  If so, you can easily bound the capacity in each milestone year to that value, CAP_BND(r,t,p,BD) = value, with BD=UP/FX,which would implicitly cause scrapping at the desired amount, but of course only at the milestone years.

Note also that if you are indeed defining NCAP_PASTI for each individual year within the active model horizon, the original design of TIMES would not respect all those commissioning years accurately. But there is a way to enable accurate handling of such NCAP_PASTI vintages, by defining INT_DEFAULT('PASTI') = yes.  That will be automatically set also if you define any value NCAP_PASTI(r,'0',p). According to the original design, NCAP_PASTI was supposed to be defined only for years before the first model period.
Reply
#4
Dear Antti

Thank you so much for your useful feedback. Indeed I meant in my previous comment the VAR_SCAP and not SCAP_BND. However, I think your following remarks are most relevant to solve my problem:

(19-05-2022, 10:04 PM)Antti-L Wrote: As you say that you "receive the number of vehicle sales and vehicle scrappage on an annual level", would that mean that you can calculate the remaining amount of vehicles for each year by subtracting the cumulative scrappage from the cumulative sales?  If so, you can easily bound the capacity in each milestone year to that value, CAP_BND(r,t,p,BD) = value, with BD=UP/FX,which would implicitly cause scrapping at the desired amount, but of course only at the milestone years.
This is indeed a good suggestion. As you say, it should in principle be possible to implicitly include the scrapping by defining the annual sales (NCAP_PASTI for each year) and the entire vehicle stock (CAP_BND in the milestone year).

(19-05-2022, 10:04 PM)Antti-L Wrote: Note also that if you are indeed defining NCAP_PASTI for each individual year within the active model horizon, the original design of TIMES would not respect all those commissioning years accurately. But there is a way to enable accurate handling of such NCAP_PASTI vintages, by defining INT_DEFAULT('PASTI') = yes.  That will be automatically set also if you define any value NCAP_PASTI(r,'0',p).  According to the original design, NCAP_PASTI was supposed to be defined only for years before the first model period.
This is a very useful information that I was not aware of yet! For the model coupling, I usually do not touch the files of the existing model in VEDA-FE but directly compute the .dd-files based on the input data of the external model and adjust the .RUN file. I tried to implement NCAP_PASTI(r,'0',p) in a scenario file of a small testmodel (see attached screenshot) and create the .dd- and .RUN-files through VFE, but I could not find where INT_DEFAULT('PASTI') = yes is defined. Could you therefore please specify where and how INT_DEFAULT('PASTI') = yes will be defined? Is this a option that will be written as a "SET" into the .RUN-file? If yes, how exactly would the code line look like that I need to add to the .RUN file?

Kind regards,
Sandro


Attached Files Thumbnail(s)
   
Reply
#5
> Could you therefore please specify where and how INT_DEFAULT('PASTI') = yes will be defined?
 NCAP_PASTI(r,'0',p) causes INT_DEFAULT('PASTI') to be defined by the TIMES code when it is executed.

> Is this a option that will be written as a "SET" into the .RUN-file?
 The TFM_INS you have is sufficient, as long as the DD file where that NCAP_PASTI parameter is written is included in the model run.
Reply
#6
Dear Antti

I have tried to work with the NCAP_PASTI(r,'0',p) to define vehicle sales annually (my milestone years are 2020, 2030, 2040, 2050). However, once I activate the respective .dd-file, my model becomes infeasible. 


My .dd-file reads as follows:


Quote:$ONEMPTY
$ONEPS
$ONWARNING
$SET RUN_NAME 'STEM_PROBOUND_single_files'
$SET SCENARIO_NAME 'xt_8clu_car_annualsales_enabler'
SET TOP_IRE
/
/

SET UC_N
/
/

PARAMETER
NCAP_PASTI ' '/
CH.0.T_C-ICEGSL_GHIT_EXT 1
CH.0.T_C-ICEDSL_GHIT_EXT 1
CH.0.T_C-ICENGA_GHIT_EXT 1
CH.0.T_C-HYBGSL_GHIT_EXT 1
CH.0.T_C-BATELC_GHIT_EXT 1
CH.0.T_C-ICEGSL_GHIO_EXT 1
CH.0.T_C-ICEDSL_GHIO_EXT 1
[...]

/


Does anything seem wrong to you? Or do you have perhaps another idea why this could lead to an infeasible model? If necessary, I can also add an excerpt from the .lst-file (I just don't have it accessible right now).

Kind regards,
Sandro
Reply
#7
Thanks for the problem report.  However, actually I said:

AL> That will be automatically set also if you define any value NCAP_PASTI(r,'0',p).

So, you would only need a single (any) NCAP_PASTI(r,'0',p) defined, to get the '0' included in PASTYEAR, which would activate INT_DEFAULT('PASTI').

Nonetheless, I have no idea why you get an infeasible model, without seeing a reproducible case.  Could you provide such?  The *.DD and *.RUN files for the infeasible case would be sufficient, if you can provide me them e.g. via Dropbox / Google drive. If providing these files is possible, you could send me the download link in a private message. Including the listing file might also be helpful.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)