Implementation of 45Q carbon credit

[ejin]

Hi,

We want to implement the 45Q policy (carbon credits) for carbon capture technologies for ammonia production. We created the credits as "DUMSUB" to those CCS technologies, and the credits can be claimed by CCS technologies only for 12 years after the plant with CCS technologies are built. We used "SHAPE" function to implement this 12-years period constrain for credit. We aim to see how this policy can promote the utilization of CCS technologies in order to reduce the carbon emissions without putting a net-zero emission constrain by 2050. We also have some activity boundary for preventing technologies processes stopping operation suddenly. Based on our model results, in 2021, the conventional technology (ATR) occurs instead of the same technology with CCS (ATR_CCS_new), which we cannot understand. Cause when the credit is assigned to ATR_CCS_new technologies, it is cheaper than ATR along.

We attached the model files and hope you can help us find the clue.


Thanks,

Enze

[Antti-L]

Your ZIP file did not contain all the files needed for running the model instance.  The following files were missing:

  • us_nh3_netzero_ts.dd
  • plant-age-distribution.dd

However, these names seemed familiar, and I found files of these names in a model of another Forum user (jabarivelisdeh) who has also been modeling ammonia production. I tried with those files, and the model then actually worked. 

I looked at the model and results, and indeed at first sight it appeared strange that the model started investing into ATRNH3 in 2021, even though there was even sufficient capacity for satisfying the demand. It turned out that the tax credits were the incentive to start speculative investments in order to maximize the overall tax credit cash flows, which were substantial enough to merit such an unexpected exploit.

In your model, the tax credits were granted also to any retrofitted plants, for 13 first years of operation of the retrofitted capacity. Due to the total lifetime of the ATRNH3 technology being defined 35 years, that made it possible to schedule several cascading retrofits for the ATRNH3 plants commissioned in 2021. In other words, the following actions were taken by the investors:

  • In 2021, 3.3 Mt of new ATRNH3 capacity was built
  • In 2023 that 3.3 Mt of ATRNH3 capacity was retrofitted with CCS and was thus granted with the 13 years tax credits
  • In 2033 that 3.3 Mt of capacity was retrofitted anew with CCS, and was granted with credits for another 13 years
  • In 2043 that 3.3 Mt of capacity was retrofitted anew with CCS, and was granted with credits for another 13 years

For each of these retrofits, the full retrofit investment costs of course had to be paid, but as these costs were so small in relation to the benefits (less than 5% of the CCS_New investments), it was still profitable to make these cascaded retrofits, in order to maximize the cashflows from the tax credits. By doing so, no operation years were left without getting those credits (except the two two first years 2021 and 2022). (You may notice even some overlap with each of those 13 years, but that of course did affect the credits, as any previous retrofit is retired when the new retrofit replaces it).

These results again highlight some of the complexities related to retrofitted processes.  As the formulation is now, it inevitably has to allow retrofits at any year over the lifetime of the original vintage, and it is not quite straightforward to automatically prevent such cascading retrofits from happening. But of course, such repeated retrofits would not make any economic sense, unless the tax credits were granted after any retrofit and were so high in relation to the retrofit investment cost, and so, this issue only arises under rather special circumstances.

However, in the case of your model, there is an easy way to prevent such cascaded retrofits by exogenously bounding any retirements of the retrofits to zero. I tested by doing so, and the issue no longer appeared. I defined the bounds for ATRNH3_CCS_retrofit as follows:

  PARAMETER RCAP_BND /
  US.0.ATRNH3_CCS_retrofit.UP  5
  US.2025.ATRNH3_CCS_retrofit.UP  0
  /;

Maybe you could consider that as a work-around solution against this kind of a problem?
However, I think I can also design an option for automatically preventing cascaded retrofits for the next release of TIMES.

[ejin]

Your ZIP file did not contain all the files needed for running the model instance.  The following files were missing:

  • us_nh3_netzero_ts.dd
  • plant-age-distribution.dd

However, these names seemed familiar, and I found files of these names in a model of another Forum user (jabarivelisdeh) who has also been modeling ammonia production. I tried with those files, and the model then actually worked. 

I looked at the model and results, and indeed at first sight it appeared strange that the model started investing into ATRNH3 in 2021, even though there was even sufficient capacity for satisfying the demand. It turned out that the tax credits were the incentive to start speculative investments in order to maximize the overall tax credit cash flows, which were substantial enough to merit such an unexpected exploit.

In your model, the tax credits were granted also to any retrofitted plants, for 13 first years of operation of the retrofitted capacity. Due to the total lifetime of the ATRNH3 technology being defined 35 years, that made it possible to schedule several cascading retrofits for the ATRNH3 plants commissioned in 2021. In other words, the following actions were taken by the investors:

  • In 2021, 3.3 Mt of new ATRNH3 capacity was built
  • In 2023 that 3.3 Mt of ATRNH3 capacity was retrofitted with CCS and was thus granted with the 13 years tax credits
  • In 2033 that 3.3 Mt of capacity was retrofitted anew with CCS, and was granted with credits for another 13 years
  • In 2043 that 3.3 Mt of capacity was retrofitted anew with CCS, and was granted with credits for another 13 years

For each of these retrofits, the full retrofit investment costs of course had to be paid, but as these costs were so small in relation to the benefits (less than 5% of the CCS_New investments), it was still profitable to make these cascaded retrofits, in order to maximize the cashflows from the tax credits. By doing so, no operation years were left without getting those credits (except the two two first years 2021 and 2022). (You may notice even some overlap with each of those 13 years, but that of course did affect the credits, as any previous retrofit is retired when the new retrofit replaces it).

These results again highlight some of the complexities related to retrofitted processes.  As the formulation is now, it inevitably has to allow retrofits at any year over the lifetime of the original vintage, and it is not quite straightforward to automatically prevent such cascading retrofits from happening. But of course, such repeated retrofits would not make any economic sense, unless the tax credits were granted after any retrofit and were so high in relation to the retrofit investment cost, and so, this issue only arises under rather special circumstances.

However, in the case of your model, there is an easy way to prevent such cascaded retrofits by exogenously bounding any retirements of the retrofits to zero. I tested by doing so, and the issue no longer appeared. I defined the bounds for ATRNH3_CCS_retrofit as follows:

  PARAMETER RCAP_BND /
  US.0.ATRNH3_CCS_retrofit.UP  5
  US.2025.ATRNH3_CCS_retrofit.UP  0
  /;

Maybe you could consider that as a work-around solution against this kind of a problem?
However, I think I can also design an option for automatically preventing cascaded retrofits for the next release of TIMES.

Hi Antti,

Thanks for your reply and support. Your suggestion is really helpful. In addition, we would like to see the problem of cascaded retrofit will be solved in the next version of TIMES.

Best,

Enze

[Antti-L]

Ok, yes, I will implement an option for requesting it (I think cascading retrofits can be a technically valid option that may in some cases be reasonable).

But could you confirm whether or not bounding the retirements of retrofits to zero also does exactly what you like to see?  I would think it does exactly the same in the case of your model (based on my tests).

[ejin]

Ok, yes, I will implement an option for requesting it (I think cascading retrofits can be a technically valid option that may in some cases be reasonable).

But could you confirm whether or not bounding the retirements of retrofits to zero also does exactly what you like to see?  I would think it does exactly the same in the case of your model (based on my tests).

Hi Antti,

Bounding the retirements of retrofits to zero works in our model. Thanks!!!