I am curently leanrning how to use VEDA and the TIMES model.
I have a question about the two attributes NCAP_AFA and NCAP_AFC : I understand they represent the load factor of a process, the former modelling a sort of mean value over all the commodities that come out of a process, and the latter representing a sort of relative value, but I'm not sure actually .
Can someone tell me how to interpret these values ? i.e. How can I understand a process with both AFA and AFC defined ? Which one is to be taken in consideration when I want to know the loda factor of this one process over a specific commodity ?
30-04-2021, 04:34 PM (This post was last modified: 30-04-2021, 04:44 PM by Antti-L.)
Have you not been reading the documentation, or under VEDA2, looking at Information → TIMES Attributes?
From both places you can find basic info, e.g. the descriptions:
NCAP_AFA: Annual availability factor relating the annual activity of a process to the installed capacity.
NCAP_AFC: Commodity-specific availability of capacity for commodity group cg, at given timeslice level.
In the documentation you can see also the equation formulations.
> How can I understand a process with both AFA and AFC defined?
As you already know, NCAP_AFA defines an ANNUAL utilization factor (min./max./fixed), while NCAP_AFC defines a commodity-specific availability at given timeslice level. Both are taken into consideration if both are defined, but if they happen to be both specified at the ANNUAL level and the bound type of NCAP_AFA is UP/FX, then they are (by default) multiplied and only the AFC constraint is generated, as you can see from the documentation. But optionally, you can define them independently also in that case.
(30-04-2021, 04:34 PM)Antti-L Wrote: Have you not been reading the documentation, or under VEDA2, looking at Information → TIMES Attributes?
From both places you can find basic info, e.g. the descriptions:
NCAP_AFA: Annual availability factor relating the annual activity of a process to the installed capacity.
NCAP_AFC: Commodity-specific availability of capacity for commodity group cg, at given timeslice level.
In the documentation you can see also the equation formulations.
> How can I understand a process with both AFA and AFC defined?
As you already know, NCAP_AFA defines an ANNUAL utilization factor (min./max./fixed), while NCAP_AFC defines a commodity-specific availability at given timeslice level. Both are taken into consideration if both are defined, but if they happen to be both specified at the ANNUAL level and the bound type of NCAP_AFA is UP/FX, then they are (by default) multiplied and only the AFC constraint is generated, as you can see from the documentation. But optionally, you can define them independently also in that case.
Thank you !
I will go deeper in the documentation, I first checked what was told about this question in it but I found difficult to understand the difference. That's why I asked it in the forum.
Regards,
Ange
(30-04-2021, 04:34 PM)Antti-L Wrote: Have you not been reading the documentation, or under VEDA2, looking at Information → TIMES Attributes?
From both places you can find basic info, e.g. the descriptions:
NCAP_AFA: Annual availability factor relating the annual activity of a process to the installed capacity.
NCAP_AFC: Commodity-specific availability of capacity for commodity group cg, at given timeslice level.
In the documentation you can see also the equation formulations.
> How can I understand a process with both AFA and AFC defined?
As you already know, NCAP_AFA defines an ANNUAL utilization factor (min./max./fixed), while NCAP_AFC defines a commodity-specific availability at given timeslice level. Both are taken into consideration if both are defined, but if they happen to be both specified at the ANNUAL level and the bound type of NCAP_AFA is UP/FX, then they are (by default) multiplied and only the AFC constraint is generated, as you can see from the documentation. But optionally, you can define them independently also in that case.
Yet, something I can't understand is the meaning of NCAP_AFC = -1, do you have any idea how we can interpret that physically ?
Thank you for your help
30-04-2021, 08:33 PM (This post was last modified: 30-04-2021, 08:56 PM by Antti-L.)
Where do you see such used? In your model? So, why do you use such, if you don't see it meaningful?
I do not know any use for such an NCAP_AFC parameter, except as an interpolation option. I have never seen anyone suggesting to define a negative availability factor, other than you.
Ok then. I guess it is someone else's model, which you are trying to understand?
Anyway, just for the record some additional info:
Because NCAP_AFC(r,y,p,cg,tslvl) = X, where X ≤ 0, is more or less meaningless (even zero is meaningless, as it would cause a divide by zero in the equation), the TIMES code automatically changes any such values to INF or to 1 (the latter only if the process is a storage process and cg is a commodity). The value of INF causes the commodity to be simply omitted from the equation, whereas the value 1 is the default value for an availability factor. Zero availability factors additionally cause independent constraints to be generated for the cg in question, forcing the flows of cg to zero, which is clearly what a zero availability for cg should imply.
Hence, for NCAP_AFC, the cases where the value is converted to INF may in fact have a rare use case when the process has a flow in the PG that should nonetheless not be contributing to the capacity availability. An example would be a hydro power plant with a fixed inflow profile and a reservoir storage, where at times of flooding some of the inflow may me spilled when the storage is full and thus cannot contribute to electricity generation. The spill flow should therefore be removed from the power plant availability constraint, and that could be done by using a negative NCAP_AFC(r,y,p,NRG,tslvl). But one could also request independent AFC equations for the same purpose.
Finally, please note that NCAP_AF / NCAP_AFA / NCAP_AFS are the primary attributes for defining process availability and utilization factors on any timeslice levels. NCAP_AFC is quite rarely needed, e.g. for storage processes and some types of demand processes with flexible output shares.
(01-05-2021, 09:32 PM)Antti-L Wrote: Ok then. I guess it is someone else's model, which you are trying to understand?
Anyway, just for the record some additional info:
Because NCAP_AFC(r,y,p,cg,tslvl) = X, where X ≤ 0, is more or less meaningless (even zero is meaningless, as it would cause a divide by zero in the equation), the TIMES code automatically changes any such values to INF or to 1 (the latter only if the process is a storage process and cg is a commodity). The value of INF causes the commodity to be simply omitted from the equation, whereas the value 1 is the default value for an availability factor. Zero availability factors additionally cause independent constraints to be generated for the cg in question, forcing the flows of cg to zero, which is clearly what a zero availability for cg should imply.
Hence, for NCAP_AFC, the cases where the value is converted to INF may in fact have a rare use case when the process has a flow in the PG that should nonetheless not be contributing to the capacity availability. An example would be a hydro power plant with a fixed inflow profile and a reservoir storage, where at times of flooding some of the inflow may me spilled when the storage is full and thus cannot contribute to electricity generation. The spill flow should therefore be removed from the power plant availability constraint, and that could be done by using a negative NCAP_AFC(r,y,p,NRG,tslvl). But one could also request independent AFC equations for the same purpose.
Finally, please note that NCAP_AF / NCAP_AFA / NCAP_AFS are the primary attributes for defining process availability and utilization factors on any timeslice levels. NCAP_AFC is quite rarely needed, e.g. for storage processes and some types of demand processes with flexible output shares.
Thank you for this developped response. Actually I'm using the JRC EU TIMES model and I try t understand how heat pumps are modelled in it. One think still hard to grasp for me is the meaning of the NCAP_AFC attribute for these technologies. The values are very low and have important effects on the results. Do you have any idea why one would define an AFC attribute for a heating technology ?
14-05-2021, 06:21 PM (This post was last modified: 15-05-2021, 09:12 PM by Antti-L.)
Well, heat pumps can provide space heat, space cool, and also hot water. And the availability of producing space heat and cool are quite different, especially between seasons, but also on the ANNUAL level. Therefore, the modeller might be tempted to use NCAP_AFC to capture these differences. That would require using independent NCAP_AFC constraints (and so specifying the special flag NCAP_AFC(r,'0',p,'ACT',tsl) = -1). The meaning of the independent NCAP_AFC constraints is very simple: NCAP_AFC(r,y,p,C,tsl) defines the maximum level of output C in proportion to the capacity, independently of the other outputs. In simplified terms the constraint is as follows, for each ts:
However, using NCAP_AFC is hardly the best practice if the optimal output shares are known beforehand. And as far as I can see, that is indeed the case for in-house heat pumps, as one can see from the graph in that thread: the optimal solution will be the point maximizing the combined output of space heat and cool. Therefore, one can calculate the combined availability and output shares beforehand, and use NCAP_AF / AFA instead, and fixed output shares (and load profiles for space heat / cool).
19-05-2021, 07:27 PM (This post was last modified: 19-05-2021, 07:29 PM by AngeBlanchard.)
To be sure I understand well, could you tell me if I'm wrong saying that:
1) Availability factors are used for heating technologies to model the fact people don't use their heating devices all the time. It avoids the model to invest in a small amount of devices and to use them 100% of the time, which would be an economic optimal but a non-sense (the fact your neighbour uses his boiler all the time is not of great help if you are freezing in your own house). This modeling technique is needed because TIMES agregates all the heating demands from the dwellings into one unique demand he tries to fullfil.
2) In the model I work on (i.e. JRC-EU-TIMES) the only availability factors defined for heating technologies are NCAP_AFA and NCAP_AFC (I can see no other AF* attribute defined for these appliances in the items detail window). NCAP_AFA is defined with a lower limit of 1% and is not dependant on the technology. I'm not sure why it is used, do you have any idea ? On the contrary NCAP_AFC is defined with a upper limit, is technology-dependant and specified with the special flag NCAP_AFC(r,'0',p,'ACT',tsl) = -1, so I guess they are used to model what is said in point 1)
19-05-2021, 08:58 PM (This post was last modified: 19-05-2021, 09:12 PM by Antti-L.)
1) Yes, ANNUAL availability factors are regularly used as utilization factors (so like capacity factors). Unlike for energy conversion technologies (e.g. power plants), one cannot optimize the capacity factors of demand technologies, which are installed for each end-use consumer. They should reflect the reality reasonably well (typical usage e.g. by house type and/or age). In reality, in-house heating systems do have quite low annual capacity factors.
2) I am not familiar with the JRC model, but I do have the DD files of the Baseline scenario of that model. Looking at them, I cannot confirm that NCAP_AFA would be always defined with a lower limit of 1%. I can see they are not dependent on the technology, but only on house type and region. For example, I can see that in Belgium AFA(LO) = 0.04191673 for space heating technologies in detached houses. This is in Subres 30_techs_heatingcooling, can you verify/confirm?
I am not sure why these lower bounds have been defined. I would expect the technologies to be used up to the maximum capacity factor, if the model decides to invests in them. But maybe they are there to improve the model behaviour e.g. under elastic demands, where the demand changes might cause unrealistic differences in the capacity factors across technologies(?).
Concerning the upper limits, if NCAP_AFC(r,'0',p,'ACT',tsl)= -1 is being used, it means that maximum availability factors (or "capacity factors") are modeled independently for space heat and cool (and maybe hot water as well?).
You're right, AFA are dependant on the region and the house type, as you can see on the screenshot I join to this message. It seems weird to me to define such a lower constraint for the exact reasons you mention, but anyway I guess the JRC team have a valid reason to do that...
03-10-2024, 09:59 PM (This post was last modified: 03-10-2024, 10:36 PM by Antti-L.)
(30-04-2021, 04:34 PM)Antti-L Wrote: Have you not been reading the documentation, or under VEDA2, looking at Information → TIMES Attributes?
From both places you can find basic info, e.g. the descriptions:
NCAP_AFA: Annual availability factor relating the annual activity of a process to the installed capacity.
NCAP_AFC: Commodity-specific availability of capacity for commodity group cg, at given timeslice level.
In the documentation you can see also the equation formulations.
> How can I understand a process with both AFA and AFC defined?
As you already know, NCAP_AFA defines an ANNUAL utilization factor (min./max./fixed), while NCAP_AFC defines a commodity-specific availability at given timeslice level. Both are taken into consideration if both are defined, but if they happen to be both specified at the ANNUAL level and the bound type of NCAP_AFA is UP/FX, then they are (by default) multiplied and only the AFC constraint is generated, as you can see from the documentation. But optionally, you can define them independently also in that case.
Hi!
I am also confused about this point, if I define the NCAP_AFA=0.5, and NCAP_AFC=0.5 for one specific timeslice (like FD), does that mean the activity level <STOCK*CAP2ACT*0.25?
Besides, if we remove the NCAP_AFA defination, does that mean the activity level <STOCK*CAP2ACT*0.5?
