I have a question about modeling of Carbon Capture and Storage (CCS) implementation for existing technologies in TIMES. We are working on Low-carbon ammonia production industry for which we consider retrofitting of existing plants (steam methane reforming) with CCS. We defined the retrofit options based on the procedure we found in the relevant TIMES documentations (the defined Excel sheet in our model is attached, where CCS can be considered for two production technologies ATRNH3, and NGNH3). By this definition we assume that the CCS technologies (NGNH3_CCS and ATRNH3_CCS_retrofit) are dependent to their host processes; for example their capacity can not exceed the capacity of the host processes, and x% increase in CCS capacity/activity is accompanied with x% decrease in the host process capacity/activity. However, in our results we noticed that when the end of life of some existing stocks (host processes) arrive, the corresponding CCS technologies (for that portion of stocks with discontinued operating) still continue operating which in fact can not be feasible practically. In contrast, we expect that when the end of life for main technology arrives, the coupled CCS-technologies should stop operating as well. We would be grateful if you can give us some hints to figure out why this happens.
13-11-2022, 07:21 PM (This post was last modified: 13-11-2022, 07:59 PM by Antti-L.)
I suspect it is probably just some flaw remaining in the code related to the handling of the "forced" retrofits, which is a complex case. Could you help by providing a reproducible test case (the *.DD and *.RUN files + the listing file) showing the issue? Please also mention the name of the process that manifests the issue.
And a request to users: include Veda Browse screenshots of processes or UCs in question that show *all* attributes that have been declared. It will make it easier for us to diagnose.
Many thanks for your reply and information. The link for a folder containing the DD and RUN and listing files is as: https://drive.google.com/drive/folders/1...share_link This corresponds to a Net-zero scenario in which ammonia production emission should be reduced by 96% by 2050 compared to the current value. The existing technology is NGNH3 where the stocks are reducing over the time when their end of life arrives depending on plants age (the existing stocks will be fully retired by 2038, as indicated in "Scen_Plant-age-distribution"). However, from the results we see that e.g. in 2030 and 2035 the total ammonia production from the the NGNH3 and corresponding CCS-retrofit technology, NGNH3_CCS (where the NGNH3 is the host) exceeds the existing stocks in those years. However, we expect that adding CCS (through NGNH3_CCS technology) would reduce the portion of production from host process (NGNH3), while the total production by NGNH3 and NGNH3_CCS together should not exceed the existing stock defined in "Scen_Plant-age-distribution". I would be grateful to have you opinion on that. Please let me know if you have any questions.
Ok, I have now tested with your test model and have arrived at some suggestions.
>The existing technology is NGNH3 where the stocks are reducing over the time when their end of life arrives depending on plants age (the existing stocks will be fully retired by 2038, as indicated in "Scen_Plant-age-distribution"). However, from the results we see that e.g. in 2030 and 2035 the total ammonia production from the the NGNH3 and corresponding CCS-retrofit technology, NGNH3_CCS (where the NGNH3 is the host) exceeds the existing stocks in those years.
Yes, I understand your point. You could also have used the NCAP_PASTI parameter for defining the existing capacities, and then you would not have seen this issue. However, you are defining the existing residual capacity by using PRC_RESID (aka "stock"), which just defines how much capacity is still remaining available in each milestone year. From these amounts, there is actually no way to tell how many units that residual amount corresponds, or of which age those units are. The model generator thus does not know the age profile of the residual capacity.
Some users may well use this parameter for describing the estimated retirements of the existing capacity, and therefore, the code has been allowing those exogenous retirements (implied by the reductions in the residual amounts of the existing capacity) to be either retrofitted or refurbished with a lifetime extension, just like with the endogenous retirements. The amount of retrofitted or lifetime-extended capacity was constrained by the total amounts retired in each period, and so the code was working consistently in that respect. The retrofitted capacity was not exceeding the amount of capacity retired in your results, and the sum of retrofitted and non-retrofitted remaining capacity was neither exceeding the original capacity.
>However, we expect that adding CCS (through NGNH3_CCS technology) would reduce the portion of production from host process (NGNH3), while the total production by NGNH3 and NGNH3_CCS together should not exceed the existing stock defined in age-distribution". I would be grateful to have you opinion on that.
Yes, I understand that you would not like to allow any part of the exogenously retired capacity to be retrofitted, but only the capacity that remains after those retirements and can be then endogenously retired. While your interpretation is quite valid, the original interpretation can also be considered valid.
As said, you could have avoided this ambiguity by using NCAP_PASTI. Nonetheless, I have now decided to adopt your interpretation in the code for the forced retrofits case, which you are using for NGNH3.
Therefore, if you can take into use the latest TIMES release, you should see the model working as you had expected. There is, however, a small omission in your input data: You have not defined the technical life of the NGNH3_CCS retrofit process, and so the default value (10 years) is applied. I think this may be too short, and so I also suggest that you define NCAP_TLIFE('US','2020','NGNH3_CCS')=20. With this addition, the sum of the retrofitted and non-retrofitted residual capacity will be in the results exactly according to the PRC_RESID trajectory you have defined, which I guess is what you have expected.
I have tested the model with the new code and with the added NCAP_TLIFE for the NGNH3_CCS process, and I have verified that the results are as expected (i.e. as I think you had expected).
I hope you can take the new TIMES v4.6.7 Release for resolving your issue?
