Modeling a vehicle eff. target w/ user constraints
I'd like to model the US CAFE fuel economy standards out to 2016, and to this end, I have created the attached scenario file with a couple user constraints - one for light-duty cars and another for light-duty trucks.  However, I'm not sure if the constraints are doing exactly what I want. 

The fuel economy constraints should only apply to *NEW* vehicles (i.e., an increasingly higher standard for vehicles built in future model years: 2012, 2013, etc.).  But by applying the constraint in the way that I have, I believe I am simply constraining the total *FLEETWIDE* fuel economy of all vehicles (existing stock + all the new vehicles added in that year). 

In the attached file, all of my light-duty car technologies begin with "TCAR*", whereas all LD trucks begin with "TLDT*".  You'll see that I have excluded all base-year vehicles from the two constraints (these are the process names ending with "05"), but I think this is not enough and I need to do something more. 

Note that my end-use demands are named "TLDC" and "TLDT" for cars and trucks, respectively.  They are in units of VMT (vehicle-miles traveled).  The "TRA*" commodities are the various types of fuel available to cars and trucks (e.g., gasoline, diesel, ethanol, etc.).  This is why I used the UC_COMPRD and UC_FLO attributes to define these user constraints.

I'm thinking it might have been easier to write these constraints more simply if we were back to the old MARKAL technology definitions, in which each new technology vintage had a different name, depending on its year of introduction.  But since TIMES does vintaging internally, I'm not exactly sure how to write my constraint to make sure the fuel economy standards in each year only apply to the vintage of technologies that are introduced in that particular year.
Hope this makes sense.  I thank you in advance for your help.


Best regards,
David Mc.

Attached Files
.zip (Size: 586.09 KB / Downloads: 6)
If I understand correctly, you are including the vehicle-miles traveled from the whole vehicle stock, not just from newly installed vehicles in each period, because you use UC_COMPRD for referring to the vehicle mileage.

Unfortunately, the TIMES User Constraint facility currently does not include any easy way of referring to the flows of newly installed capacity only. Hence, UC_FLO will refer to the sum of the flows of all vintages operating in the period of the user constraint.  But if there is general interest for it, I could add support for a new UC constraint modifier (UC_ATTR), which could be used to refer to the flows of newly installed capacity only, in each period. If such were supported, then you could model these constraints by formulating the equation as follows, for each period t:
SUM(Car_models(p), FLOW(t,p,input_fuel)*Fuel_efficiency_target(t)) <= SUM(Car_models(p), FLOW(t,p,output_miles))
However, Amit might well have also some ideas for generating such constraints even with the current code.


Thanks for your response.  You have understood my problem entirely correctly.  However, I was worried that your answer might be the one you gave - i.e., that the approach I propose is not possible with the current code.  But before losing all hope, let's see what Amit has to say.  After all, I would imagine this question has come up in the past by different modeling teams, whether trying to model US CAFE (i.e., fuel economy) standards, similar vehicle CO2 standards in Europe, or some other type of constraint, where the standard only applies to newly installed capacity and not the entire stock.

Losing all hope? Shocked 

In the unlikely case that Amit would have no feasible ideas to create such constraints, but would agree that such would be useful, it should take only a few days until the new TIMES distribution (supporting the new UC_ATTR) would be available for download for you.

How about this:

  • Declare an EFFTarget emission (activity-based) = Fuel Cons/VMT efficiency standard in each year.
  • Have a simple UC that forces the total consumption by this group of technologies to be less than the total EFFTarget emission from them.

what do you think?

PS: very sorry for the delay in my response; I have been relying on the email notifications that are, clearly, malfunctioning.
Add an ENV commodity EFFTarget and declare an ENV_ACT = (fuel consumption/VMT) that applies in each year/period of the horizon. This basically vintages the target. In any future period, the total emission of this new commodity will represent the maximum fuel consumption that is allowed by the EFF target. So, when you add EFFTarget emissions over vintages and individual technologies, you will have the total fuel consumption that is allowed by the targets over different years, which can then be imposed as an upper bound on the total fuel consumption in each period (via a UC). You can have a different commodity for each category that you want to impose such constraints on.
However, as Antti pointed out in a bilateral communication, this is an approximation as it allows for overachieving the target in one period and underachieving it in a subsequent one. A kind of "banking" if you will.
I'm sorry Amit, but I don't exactly follow your logic.  Could you please elaborate? 

Are you suggesting that "EFFTarget" would be a new commodity that I would add somewhere in one of my various ~FI_Comm tables?  This commodity would be in which Cset - DM, ENV, or MAT?  Moreover, I'm not sure how I would connect each Light-Duty Car and Truck technology with this EFFTarget emission.  Or maybe you are suggesting something different altogether?

I think I may see where you're going with this.  In my model each new LD Car and Truck technology has a certain EFF (or CEFF) associated with it, in units of VMT/Fuel Cons (i.e., inverse of what you proposed).  If I could just somehow write a UC that says that all new vehicles added in a given year must have an EFF that is greater than the specified target value, that's what I'd really like to have.

PS: I also have been having problems with the auto-email feature of this forum.  But other than that, the forum has been an absolutely brilliant idea!
David Wrote:If I could just somehow write a UC that says that all new vehicles added in a given year must have an EFF that is greater than the specified target value, that's what I'd really like to have.

