-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to set up vehicle ownership control scenarios for the transportation sector? #487
Comments
I don't know how Yang's study was done but I can comment on the meanings of the variables.
where |
This is Yang Ou, and thanks for digging into that old paper. Basically it's exactly as Page said, and we backward calculated the coefficient based on % sale targets. The approach in solving these kinds of minimum percentage constraints and intensity targets in GCAM is to set to credit the technologies or activities that meet the criteria or meet or exceed the target and not credit or in some cases penalize the technologies that do not meet the target. The key to it solving is to specify a market constraint (might be virtual, i.e., not literally how real world policy) for supply and demand of credits in such a way that the target is met when the supply meets or exceeds the demand. If the market is binding and supply equals the demand, there will be a non-zero credit price. If supply exceeds that demand at zero credit price, then the market is considered solved and the constraint not binding. For the EV standard, there are several possibilities for constructing a target in GCAM. The scale of total new vehicles has to be tracked to set the denominator, and the new EVs have to be credited to set the numerator of the target. To set the EV target, we would have to set the secondary output of the vehicle technologies to be credits equal to the allowable percentage of non-EV. But instead of crediting EV technologies, we would have to awkwardly penalize all non-EV vehicles by making them demand or buy credits allocating the share of non-EVs allowed. In this approach, the target would be met when the supply of allowable non-EV equals or exceeds the demand for non EVs. This should work, but seems awkward. Instead, we suggest something that is a little different from the CAFÉ target but seems more direct. We propose that the supply of EV credits is set by a secondary output on a 1-1 basis on all EV technologies. Simply, an EV will get a direct credit for being an EV. This supply sets the numerator of the EV target. The denominator is the number of total new vehicles, including EVs. The prescribed demand floor for EV credits is set by the target percentage multiplied by the total number of vehicles. This demand is implemented by setting an additional input demand of EV credits on each vehicle technology (including EVs) that is a function of the EV target. (Note you could equivalently have EVs demand zero credits and all non EVs demand (EV target)/(1- EV target), but this is less intuitive and blows up when the EV target is 100%). Much of the difficulty in implementing is with the units. We want supply and demand of credits to be in terms or units of number of vehicles. The GCAM vehicle output is in pkm, so we need to convert to vehicles using load factors and annual km per vehicle assumptions. To get the total number of vehicles so we can compute the floor for the number of EVs required (product of EV target and total), we also need to add a new input to vehicles in terms of vehicles per vkm based also on the assumed annual km per vehicle for each vehicle class. As part of the legacy of the C++ code for transport technologies, the code assumes that inputs are going to be in GJ, and it divides them by 1e9 to get total demand for inputs EJ. The credit inputs here are not in energy units, but they still get divided by 1e9. Therefore, we need to factor that conversion in setting a consistent definition and units for supply and demand of new EVs and credits and total new vehicles. It is irrelevant to this EV target that the units are not actually energy units. Implementing: Each vehicle technology vintage has an additional input to represent the ratio of number of vehicles per million vehicle km multiplied by the EV target for that period. This gives the demand target for EV in terms of number of EV required. This input applies to all vehicles that are part of the overall policy scope. The input should be named to identify the period, like EVTarget2030. Only the qualifying EV technologies need a secondary output to specify the number of EV vehicles and apply the credit (e.g., EVTarget2030) to incentivize the EV. The output of passenger vehicles is in passenger km, so we need the load factor for each class in addition to the annual km per vehicle assumption. But here is where we also need to account for the divide by 1E9. We then divide the secondary output ration by 1E9 (so the ratio is a small number but the units are billions of vehicles). Finally, we read in a price multiplier of 1E9 to convert the credit price, which will be in The last step is to define each of the period’s EVTarget markets and turn them on just for the period. Like EVTarget2030 is only on for 2030. Even though a market needs to be set for each, only one of the markets will be active in each period. So the solution burden is just this one additional market per period. |
Thank you so much for your detailed explanation! |
Thank you, Mr. Ou, for your explanation. I now understand that in order to set a target for BEV (Battery Electric Vehicle), we need to convert the target stock into passenger-km and then further convert it into a credit price. However, due to my limited knowledge, even after reviewing the official documentation, I am still unsure how to add a market into a scenario. Could you recommend additional resources or tutorials on how to configure models in GCAM? I plan to use the GCAM model in my paper. Thank you! |
According to Yang Ou's research (https://doi.org/10.1016/j.apenergy.2021.117364), we can set a scenario where EV sales shares grow to account for 70%. How can this be implemented in the transport input XML or similar files?
and could somebody tell me what meaning are these variable
The text was updated successfully, but these errors were encountered: