I have a storage process (pump) which is defined as STS and is operating at the DAYNITE level. I use the NCAP_AFC for ANNUAL and DAYNITE timeslices and the same in/out commodity (ELC).
The units are GWe for the capacity and PJ for the output commodity, with a CAP2ACT=31.536.
The model has 288 timeslices distinguishing between 4 seasons and 3 typical days with 24 hours each (4*3*24=288).
I would like to report the charging and discharging profile of this process in terms of capacity per hour (during a 24-hour single typical day).
This can be done straightforward for the Var_Fout using the timeslice duration, the capacity and the CAP2ACT coefficient (as the VAR_SOUT variable participates in the capacity availability constraint CAP)
By applying the same procedure for Var_FIn, I get a result that exceeds the process' capacity in GWe for some timeslices.
There are no bounds affecting the result.
Is anyway to adjust Var_Fin (by declaring some additional parameter that I am missing) in order not to report charging power more than the process' capacity in a typical hour? Or do you suspect that I have a model specification error?
I attached the output that I get and the calculation I made to report the charge/discharge capacity in a year.
For storage processes, you can only have a capacity based on the stored amount, or based on either the output or input flow (when using NCAP_AFC), but not both. Therefore, if you would also want to restrict the charging flows by the same capacity as the output flows, at the moment that is a bit difficult (you would need to define an UC and an auxiliary flow). But the next TIMES version will allow an easy way for doing that.
However, I am not sure I understood your question correctly, as you were talking about reporting...
yes you understood very well the "reporting" (it is just for producing an excel chart).
I will do the UC constraint and AUX flow alternative (if necessary), but I was hopping to avoid it. It is good that it will be considered in the next TIMES version.
FWIW: In fact, you could also require both the input and output flows to be constrained by the capacity by using different electricity commodities for the input and output, because then you can define NCAP_AFC for both. But when using
the same commodity for both input and output, the current code allows only the output flows to be constrained by the capacity. And, as mentioned, this restriction will be relaxed in the next version.
This is related to the use of NCAP_AFC on both the input and output flow. I find this very useful in regards of modelling batteries in a relatively simple manner.
- Have anyone succeeded on doing this for a storage process in Answer-TIMES? I am currently struggling with this.....I know this is a VEDA forum but the questions is highly related to this previous post : ).
This should normally work well on the DAYNITE level, because usually one can assume that charging and discharging occur at different timeslices. Thus you can constrain the charging and discharging power levels to different maximum levels. However, on the SEASON or ANNUAL level one might want to define only an output availability.
Yes, I have the same commodity IN and OUT, and the process is on a storage DAYNITE level.
Since a process activity is defines as either Output-based or Input-based in Answer, I am currently only able to use NCAP_AFC on either the input or output commodity. I assume that there is either something that I have misunderstood, or that Answer-TIMES needs to be modified to be able to use NCAP_AFC on both input and output flows.
Hmm... that sounds strange. What are you trying to do for using NCAP_AFC on both input and output? And how does the fact that the process activity is defined as either Output-based or Input-based affect that?
If the input and output commodity is COM, and it is defining the PG, both the input and output will be in the PG.
I just tried it myself in ANSWER, with a storage having ELC as an input and an output. I was able to define NCAP_AFC(ELC) and NCAP_AFC(NRG) without any problems. So, that worked well, and then TIMES will define the AFC equation for both input and output, using the different availability factors for charging and discharging. Thus, unless I am missing something, that should work well.
This is good news! Thank you very much, now it works perfectly!
Previously, I did not include NCAP_AFC(NRG), only NCAP_AFC(ELC,) and that is the reason for why it did not work! I apologies for not reading the documentation more thorough.....
15-07-2021, 09:02 AM (This post was last modified: 15-07-2021, 09:06 AM by zheng.)
(24-07-2014, 12:41 PM)Antti-L Wrote:
Just a quick comment (being on holidays):
For storage processes, you can only have a capacity based on the stored amount, or based on either the output or input flow (when using NCAP_AFC), but not both. Therefore, if you would also want to restrict the charging flows by the same capacity as the output flows, at the moment that is a bit difficult (you would need to define an UC and an auxiliary flow). But the next TIMES version will allow an easy way for doing that.
However, I am not sure I understood your question correctly, as you were talking about reporting...
Dear Antti-L
Is this problem already solved in current version? I am using VEDA-FE version 4.5.834，GAMS_SRCTIMESV450。 I set a storage process as follows
Still in 2014, when using the same commodity for both input and output, the code allowed only the output flows to be constrained by the capacity.
AL2014>And, as mentioned, this restriction will be relaxed in the next version.
So, as mentioned, that restriction was indeed relaxed many years ago. In your case, if you want both the input and the output flow of ELC to be constrained by the same capacity, please define NCAP_AFC(NRG)=value instead of NCAP_AFC(ELC)=value.
20-07-2021, 09:36 PM (This post was last modified: 20-07-2021, 09:39 PM by zheng.)
(15-07-2021, 05:28 PM)Antti-L Wrote: Still in 2014, when using the same commodity for both input and output, the code allowed only the output flows to be constrained by the capacity.
AL2014>And, as mentioned, this restriction will be relaxed in the next version.
So, as mentioned, that restriction was indeed relaxed many years ago. In your case, if you want both the input and the output flow of ELC to be constrained by the same capacity, please define NCAP_AFC(NRG)=value instead of NCAP_AFC(ELC)=value.
Dear Antti-L
I tried to use AUX to constrain both the capacity of storage and power of a storage process. but this does not worked, there are only input or output of ELC (ELCC、ELCRC) and no AUXs when this process working. What is wrong in my model?
20-07-2021, 09:49 PM (This post was last modified: 20-07-2021, 09:51 PM by Antti-L.)
> I tried to use AUX to constrain both the capacity of storage and power of a storage process. but this does not worked, there are only input or output of ELC (ELCC、ELCRC) and no AUXs when this process working. What is wrong in my model?
I see no point in using an auxiliary storage flow to constrain both the capacity of storage and power of a storage process, because you can do that with NCAP_AFC. Can you explain why you are not using NCAP_AFC for this purpose?
However, of course it works also with an auxiliary commodity, if that would really be necessary. But unless you can explain why it would be necessary / desirable, I can only recommend using NCAP_AFC(ACT) for constraining the storage level (from above), NCAP_AFC(NRG) for bounding the input power level, NCAP_AFC(ELC) for bounding the output power level, and NCAP_AF(LO) / NCAP_AFS(LO) for constraining the storage level from below (if such is needed).
21-07-2021, 01:24 PM (This post was last modified: 21-07-2021, 02:12 PM by zheng.)
(20-07-2021, 09:49 PM)Antti-L Wrote: > I tried to use AUX to constrain both the capacity of storage and power of a storage process. but this does not worked, there are only input or output of ELC (ELCC、ELCRC) and no AUXs when this process working. What is wrong in my model?
I see no point in using an auxiliary storage flow to constrain both the capacity of storage and power of a storage process, because you can do that with NCAP_AFC. Can you explain why you are not using NCAP_AFC for this purpose?
However, of course it works also with an auxiliary commodity, if that would really be necessary. But unless you can explain why it would be necessary / desirable, I can only recommend using NCAP_AFC(ACT) for constraining the storage level (from above), NCAP_AFC(NRG) for bounding the input power level, NCAP_AFC(ELC) for bounding the output power level, and NCAP_AF(LO) / NCAP_AFS(LO) for constraining the storage level from below (if such is needed).
Thank you for the advice, but I still do not understand why the AUX does not work, there are only input or output of ELC (ELCC、ELCRC) , no input or output of AUXs when this EST process working.
And, I also have tried to use different NCAP_AFC(XXX) as in the attaeched file. however these data can not be readin. the error message is
Info: Column ignored due to alien element (NCAP_AFC(ELCRC))
Info: Column ignored due to alien element (NCAP_AFC(ELCC))
Info: Column ignored due to alien element (NCAP_AFC(ACT))
21-07-2021, 09:08 PM (This post was last modified: 22-07-2021, 09:13 PM by Antti-L.
Edit Reason: typo
)
NCAP_AFC expects a commodity group, and so it is safest to specify the CommGrp in the CommGrp column. In addition, NCAP_AFC expects a timeslice level, which you had omitted.
See the attached with these corrections. (Note that I have added a FI_Comm table just for my quick testing).
Concerning the auxiliary flow approach, I can understand that it might be necessary/useful if you would want to optimize the size of the charger, and therefore would like to model the charger as a separate process. But I cannot see from your earlier screenshot that you would have defined the auxiliary flows at all (they must be defined with FLO_FUNC or PRC_ACTFLO, see the documentation). But seeing only that limited screenshot, I am afraid I am not able to help you more with your auxiliary flows.
P.S. Times attributes have certain indexes, for example NCAP_AFC(r,y,p,cg,tslvl). By using the shorthand notation NCAP_AFC(ACT), NCAP_AFC(ELC), I was meaning that the cg in NCAP_AFC is specified as 'ACT' or 'ELC', respectively.