Ok, if this is what you want, then the constraint can be resolved "exogenously", by shutting down all technologies that do not meet the standard.  In that case you don't need any user constraint at all.
Earlier, I thought that you wanted the new cars to meet the standard on an average, such that even cars consuming more than the target could be still be taken into use, as long as the average over all new cars will be below the target in each period.

Whatever you actually want, I think I will include in the next release the new UC_ATTR, which will make it possible to model the optimal achieving of such targets endogenously. I have already implemented it, and will send it to Amit for distribution when he is ready for it.

Sorry for the confusion.  In fact, what I would like to have is a way to impose a constraint that forces new cars to meet the fuel efficiency target in each year on average.  In other words, just as you originally thought.  I would like to do this endogenously, rather than exogenously.  You're correct  that the latter approach would be quite easy, but the endogenous approach requires some more thought.  Of course, the endogenous approach is more representative of reality, since automakers certainly will continue to produce cars that do not meet the target, though they will balance this by producing cars that meet the target, or perhaps far exceed it.  If I utilized an exogenous approach, then I would not be able to capture this balancing (or technically, trading of credits between and within auto companies).

I look forward to the new release which will include the UC_ATTR that you mention.  Please let me know when it is available and how I should modify my UC to accommodate the new attribute.

Thank you for spending some time thinking about this.  I apologize, however, that it's still not entirely clear to me the method you are proposing.  I think I'm starting to follow though.

So you're saying that EFFTarget would be an "environmental" commodity, even if in reality it's an Energy (NRG) commodity (i.e., fuel consumption).  The advantage of this approach is that it doesn't interfere with actual fuel flows defined by the model (e.g., those for gasoline, diesel, etc.). 

Then, ENV_ACT (i.e., FLO_EMIS+) would be defined for each technology and each period.  However, I don't know what values ENV_ACT would take for each technology and period.  Would they be different for each technology, dependent on the actual efficiency (EFF, CEFF) of that technology?  Or is ENV_ACT simply the target fuel economy (i.e., the policy), in which case it would be the same for all car and truck technologies, regardless of their actual efficiencies? 

Lastly, I'm not exactly sure what the UC would look like and what would be constrained.  Obviously, the production of VMT by each vehicle multiplied by its corresponding ENV_ACT value would produce the the "environmental" commodity of fuel consumption.  But if I use the UC to constrain fuel consumption to be a certain level, this is a bit tricky because light-duty car and truck fuel consumption is dependent on some assumed level of future demand for light-duty VMT.  Fuel consumption should be free to rise or fall in the model, depending on the assumed VMT projection.  But as long as the average new car and average new truck in a certain year meet their respective fuel economy targets (in VMT/GJ, or GJ/VMT, or whatever), then everything is fine.
The UC will be as follows:
Tech Group (total fuel consumption) <= Tech Group (total EFFTarget emission)
These tech groups can be created via VEDA filters.

Amit's proposal is very good example of creative problem solving in TIMES modeling, and it represents an excellent workaround in the current code to overcome the lack of a direct way to refer to the flows of the newly installed vintage only. The drawback related to possible "banking" could also be eliminated by some further thinking: By adding another "emission" commodity for the actual fuel consumption and by introducing a quickly vanishing SHAPE for both of these "emissions", one could make sure that the previous vintages would have no impact on the constraint for any individual period.  So, with this approach the desired constraints could, indeed, be modeled accurately.
Nonetheless, I would think that the new UC_ATTR will be easier to use and more transparent, and using it does not require adding any such dummy emission commodities.

dlmccollum Wrote:I look forward to the new release which will include the UC_ATTR that you mention.  Please let me know when it is available and how I should modify my UC to accommodate the new attribute.

I have now sent the new TIMES version v3.0.6 to Amit for evaluation and subsequent distribution.
When you have downloaded the new version, you can modify your UC as I described in my first answer to your question:
SUM(Car_models(p), FLOW(t,p,input_fuel)*Fuel_efficiency_target(t)) &lt;= SUM(Car_models(p), FLOW(t,p,output_miles))
Described verbally:
  1. Define a UC_FLO for the input fuels, using the efficiency targets as the coefficients
  2. Define a UC_FLO for the output flows (vehicle miles travaled), using coefficient -1
  3. Define the UC_RHSRTS, with a zero upper bound (UP), and the interpolation option 15
  4. Define UC_ATTR~LHS with an entry FLO,NEWFLO (see the DEMO model for an example)
That's it. Of course, you can alternatively define the coefficients (1) to be negative and the coefficients (2) positive, and then use a zero lower bound (LO), as in your original formulation.
Very sorry for the needless delay; the code is now available via the VEDA installer (and the ETSAP download site).
I assume the code will be available as part of the auto-update feature of VEDA-FE.  I don't see it as of yet this morning, but maybe the auto-updater only runs at pre-determined times throughout the day/week?
This is another thing to be improved in VEDA... the autoupdate only flags VEDA FE/BE updates. You can access the TIMES code update by rerunning the installer. VTI_www_4.EXE that must be in your \VEDA\ folder.

Forum Jump:

Users browsing this thread: 1 Guest(s)