FLO_EMIS with IRE process problem
|
11-01-2014, 06:21 PM
Hi Antti - this is probably an issue for you
I have a problem with the emissions accounting in a model that I'm developing. I'm counting CO2TOT emissions in an IRE import process using FLO_EMIS. In most periods, this works fine, but in some periods the emissions are much higher than they should be (45 MtCO2 higher!). Look at the CO2TOT emissions from the IMPCOA process in 2020 and 2025 in this spreadsheet: uploads/80/impcoa_output.zip. I've limited total imports to 500 PJ/year to highlight the problem. In most years, the emission factor is as expected, but in 2020 it's more than double at 176 kt/PJ. I've attached the DD files for the TIMES model that I'm using: uploads/80/impcoa_emissions_problem.zip. I'm using TIMES v3.43 from VEDA-FE. I've checked the DD files and the TIMES dump, and the data look fine. For example, from the TIMES dump: UK.IMPCOA.COA.ANNUAL.IMP.CO2TOT.OUT 83.7620370 83.7620370 83.7620370 83.7620370 83.7620370 83.7620370 2027 +++ 83.7620370 83.7620370 83.7620370 83.7620370 2046 +++ 83.7620370 I've also confirmed the wrong values in the GDX file, which suggests that the problem lies somewhere in the model or the TIMES code. I'd be very grateful if you could have a look at the problem to see if you can replicate it and perhaps tell me what is happening! Thanks a lot, Paul Dear Paul, Inter-regional exchange processes can have two types of flows: trade flows from/to other regions, and auxiliary flows that are tied to the trade flows. One can also define both types of flows for the same commodity, and this is what you are doing for CO2TOT. Your process IMPCOA has been defined to have the following TOP_IRE topology for trading: SET TOP_IRE / So, you are making emissions trading business with this process. In addition, you have also an auxiliary output of CO2TOT, which is tied to the imports of COA. But as your CO2TOT trade flow has no costs, and no bounds, you are freely importing any amounts of CO2 into the UK from the rest of the world (IMPEXP). I think this could be a brilliant solution to reduce CO2 emissions elsewhere in the world: Just export all your CO2 to the UK! But if this is not intentional, I am not sure what is causing such a modeling error. Have you really defined CO2TOT to be an import flow for the process? Or do you have some kind of a typo in the template, or is it a problem in VEDA-FE? Maybe you can post the process definition here? [EDIT:] As a matter of fact, you are importing CO2TOT with a number of processes: IMPEXP.CO2TOT.UK.CO2TOT.IMPCOA Therefore, I guess the issue must be unintentional. It remains unclear to me why you have these import flows defined.
14-01-2014, 06:09 AM
Dear Antti,
Thanks for the comprehensive answer. You are right that it was not our intention to have CO2 trading. We defined the emissions using ENVACT in VEDA-FE, so using FLO_SHAR. I expected them to be proportional to the commodity flow (which they are in most years) as an auxiliary flow. I don't understand why they are not? Here is the cut-down VEDA-FE input sheet with the relevant definitions: uploads/80/VT_UK_RSR_V01.zip This is a single-region model so we are importing and exporting commodities (and associated emissions) from an external undefined region, mainly for legacy reasons (it's how we did it in the previous MARKAL model). Would it make a difference if we explicitly defined a ROW region? It seems very odd to me that it imports additional CO2TOT because that commodity has an upper bound in the UK region so it is increasing the cost of the energy system by doing so. So there's two things I don't understand: 1) Why VEDA-FE is defining CO2TOT as a trade flow rather than an auxiliary flow, and whether this is correct? 2) Why TIMES imports additional CO2TOT when that increases the overall cost of the model? Thanks a lot for your help. Paul Thanks for the follow-up. In the template you provided, I cannot myself see any reason why VEDA-FE should think that CO2TOT is to be traded. I suggest to post this question on the VEDA Forum, for Amit to answer, to get to the bottom of it. But the fact is that those TOP_IRE definitions are coming from VEDA-FE, which writes them into the DD file for TIMES. Concerning the second point, according to the model results from the run you provided (uktimes_base), the marginal cost of CO2TOT is zero up to the year 2025. So, your upper bound does not appear to be binding in those years where the extra imports of CO2TOT occur.
14-01-2014, 07:21 AM
Thanks Antti, I will post this issue to the VEDA forum as you suggest. I should have looked more closely at the marginal costs! Thanks for all of your help.
|
« Next Oldest | Next Newest »
|
Users browsing this thread: 1 Guest(s)