I am new to TIMES and seeking some advice in order to better capture certain dynamics in my representation of the cement industry. I aim to explore net-zero pathways for the cement industry by 2050, with an emphasis on fuel-switching flexibility, while giving the model an option for incorporating CCS for existing facilities to influence future investment decisions. Given the short timeline (about 25 years), retrofitting existing facilities with CCS appears to be crucial and gives a more consistent picture of how things could go in reality to the model. However, the problem is that the model structure is designed in a way that the burner is divided from the kiln (to capture fuel switch options and reflect the costs, efficiencies, etc., related to each carrier). And this makes modeling carbon capture technologies, in particular, more challenging. I have outlined two different modeling approaches so far, as explained below, and I would appreciate feedback or suggestions for capturing better what could happen in reality.
Please note that in both approaches, the kiln (calcination) is distinct from the burner (furnace), followed by a finishing stage where clinker is mixed with additives to produce cement. 1. Separate Technologies Approach (This seems to be the most common way of modeling CCS in TIMES models): Here, each technology (e.g., burners, kilns) is modeled separately with and without CCS. This complicates capturing CCS's potential for existing technologies and doesn't dynamically account for trade-offs between CCS implementation and fuel switching. The other problem is with the separated burners as, in reality, when you implement a CCS unit, it will capture the emissions coming from the kiln (which includes the fuel emissions, too), and therefore in the model, one should be able also to capture the emissions from burner and to do so I would need to define new technologies for burners again too (let's say with 5 burners and 3 CCS technologies, for each burner 4 (w/o CCS + 3 w CCS)=20 technologies should be added, and same goes for the kiln technologies). Furthermore, assigning CCS costs based on activity unit capacity (Mt for kiln and PJ for burner) and fuel emission factors presents challenges. Also, the type of CCS technology selected for each might differ, while in reality, the fuel combustion and calcination occur in one place.
2. Integrated Plug-in Approach: Here, CCS is treated as a plug-in technology (so the capacity of this is based on kt) (various CCS technologies exist) that is applied across the cement production stages (kiln and burner). This model reduces the number of technologies by channeling all emissions through each CCS technology or a dummy process where no capture occurs. After doing some runs, I noticed that with TIMES where no demand is defined for a commodity, the process won't be active (valid for both CCSs and dummy). To solve this, user constraints are defined based on the activities of host technologies by adjusting the total flow of emissions coming out of (the kiln and burner) to be equal with CCS and dummy accordingly. This way, the CCS technologies would work until there's some activity for kilns. However, the challenge related to this approach would be the compatibility of the CCS capacity with the capacity of each production technology, as there's only one process defined for each CCS technology type (also, in reality, one builds a CCS plant to capture emissions coming from a certain facility, and when the facility expires, there would be no point for the CCS to exist except the host will be renewed too). This way of considering emissions as a pool might also create problems, such as capturing some of the emissions with MEA while the rest go through calcium looping, for example, and both emissions might come from one specific technology. I am not sure how realistic such simplifications would be on a national (one or two countries) or regional (e.g., Nordics) scale. On the other hand, this approach gives the model a handful of options and freedom to choose if it wants to invest in CCS for existing ones or build new ones from scratch, where again it can use it with OR w/o CCS.
Could you provide insights on improving these approaches or suggest alternative methods to capture better the interactions between CCS deployment (for existing stock and new technologies) and fuel switching in the cement industry? I can provide you with more details about my case if needed.
Looking forward to comments.
>I noticed that with TIMES where no demand is defined for a commodity, the process won't be active (valid for both CCSs and dummy).
I don’t think this is a fair statement about TIMES. I think you are probably just using a ≥ commodity balance (which is the default for ENV commodities), whereas it seems to me that you should apparently use a fixed balance for the commodity in this case. Defining user constraints for adjusting the total flow of emissions coming out of the kiln and burner to be equal with the input to the CCS and dummy should be quite unnecessary.
>Could you provide insights on improving these approaches or suggest alternative methods to capture better the interactions between CCS deployment (for existing stock and new technologies) and fuel switching in the cement industry?
It seems to me that the TIMES retrofit / lifetime extension options might suit well for your purpose. You could allow the model to have the option of replacing the existing capacity by a refurbishment add-on technology (with CCS, among any number of different options), with the desired additional investment cost, fixed O&M costs, variable costs and other process characteristics (e.g. with fuel switching). However, when using the retrofit/LE options, the size of the model is likely to increase more than with the simplistic plug-in options you described.
The documentation for the TIMES Retrofits and Lifetime extensions facility is found here.
Of course, fuel switching and CCS can be also combined in any technology in TIMES, with the captured amount of CO2 (and the related electricity consumption for e.g. compression), process efficiency and variable costs all depending on the fuel(s) used.
18-04-2024, 06:29 PM (This post was last modified: 23-04-2024, 02:33 PM by farzin.)
Thank you, Antti, for the prompt reply and helpful links!
>I don't think this is a fair statement about TIMES. I think you are probably just using a ≥ commodity balance (which is the default for ENV commodities), whereas it seems to me that you should apparently use a fixed balance for the commodity in this case. Defining user constraints for adjusting the total flow of emissions coming out of the kiln and burner to be equal with the input to the CCS and dummy should be quite unnecessary.
You are right. It makes sense when there's no consumption the process shouldn't be active unless the balance is defined otherwise. As you suggested, the problem with idle processes was resolved after changing the commodity balance to fixed instead of the default balance (without any user constraints).
> You could allow the model to have the option of replacing the existing capacity by a refurbishment add-on technology (with CCS, among any number of different options), with the desired additional investment cost, fixed O&M costs, variable costs and other process characteristics (e.g. with fuel switching).
I went through the documentation and ran the example a few times to see how it works. However, since our model is a full energy system and all industries have stock instead of PASTI, I wanted to ask how this could change the results in the retrofit case compared to the latter? I find it challenging to track exactly how much of the stock is refitted. It seems like with stock, by default, the capacity reduces linearly to zero at the end of the lifetime.
Also, with the salvage cost, I understand that by defining the NCAP_FDR, you can enable the salvage cost for the host process. Apparently, for the retrofit (-1) technology, there’s no salvage cost unless one defines it as a life extension (+1). So, how can one compare the greenfield versus brownfield if it is very close to the end of the time horizon (model end year) and the cost calculations related to the retrofit don’t have a salvage cost?
Another question I have is related to common approaches in the modeling industry sector: Why, usually, in models, is the industry modeled based on STOCK and not PASTI? In the real world, that’s not how industrial units operate. Is it because modelers tend to enforce the model to replace capacities with new technologies, or are there other reasons behind this?
26-04-2024, 08:16 PM (This post was last modified: 26-04-2024, 08:58 PM by Antti-L.)
>However, since our model is a full energy system and all industries have stock instead of PASTI, I wanted to ask how this could change the results in the retrofit case compared to the latter?
The TIMES retrofit options can never create any new capacity. Therefore, if you use PRC_RESID for defining the phase-out of existing capacity, the capacity of a retrofit option will always be at most the original capacity. For example, if you have defined a linear phase-out of the existing capacity, and at some year the remaining capacity is fully retrofitted, that retrofitted capacity can of course then only follow the subsequent phase-out trajectory. But if only half of the capacity is retrofitted, then the subsequent phase out of the original capacity can be fully allocated to the non-retrofitted portion as long as such remains, and only after the non-retrofitted portion has been fully retired, the retrofitted capacity would need to start following the trajectory. I hope that is understandable?
>I find it challenging to track exactly how much of the stock is refitted.
Why so? The Var_Cap attribute should give you exactly the amount of capacity retrofitted or life-extended.
>It seems like with stock, by default, the capacity reduces linearly to zero at the end of the lifetime.
No, there is no such default. But it can be forced to be so when defining existing capacities with a linear phase-out. Then any fully retrofitted capacity simply must follow the same trajectory, because a retrofit can not not create any new capacity, it can only replace the old capacity with the retrofitted capacity. The lifetime extension options never have such characteristic; while replacing the old capacity they effectively create new capacity with a well-defined lifetime.
>Apparently, for the retrofit (-1) technology, there’s no salvage cost unless one defines it as a life extension (+1).
Yes, as described in the documentation. In general, it is not possible to define a consistent salvage value for a retrofit, because its lifetime is endogenous. And I guess it is even somewhat questionable whether retrofit costs should have salvage value. But of course, you could annualize the investment costs and thereby add all the investment costs as a fixed O&M costs, which should effectively result in costs equivalent to those with a salvage value. You may ask why there isn't an option available to do that automatically, and the answer is that it is now left to the user if such is wanted, because if doing so, it would make it possible to retire the retrofit investment at any point with a full salvage credit for the remaining lifetime (unless when using the forced retrofit option). And for the annualizing one would need to use some lifetime assumption, not quite known apriori.
>So, how can one compare the greenfield versus brownfield if it is very close to the end of the time horizon (model end year) and the cost calculations related to the retrofit don’t have a salvage cost?
Well, I think in most models retrofits would be deployed for existing capacities that would usually either be retired before the EOH anyway, or the salvage value of the retrofit investment would be very small, and not much affecting the cost-optimal decisions. However, with LE options you could ensure full salvage values.
Thanks, Antti, for the clear explanations! I have been working on the model development since. To mimic better the real world, I changed the technologies into unit-based ones and enabled the discrete investment function. I used the NCAP_DISC as described here and also read this thread. After testing the functionality in a smaller model, then I applied it to ours (which is a full energy system model, so the other parts are not defined as LUMPY). When I run the model as MIP, I am encountering some challenges that I can't seem to resolve. For example, the values of output commodities increase astronomically compared to when solving with the LP method. This prompts the model to create dummies for some periods while their available technologies exist that could be invested in. I tried increasing the dummy costs, but that resulted in increasing runtime, and usually, the branch and bound search takes forever and doesn't usually succeed in this case. I also tried turning all the INVCOST into zero but still got some Val_Flo with more than 7-8 figures.
I hope you can provide some insights or guidance. If you need anything from my side to assist you better, please let me know. I hope the explanations are clear.
25-07-2024, 10:29 PM (This post was last modified: 25-07-2024, 10:33 PM by Antti-L.)
Well, I find it hard to provide any notable insights without seeing the model and its results. So, if it is an academic model and therefore a public model, can you provide me the name/address of the Github repository (or equivalent)?
But anyway, make sure that you are defining sufficient size options for the new capacity blocks (only one block can be installed in each period), and make sure that NCAP_DISC is inter/extrapolated (it is by default not).
(25-07-2024, 10:29 PM)Antti-L Wrote: Well, I find it hard to provide any notable insights without seeing the model and its results. So, if it is an academic model and therefore a public model, can you provide me the name/address of the Github repository (or equivalent)?
But anyway, make sure that you are defining sufficient size options for the new capacity blocks (only one block can be installed in each period), and make sure that NCAP_DISC is inter/extrapolated (it is by default not).
Hi Antti,
Sorry for coming back to you with delays. I am working on the JRC TIMES and have changed how the cement is modelled there. I don't know if it is possible to make sense of the model considering the complexities or its results, but I just sent you a private message, including some result runs and the model itself. I understand if you would not find it possible to investigate this; therefore, I would write here what model behaviour I aim to prevent with discrete choice modelling in case there is a better way to tackle this. With continuous investment, the model does small incremental investments or sometimes has small activities on some technologies. We do not want this to happen as, in reality, investments are made at once or within every 10-20 years. The other issue I am facing is with the model deciding to sometimes use two CCS technologies on one site, whereas in reality, this should not be the case. Is there a way to tell the model, for example, if it wants to invest in a specific technology, it can't invest again until 10 years, for example? So that way it will do the investments all at once if needed and not in two consecutive periods?
Ok, it is the biggish JRC-EU-TIMES model. But apparently you run it with only one (or a few) regions?
Because I can see that the model instance to be ran is, however, reasonably small (~220,000 rows), I could take a look at it, but only if you provide me with the full set of input DD files (81 DD files), to avoid any issues with trying to reproduce your input files. The folder you linked only contained the discrete_cement.dd file, all other were missing. So, can you provide all those *.DD files (zipped)?
(09-08-2024, 09:16 PM)Antti-L Wrote: Ok, it is the biggish JRC-EU-TIMES model. But apparently you run it with only one (or a few) regions?
Because I can see that the model instance to be ran is, however, reasonably small (~220,000 rows), I could take a look at it, but only if you provide me with the full set of input DD files (81 DD files), to avoid any issues with trying to reproduce your input files. The folder you linked only contained the discrete_cement.dd file, all other were missing. So, can you provide all those *.DD files (zipped)?
I only ran the Finnish region for the time being. And thank you, I just sent you the dd files.
13-08-2024, 12:09 AM (This post was last modified: 13-08-2024, 03:38 AM by Antti-L.)
Ok, I have now looked at it, and I think I managed to fix the main issues in your model related to using the discrete investments option. The problems with your model were mainly related to the model being infeasible without dummy imports, and also to the very small feasibility tolerance you had used in cplex.opt. Dummy imports are not very good for MIP, because the solver can then find many MIP solutions that are basically infeasible. Therefore, I would strongly suggest eliminating all dummies first, to get a better quality model. And then, because you did not wish to see astronomical value flows (which arise from the commodity marginals being astronomical), you should also disable the dummy imports processes, because when they are available, the solution may still have dummy variables basic at zero level, and then the marginals would reflect your astronomical dummy prices (even though no dummy flows would be visible in the solution).
In summary, I did the following fixes to your model to obtain a good MIP solution:
• I eliminated all the dummy import flows;
• I disabled all the dummy import processes;
• I adjusted some options in cplex.opt (e.g. eprhs, which was unreasonably small);
• I defined the MIP optimality tolerance OPTCR=0.0001 (the GAMS default was 0.1, which is way too high).
As a result, for the nearzero-d-agg case I obtained an optimal MIP solution with ObjZ = 1303223.99, whereas your solution was about 280 times higher ObjZ = 359892712.96. And thanks to disabling the dummies, I did not see any astronomical value flows. My fixes are in the ZIP file attached.
Note that my fixes for eliminating the dummy flows were just quick test fixes. While they worked well as such, I think these dummy issues are likely caused by some underlying model calibrating errors, which is where one should better implement those fixes. But anyway, I as far as I could see, your problems with the discrete investments were indeed primarily related to your astronomically priced dummy imports.
Small follow-up comment on your additional remarks:
>With continuous investment, the model does small incremental investments or sometimes has small activities on some technologies. We do not want this to happen as, in reality, investments are made at once or within every 10-20 years. The other issue I am facing is with the model deciding to sometimes use two CCS technologies on one site, whereas in reality, this should not be the case. Is there a way to tell the model, for example, if it wants to invest in a specific technology, it can't invest again until 10 years, for example?
Unless using the MIP options (discrete or semi-continuous new capacity), TIMES is based on convex optimization. Because of that, restricting investments to discontinuous size ranges (such as "either no investment or an amount between A and B can take place") is not possible without MIP, because such a requirement is not convex. It is possible to restrict investments in a given period as a function of investments in the previous period(s), but again only as long as the convexity condition is fulfilled. So, for example a growth constraint on new capacity is of course possible (such that e.g. the sum of new capacity installed must remain constant for the next 10–20 years from year Y1), but again it is not possible to make that constraint disjunctive with respect to an investment taking place in Y1 or not. Therefore, looks like integer programming is indeed what you need for your objectives.
