Download the latest version of VEDA-FE (45828) and VEDA-BE (492014)

Veda Application Installation guide

Modeling a vehicle eff. target w/ user constraints
I am happy to report that the new code and new approach to setting targets for new technology efficiencies works brilliantly!  Thank you again for thinking about this issue and for acting so quickly.  I owe you.

On a related matter, a question popped up as I was inspecting some of my results in VEDA-BE.  The constraint on new vehicle fuel economies is working as intended.  (I implemented the constraint in the way that Antti suggested.)  No problem there.  But now I see that if I don't set the vintaging option to "YES" for base-year technologies, then their fuel consumption and vehicle-mile production gets lumped into that of the new technologies.  Of course, there are ways to filter out these technologies within VEDA-BE or later in Excel. 

However, this caused me to think, "Should base-year technologies have the vintaging option set to 'YES' in the ~Processes sheets of the BY workbooks?"  I looked to the TIMES-DEMO model for some guidance, and I see that most BY technologies (i.e., residual stock) are not vintaged.  But a couple are, and these are the two car technologies. 

I'm leaning toward changing my model to vintage the BY transportation technologies, but before I do this, it would be good to hear your thoughts on why this is either a good or bad idea.  And is the transportation sector unique, or can I simply vintage all BY technologies in all sectors (e.g., also including refineries, power plants, etc.)?
I should have mentioned that I configured my constraints to exclude the base-year technologies.  In other words, the fuel economy targets do not apply to them.  So this vintaging question is really more of a post-processing question.  Unless I am mistaken, and the application of vintaging to BY technologies would actually change the solution.
I now have some other questions about vintaging, in addition to those posted above, which were related to vintaging base-year technologies.

Upon closer inspection of my results, in combination with running some stricter constraints on vehicle fuel economy, I have found that the model is acting in a weird way.  In certain periods, the model is investing in old vintages.  For example, in period 2030 the model invests in light-duty trucks with a 2025 vintage.  And again in 2050, it invests in LD trucks with a 2045 vintage.  When I do some external calculations, it seems that within a particular period, the model is obeying the fuel economy constraints that I impose.  However, the constraint is not obeyed for particular vintage years.  In other words, for example in period 2020, the model might invest only in 2020 vintage technologies, which meet the fuel economy target/constraint on average.  This is good.  Then, in 2025 the model might invest in a few 2025 vintage technologies, which meet the fuel economy target on average (again this is good); but then also in 2025 the model invests in some 2020 vintage technologies which have fuel economy well below (i.e., much worse than) the targets, which are in efficiency units of MVMT/PJ.  Thus, the average fuel economy of new vehicles in the 2025 period is below the fuel economy target constraint on average.  It's like the constraint only applies when the period and vintage years are exactly the same.

Now, certainly, there could be a problem with the way I have formulated my constraints.  They are attached here.  There could also be a problem with some other part of my model.  (Though, I checked SysSetttings.xls for the way vintaging is handled, and my settings are the same as the DEMO model.)  But just in case there is a bug in the code, I wanted to report this issue.  I think Antti might like to receive feedback on the new implementation.

If you have any ideas on how to fix this vintaging problem, I would very much like to hear them.

Please have a look at the attached files, which formulate my fuel economy constraints in exactly the way that Antti described a few posts before.  I hope I haven't introduced any errors when I specify the interpolation setting of UC_FLO to be 1.  Also, I wonder if these two scenario files are in conflict with one another.  You'll see that one file imposes increasingly stringent fuel economy targets from 2012 to 2016.  Then, the 2016 level is held constant until 2055.  This is the BAU case.  Then, the other file imposes even stricter constraints from 2017 to 2025.  The 2025 level is then held constant to 2055.  I don't always run with this second file, since it is not BAU.  My assumption is that if there are two constraints which overlap (i.e., the fuel economy targets in the two files between the years 2016-2055 and 2025-2055), then the more stringent constraint would "win out", so to speak.  But perhaps this is the problem.  Though, I should mention that I have run these files separately (one without the other), and the "back-vintaging" issue described above still persists.


Attached Files
.zip (Size: 1.17 MB / Downloads: 7)
I must say that I don't understand what exactly is the issue that you are trying to describe.
TIMES can invest only into a single vintage in each period. For example, in 2025 TIMES can only invest into the 2025 vintage. The investment variables are VAR_NCAP(reg, t, prc), where reg stands for the region, t stands for the period, and prc stands for the technology.

Understanding this, I find it difficult to understand what you mean by saying that "in period 2030 the model invests in light-duty trucks with a 2025 vintage".  This is not possible, because if the model invests into the 2025 vintage, that will occur in the period 2025.  (I assume that all your new vehicle technologies have been defined to be vintaged, as they should be when modeling vintaged efficiency targets.)

