Veda2.0 Released!


Implementing minimum utilization factor/activity of a technology over the time
#1
Hello,

I am modeling low-carbon ammonia production pathway in TIMES for reaching net-zero by 2050. To prevent sudden switch between low-carbon technologies (based on our target emission reduction trajectory over the time horizon: 2020 to 2050), I aim to define lower bounds for the capacity utilization such that a technology is used during its whole technical lifetime. I am wondering whether it is possible to define a minimum utilization factor for a technology by its age, such that the plant activity is decreased smoothly. To this purpose we need to specify its utilization factor for each milestone year? 

Besides, could we also impose a constraint such as:
utilization factor (or activity) of a technology at time (t+1) > 0.5*utilization factor (or activity) of a technology at time (t)


which pushes the model to utilize any existing technology at each time point no less than 50% of its utilization (or activity) in the last time point.

I would be grateful to have any advice on that. Thanks.

Best
Banafsheh
Reply
#2
Shaping of availability/utilization factors by age is relatively easy, but requires several parameters:

  ● NCAP_AFS(reg,year,prc,ts,bd) = value;   – defines the AFS factor
  ● NCAP_AFX(reg,year,prc) = index;   – defines the SHAPE index for the AF/AFS factor
  ● SHAPE(j,age) = multiplier;           – defines the SHAPE multiplier according to age

However, when using lower bounds on availability, this currently works well only for processes defined at the ANNUAL level.  This is because when defined, the shape is currently applied to both UP and LO factors if both are defined. I hope your processes are ANNUAL?  Then you can define UP bounds by NCAP_AFA and the shaped LO bounds by NCAP_AFS.  Anyway, I will try taking care of that in the next version of TIMES it will be more generally possible to handle UP and LO factors differently with respect to shaping.

Also, a user constraint requiring something like:  VAR_ACT(y+1) ≥ VAR_ACT(y) × C  would also be easy to formulate.  Here, the multiplier C would be the allowed proportional annual decrease in activity. But a 50% annual decrease would be rather steep, and so I would suggest a smaller value, e.g. 10%/a.  However, without taking also into account changes in capacity, it would require some process activity infinitely, and therefore I think one might want to try and take into account also the impact of capacity changes. I leave it to you to consider how it might be best formulate such a constraint mathematically, but for expressing it in VEDA, see example below (where a 10% allowed annual decrease is assumed, and half of capacity change is considered). The shaping of AFS(LO) (annual minimum utilization factor) is also illustrated below.

   

Note also that I have tested these examples myself, and verified that they work as expected. But let me know if you see any problem...
Reply
#3
(01-09-2022, 09:29 PM)Antti-L Wrote: Shaping of availability/utilization factors by age is relatively easy, but requires several parameters:

  ● NCAP_AFS(reg,year,prc,ts,bd) = value;   – defines the AFS factor
  ● NCAP_AFX(reg,year,prc) = index;   – defines the SHAPE index for the AF/AFS factor
  ● SHAPE(j,age) = multiplier;           – defines the SHAPE multiplier according to age

However, when using lower bounds on availability, this currently works well only for processes defined at the ANNUAL level.  This is because when defined, the shape is currently applied to both UP and LO factors if both are defined. I hope your processes are ANNUAL?  Then you can define UP bounds by NCAP_AFA and the shaped LO bounds by NCAP_AFS.  Anyway, I will try taking care of that in the next version of TIMES it will be more generally possible to handle UP and LO factors differently with respect to shaping.

Also, a user constraint requiring something like:  VAR_ACT(y+1) ≥ VAR_ACT(y) × C  would also be easy to formulate.  Here, the multiplier C would be the allowed proportional annual decrease in activity. But a 50% annual decrease would be rather steep, and so I would suggest a smaller value, e.g. 10%/a.  However, without taking also into account changes in capacity, it would require some process activity infinitely, and therefore I think one might want to try and take into account also the impact of capacity changes. I leave it to you to consider how it might be best formulate such a constraint mathematically, but for expressing it in VEDA, see example below (where a 10% allowed annual decrease is assumed, and half of capacity change is considered). The shaping of AFS(LO) (annual minimum utilization factor) is also illustrated below.



Note also that I have tested these examples myself, and verified that they work as expected. But let me know if you see any problem...

Thank you so much for the thorough explanation and sharing the examples. It really helped. 

Best
Banafsheh
Reply
#4
Ok, thanks.

But I see now that failed to give explicit answers to your questions:

Q1> I am wondering whether it is possible to define a minimum utilization factor for a technology by its age, such that the plant activity is decreased smoothly.

A1>  It is possible to define a minimum utilization factor for a technology by its age, such that the minimum plant utilization factor decreases according to a user-defined trajectory, as a function of age.  However, defining such does not imply that the plant activity would necessarily be decreasing smoothly, although you seemed to assume so in the question.

The means for defining such minimum utilization factors (i.e. minimum average annual capacity factors) for a technology by its age is the NCAP_AFX attribute, together with the NCAP_AFS(ANNUAL,LO) and SHAPE attributes. Note that NCAP_AFA(LO) cannot be used for defining such an age profile, because NCAP_AFA is always non-vintaged (not vintage-specific). On the other hand, NCAP_AFS(ANNUAL,bd) is always vintage-specific, and therefore suits well for this purpose.

However, currently this would work well only for technologies defined at the ANNUAL timeslice level, because NCAP_AFX is currently applied to all NCAP_AF and NCAP_AFS(ANNUAL) parameters, and so if the technology would be defined e.g. on the DAYNITE level, one would end up shaping both minimum and maximum utilization factors with the same shape. But you can expect this limitation to be removed in the next version of TIMES.  Anyway, if your technologies are at the ANNUAL level (PRC_TSL=ANNUAL), you can avoid this issue, by defining the maximum utilization factors with NCAP_AFA(UP), and the minimum factors with NCAP_AFS(ANNUAL,LO), which are shaped by age.

Q2> To this purpose we need to specify its utilization factor for each milestone year?

A2>  If you want to define a minimum utilization factor for a technology strictly by its age, then you only need to define the "base" value for the utilization factor, plus the SHAPE index that defines age-dependent multipliers for this base value, for deriving the utilization factors by age.  In this age-profile approach, there is thus no need to define utilization factors for each milestone year, as you can also see from my example above.

However, for technologies that only represent the capacity of an existing plant defined by PRC_RESID (aka Stock in VEDA) or NCAP_PASTI, one could also accomplish the same effect by defining non-vintage dependent minimum utilization factors for each milestone year, by using NCAP_AFA(LO). This would work for technologies operating at any timeslice level.  And in fact, one cannot even use the shaping method for PRC_RESID capacities, because they do not have any well-defined age.
Reply
#5
Thanks a lot for the explanations.
I tried the growth constraint on the activity and capacity for each technology but the results does not seem to reflect it properly! Based on your suggestion I defined the constraint as attached. To make sure I defined the UC constraint correctly, Could I ask you to confirm it that the meaning of the defined constraint in the attached file is as below:


For UC_ATTR (ACT,GROWTH) constraint, it equals to "VAR_ACT(t)*(0.9^5) < VAR_ACT(t+1)", right?
(for the growth, the UC_ACT should be powered by the number of years between milestone years? In my my model milestone years are defined from 2020 to 2050 as: 2020, 2025,2030,2035,2040,2050. I assume this means the value of UC_ACT should be powered by M(t+1)-M(t)=5?!)

For UC_ATTR (CAP,CAPACT), does it maybe mean "VAR_CAP(t)*0.5 VAR_ACT(t+1)" ?   
I am not really sure about this constraint and why the value of UC_CAP (CAPACT) is -0.5 but not 0.5! Definitely I misunderstood the way you defined it... Could you please advise me on its definition?
Besides, when we do not define the year for the constraint implementation, it means it applies over the whole prediction horizon, right?