Possibly your problem is related to an anomaly caused by very strict efficiency targets, which could lead to the model investing into the 2025 vintage (in 2025, as explained above), but not taking those vehicles into use before 2030?!  Is this what you mean by the anomaly you have described?  By such investments, the model could circumvent the efficiency targets, but at the high cost of not using the vehicles at all in the period when they are "installed". If this is the problem, you should be able to eliminate it easily by setting the NCAP_AF availability factors for the new vehicles to be of bound type FX instead of type UP.  The fixed availability factors will force the vehicles to be used according to the availability factor. Do let me know if that fixes the problem.
As always, you have understood the problem correctly and proposed an elegant solution!  Actually, I wasn't sure if TIMES restricted investments in a certain period only to technologies with the vintage of that period.  That was, of course, my initial assumption and what I was hoping would be the case.  But then my results seemed, at first, to suggest otherwise.  But you were absolutely correct.  The model was circumventing the strict efficient target constraints by investing in technologies in 2025 but not using them until 2030.  Pretty clever of the model actually :-)  Now that I've changed my NCAP_AF availability factors to FX instead of UP, the problem has been solved. 
Great news!

I was already getting afraid that the suggestion might just cause more problems, due to your modeling approach possibly not corresponding to all of my implicit assumptions. In fact, I had already originally implicitly assumed that you had modeled the new vehicle technologies by fixed availabilities (because that's what I have myself deemed most reasonable for the car technologies). Thus, I had not anticipated that those clever car manufacturers would be able to exploit such a loophole in your efficiency regulations, by putting their less-efficient production models onto the used car market instead of the new car market, because I had maintained wrong assumptions about your modeling approach in the first place. Embarrassed
Actually, more problems did develop after I implemented the procedure we have been discussing.  But it wasn't a problem with your suggestion, rather my model was overconstrained in other areas.  For example, the growth rates on my light-duty car and truck technologies were far too strict, and this is why the model was choosing to circumvent the fairly strict efficient targets.  After I changed the NCAP_AF factors to FX, the model started overproducing the end-use demands in certain years in order to meet the efficiency constraint.  Simply put, I had not made available enough highly efficient vehicle technologies, so the model didn't really have a way to meet the constraints without flooding the market with too much VMT (which obviously automakers cannot really control).  I guess, from TIMES perspective, over-investing in vehicles was cheaper than bringing in dummy technologies.  However, in the end I was able to solve the problems, and it's good that I was forced to revise my growth rate constraints anyway.  Smile

All of this leads to a couple other quick questions.

1)  In SysSettings.xls (in the "Import Settings" sheet), am I correct to specify a value of "0" for "Generate Vintage Bounds".  The TIMES-DEMO model now specifies a 1 here.  However, according to the "Getting Started…" documentation (see v2.7, p. 22), it seems that I actually want to specify a 0 here, since I do not follow the old MARKAL naming convention of having the last two letters of the technology name represent the model year.  That being said, some of my technologies do have names that end in numbers (e.g., TCARGSLPHEV10 for a gasoline plug-in hybrid with 10-mile electric range; and TCARE85 for a flex-fuel ethanol vehicle).  Is it okay to have numbers at the end of technology names if I am not requesting that TIMES generate vintage bounds?  And if I do not generate vintage bounds, am I still in line with your assumptions about my modeling approach?

2)  What did you think about my earlier question about vintaging base-year technologies.  I implemented the approach, and everything seems fine.  The vintage year is shifted to 2004 (even though my base-year is 2005).  But the model solution does not change at all.
Commenting on these VEDA-specific settings should be best left to Amit, but as far as I know, one had really better use the "0" setting for "Generate Vintage Bounds", unless you are actually manually introducing technology vintages in your model (by introducing separate processes for each vintage), and have given them names ending in year numbers.  Only in that case you can make use of the automatic generation of vintage bounds, which depends on the process names with year numbers. However, if you have some process names ending in numbers but not being intended to be interpreted as vintage years, it would be dangerous to use the "1" setting. I have personally never considered using the "Vintage bounds" setting in my models. Not generating the automatic vintage bounds will never do much harm, even if you have been modeling vintages by separate processes.

Defining the base year technologies as vintaged would make no difference, unless you have defined for the technologies some time-dependent parameters that will be assumed to be vintage-dependent when the process is vintaged. For example, if you have defined some efficiency developments for the base year technologies, the solution would be different when they are vintaged (the efficiency would remain constant over time if vintaged, whereas it would change over time when non-vintaged). On the other hand, for vintaged technologies you can then use a SHAPE for defining an age-dependency for some parameters, such as efficiency, emission factors etc.

In my opinion, it can be useful to define some changes in the average characteristics of the remaining existing stock over time (for example, reduced emissions along with the retirement of the oldest equipment), and such changes can usually be most conveniently specified when the technology (representing the residual stock) is not vintaged. Therefore I have not chosen to define the base year technologies vintaged in my models.

Forum Jump:

Users browsing this thread: 1 Guest(s)