Overall, I think when I define the constraint only as VAR_ACT(t)*UC_ACT VAR_ACT(t+1), it means we do not allow the activity of a process to get reduced to zero (unless its life-time ends), right? while I know that it might be required to stop the activity of a process at some point and switch to another process in order to have our CO2 emission constraint fulfilled. In fact, our purpose for defining such a constraint on process activity is to prevent a sudden switch between technologies (which is not favorable practically), and to make this switch smoother! However, we are still sure that switch between processes should happen in order to follow the total emission target (75% and 95% emission reduction by 2050 compared to today's values). I would be grateful to have your idea on that and sorry if I misunderstood any points from your aforementioned advises.

Best
Banafsheh


Attached Files
.xlsx   Scen_Activity_bounds.xlsx (Size: 23.53 KB / Downloads: 7)
Reply
#6
Ok, I will try to address your questions below. Let's first write down again the constraints discussed, in mathematical terms, see Box 1:
   

Your original idea is shown in the first line in Box 1 shown above: VAR_ACT(y+1) ≥ VAR_ACT(y) × Coef .
The TIMES formulation of that constraint, based on model periods and using the dynamic type (t,t+1), is shown in the second line above. And finally, in the third line you can see the formulation of my earlier example, where I added the VAR_CAP difference (without showing the CAPACT multipliers here for simplicity), to consider also changes in capacity, such that if there is one unit of capacity added, we require some more activity (corresponding to at least half of the capacity change), and if there is some capacity retired, we allow less activity, respectively.  Note also that the VAR_ACT(t), VAR_FLO(t) and VAR_CAP(t) terms of TIMES user-constraints are not vintage-specific, and therefore I have omitted the vintage index v from VAR_ACT(..) terms (as a shorthand for sums over vintages). The third line is thus equivalent to the user constraint example I posted earlier.

Now to your questions:

> Could I ask you to confirm it that the meaning of the defined constraint in the attached file is as below: For UC_ATTR (ACT,GROWTH) constraint, it equals to "VAR_ACT(t)*(0.9^5) < VAR_ACT(t+1)", right?

No, in the file you attached you have only included the terms on the LHS side. Your constraint is therefore:  VAR_ACT(r,t,p) × (0.9^5) − VAR_CAP(r,t,p) × 0.5 ≤ 0 . In a constraint of dynamic type (t,t+1), the terms on the LHS side refer to the period t, and the terms on the RHS side refer to the period t+1. But because you have excluded all RHS terms, your constraint is thus not dynamic.

> (for the growth, the UC_ACT should be powered by the number of years between milestone years? In my my model milestone years are defined from 2020 to 2050 as: 2020, 2025,2030,2035,2040,2050. I assume this means the value of UC_ACT should be powered by M(t+1)-M(t)=5?

Yes, that is correct.  But as you have no RHS terms, your constraint is not a dynamic constraint, as explained above.

> For UC_ATTR (CAP,CAPACT), does it maybe mean "VAR_CAP(t)*0.5 < VAR_ACT(t+1)" ?

In a user constraint, the UC_ATTR(CAP,CAPACT) modifier instructs TIMES to multiply the VAR_CAP term by the PRC_CAPACT parameter, as explained in the documentation.  I included this modifier to make sure the that the VAR_CAP terms are converted to the amount of activity equivalent to the full capacity, in the correct activity unit. If your PRC_CAPACT=1 (or is left undefined), that modifier will of course have no impact. But as I could not know about that without seeing your model, I only tried to be on the safe side here.

> I am not really sure about this constraint and why the value of UC_CAP (CAPACT) is -0.5 but not 0.5! Definitely I misunderstood the way you defined it... Could you please advise me on its definition?

Please take a look at Box 1 above, and you should see what it means. The VAR_CAP terms are multiplied by −0.5, because I suggested to take into account the capacity change as follows:

   VAR_ACT(t+1) ≥ VAR_ACT(t)×(0.9^5) + [VAR_CAP(t+1) − VAR_CAP(t)]×0.5

This is the same constraint as in Box 1, with just the terms arranged. As you can see, if the capacity increases by an amount ΔC in (t+1), it requires the activity to be 0.5×ΔC larger than in the case of constant capacity.  And if the capacity decreases by an amount ΔC, it allows the activity become 0.5×ΔC smaller in (t+1).  You should also immediately see why the multiplier is not 1, but chosen to be 0.5 here. If the multiplier would be 1, we would be implicitly assuming a utilization factor of 1 for the capacity change, which is obviously too much.

> Besides, when we do not define the year for the constraint implementation, it means it applies over the whole prediction horizon, right?

Not really. The UC_RHSRT parameter defines the years for the constraint implementation, and I used the IE option 2 for UC_RHSRT.  As you know, this option fills all the undefined Milestone years with a zero value.  In that way, I did indeed define the years for the constraint implementation, because I defined UC_RHSRT for all Milestone years.

> Overall, I think when I define the constraint only as VAR_ACT(t)*UC_ACT < VAR_ACT(t+1), it means we do not allow the activity of a process to get reduced to zero (unless its life-time ends), right?

It effectively means that the activity of the process can never be reduced to zero (within the model horizon), regardless of the process lifetime. For example, if your model horizon would be 2020–2100, any of these processes would have to operate until 2100, if they are used in any earlier year. This would be a direct consequence of the simplified recurrence relation:

  VAR_ACT(t+1) ≥ VAR_ACT(t)*UC_ACT

Clearly, VAR_ACT(t) can then never reach zero in year t if there is a year t1 less than t such that VAR_ACT(t1)>0, would you not agree?

P.S: Would you mind answering my earlier question (whether the ammonia processes are ANNUAL or not)?
Reply
#7
> In fact, our purpose for defining such a constraint on process activity is to prevent a sudden switch between technologies (which is not favorable practically), and to make this switch smoother!

There has been another user on the Forum also posting modeling questions related to ammonia production, with seemingly very similar selection of processes as you are using! 
I am sorry if my impressions are unfounded, but these similarities have led me to think that maybe ejin and you are colleagues working on the same modeling issues?  If so, have you looked at the thread where I helped by improving the retrofits modeling and thereby produced results showing a much smoother transition in the production technologies?  See the picture below:
[Image: attachment.php?aid=1475]

Moreover, from this figure you can also see that the total capacity is constant at 16.5 Mt, which was equal to the demand in that model and therefore all of the production capacity was being utilized 100% throughout the model horizon. Hence, using any lower bounds on technology utilization would of course not accomplish anything in this case:  The capacity of each and every technology is being utilized 100% throughout their lifetimes, and so there are no such sudden switches between technologies, which would leave some capacity at too low utilization or even unutilized. Consequently, if you happen to be working with this together, I am now a bit confused as to what you actually mean by trying to "prevent sudden switch between low-carbon technologies", because at least in terms of capacity utilization, such issues were non-existent in those results.  Maybe you could clarify that for me to better understand the nature of the issue?

However, I apologize if it was inappropriate to assume any connection with the other Forum user.
Reply
#8
You are exactly right! ;-) We are colleagues working on the low-carbon ammonia production together. 

However, we are working on different scenarios. I am modeling a decarbonized pathway with 95% emission reduction for ammonia by 2050 (compared to today's emissions), while ammonia demands also increases over the prediction horizon (2020-2050). The existing technology for ammonia production is SMR (steam methane reforming), which should be retrofitted by CCS installations and/or be replaced by other innovative low-carbon technologies to address the target emission reductions. Below a figure is attached in which the results for ammonia production trajectory is plotted (in case no constraint on the activity reduction for each technology is considered). From that you can see that the ATR (with or without CCS) is built from 2035 with increased capacity through 2045 but in 2050 most of that is replaced by water electrolysis technology in order to achieve the 95% emission reduction in 2050. So my purpose from adding the constraint on the level of activity reduction of each technology was to make the transition between technologies a bit smoother instead of such switch between them to address practical feasibility of the future ammonia production pathway.
Thanks to your advises, I now revised the constraint on activity for new low-carbon technologies (as you pointed out, my mistake was that I did not define the RHS of the constraint) such that it works properly. The new results are also attached here: as you can see now the transitions between technologies are smoother which makes the model outputs to be more practical, but with the higher total production cost of course. I also attached the modified version of the constraint here. 

Thanks a lot for your helps.
Best
Banafsheh


Attached Files Thumbnail(s)
       

.xlsx   Scen_Activity_bounds (2).xlsx (Size: 23.47 KB / Downloads: 5)
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)