30-05-2019, 03:47 PM (This post was last modified: 30-05-2019, 03:53 PM by MohammedAbiAfthab.
Edit Reason: to add more
)
Hello,
I have a few doubts related to defining storage in TIMES.
1) I have my investment cost in terms of the maximum storage volume possible. Therefore, I need to represent my capacity as the amount of storable energy. As per the TIMES documentation, capacity can be represented in three ways; output flow is the basis for capacity (NCAP_AFC(o)=1), input flow is the basis for capacity (NCAP_AFC(i)=1) or the basis is the amount stored. I believe my case is the final one. Does this mean I do not have to define any NCAP_AFC to make my capacity represent the amount of storable energy? I did this way and I am getting strange results. My capacity is very small but my Var_Fin, Var_Fout and Var_Act are all larger than my capacity. Is this possible?
2) In another case, my investment cost is in terms of Euro/PJa. I defined NCAP_AFC=1 and I am getting the capacity in terms of the output flow in a year (equal to my Var_Fout; my efficiency is 1). This is what I wanted. But in TIMES advanced documentation I saw an example where it is defining the NCAP_AFC=0.33. In that case in the results, capacity is in terms of GW but not in energy units (Var_FOut is energy units and not equal to Var_Cap). Why there is a difference between this case and my case?
3) When it says NCAP_AFC(o), how do I put it in the VEDA excel sheet. Is it like I add one column next to NCAP_AFC column with attribute CommGrp and input as my output commodity. If this is a Veda question, please let me know, I will post in VEDA Forum.
4) Also, my input and output commodities are different ( I am doing this to enforce the commodity flow only through storage and commodity cannot bypass the storage). To enable this I have defined my PCG as the output commodity which is mentioned in the TIMES documentation. Is this a right approach?
5) Var_Act is the amount of energy being stored as I understood from the documentation. That means if we take two consecutive time slices T1 and T2, Var_Act (T1)+Var_FIn(T1)-Var_FOut(T1)= Var_Act (T2), this will be satisfied always, right?
30-05-2019, 09:41 PM (This post was last modified: 30-05-2019, 10:15 PM by Antti-L.)
1) If you define any NCAP_AFC (i.e. a flow-based availability factor), your capacity will be flow-based. To have the capacity instead represent the amount of storable energy, you should not define it to be flow-based. And, when the capacity is the amount of storable energy, of course the Var_Fin, Var_Fout and Var_Act are usually all larger than the capacity (unless you would have only a one storage cycle in a year/season). For example, many batteries are typically charged/discharged on a daily basis, and not only once per year or season. For a DAYNITE storage, the input/output flows thus obviously become usually much larger than the capacity, as described in the documentation. For example, if the summer season is 92 days long, and the DAYNITE cycle under it is a representative summer day, assume that a certain storage is fully charged and discharged once each day. Then the input/output flows within the summer would be 92 times as high as the capacity.
2) I am not able to confirm you findings. If I put NCAP_AFC=1 (and STG_EFF=1, PRC_CAPACT=1), I am getting capacity equal to Var_Fout as you said, but if I define NCAP_AFC=0.33, I am getting capacity equal to Var_Fout/0.33. Thus, I am not seeing the capacity unit changing from PJ to GW, as you claimed. Please provide a reproducible test case demonstrating the issue.
3) You are not saying which table you are using (e.g ~TFM_INS, ~FI_T), but looking at 2), it looks like you are already able to define NCAP_AFC. There is no difference in defining it for the input or output commodity (unless they are the same, but you said you have them different). Thus, I don't quite understand the question, and perhaps it would indeed be better to post it on the VEDA Forum. Anyway, I just made a quick test with a ~TFM_INS, and specifying the commodity for NCAP_AFC worked equally well both in the Cset_CN and the Other_Indexes column.
4) The PCG of a storage process should include the charged and discharged commodities. So, if you have com1 as a charged commodity and com2 as a discharged commodity, you should thus define them both in the PCG. If they are both of type NRG, usually defining PCG=NRG would be the best choice.
I have a few questions based on my observations with my model and the answers provided by you. Please find my responses and further queries below each point. Could you kindly clarify? I have mentioned the name of the processes wherever I am mentioning a problem.
For your reference, I am attaching my base year templates, sub_Res file, .dd and .run files.
For your information, I am trying to model hydrogen storage. One for a hydrogen refuelling station for transport (in this case I want to represent my storage in terms of maximum hydrogen that could be stored at a time) and other for the industrial feedstock hydrogen (in this case I am representing storage capacity in terms of stored hydrogen in a year).
1) If you define any NCAP_AFC (i.e. a flow-based availability factor), your capacity will be flow-based. To have the capacity instead represent the amount of storable energy, you should not define it to be flow-based. And, when the capacity is the amount of storable energy, of course the Var_Fin, Var_Fout and Var_Act are usually all larger than the capacity (unless you would have only a one storage cycle in a year/season). For example, many batteries are typically charged/discharged on a daily basis, and not only once per year or season. For a DAYNITE storage, the input/output flows thus obviously become usually much larger than the capacity, as described in the documentation. For example, if the summer season is 92 days long, and the DAYNITE cycle under it is a representative summer day, assume that a certain storage is fully charged and discharged once each day. Then the input/output flows within the summer would be 92 times as high as the capacity.
Yes, now I understand the logic. Thanks for this. But there is an observation in my model results. In some years, I have Var_FIn, Var_Fout and Var_Act (extremely small values, like 0.00004). But Var_cap is not reported (Process is HYGNSTG_new). Is this possible? This means my INVCOST is also 0 which should not be the case. In this case, I have not defined NCAP_AFC and I want my storage capacity to represent the maximum energy that can be stored. Also, the process set membership is inputted as STS.
2) I am not able to confirm you findings. If I put NCAP_AFC=1 (and STG_EFF=1, PRC_CAPACT=1), I am getting capacity equal to Var_Fout as you said, but if I define NCAP_AFC=0.33, I am getting capacity equal to Var_Fout/0.33. Thus, I am not seeing the capacity unit changing from PJ to GW, as you claimed. Please provide a reproducible test case demonstrating the issue.
In the example provided in the advanced documentation, NCAP_AFC is 0.33. But in the results shown in page number 27, I cannot see such a relationship between Var_Fout and Var_Cap. Here there is a small efficiency loss. I guess here the Var_Cap in GW units unlike PJ which is the unit of Var_Fout. I found that there is a CAP2ACT 31.536 defined. So now I understand.
I have another observation. When I define the process as STS, NCAP_AFC=1 and eff=1, in some years my Var_Cap is higher than Var_Fout (Process I have checked is HYGNINDSTGcap_new). But this is not happening when I define my storage process as STG. Why this is so?
3) You are not saying which table you are using (e.g ~TFM_INS, ~FI_T), but looking at 2), it looks like you are already able to define NCAP_AFC. There is no difference in defining it for the input or output commodity (unless they are the same, but you said you have them different). Thus, I don't quite understand the question, and perhaps it would indeed be better to post it on the VEDA Forum. Anyway, I just made a quick test with a ~TFM_INS, and specifying the commodity for NCAP_AFC worked equally well both in the Cset_CN and the Other_Indexes column.
Sorry, my table is ~FI_T .
4) The PCG of a storage process should include the charged and discharged commodities. So, if you have com1 as a charged commodity and com2 as a discharged commodity, you should thus define them both in the PCG. If they are both of type NRG, usually defining PCG=NRG would be the best choice.
I checked my results for this. But in some time slices (I have 20*24=480 time slices), I am getting a small difference. For example, my Var_Act(T1)+ Var_FIn(T1)-Var_FOut(T1)-Var_Act(T2) is not always 0. I am getting numbers like 0.0002 in some time slices. Is that possible? I have tried this by defining storage process as both STG and STS. This is violated more when the process is defined as STS (Process I have checked is HYGNINDSTGcap_new). I understand that for STS, the storage can be carried over between seasons.
02-06-2019, 01:19 AM (This post was last modified: 02-06-2019, 04:25 AM by Antti-L.)
Ok, below I will try to answer briefly to the new comments and questions for each case:
1) Issue with HYGNSTG_new, where capacity is the amount of storable energy.
Abi Afthab Wrote:In some years, I have Var_FIn, Var_Fout and Var_Act (extremely small values, like 0.00004). But Var_cap is not reported (Process is HYGNSTG_new). Is this possible?
As I have explained earlier on this Forum and elsewhere, if the capacity is the amount of storable energy, you can have simultaneous input/output storage flows in the same timeslice without any need for capacity, because then nothing gets stored. I guess that may well explain any notable input/output flows also in your case. I looked briefly at your results for one year, and apart from the smallest tiny values the input/output values in general appeared equal to each other in the same timeslice, but I did not have time to look at it extensively. But mathematically it would be impossible to have a positive activity and no capacity. Numerically that may be possible, if either your solver is bad or your model is badly scaled. The model is solved numerically, not analytically, and therefore badly scaled models may have constraints violated by small amounts. In well-scaled models any such violations are negligibly small.
2) I was wondering what you mean by "advanced documentation". The TIMES documentation is found at https://iea-etsap.org/index.php/documentation, so which one is "advanced documentation"? Finally, your reference to "page 27" prompted me to see if there is somewhere a documentation for the VEDA-TIMES Advanced DemoS, and I found it. Anyway, you now said that you found that there is a CAP2ACT 31.536 defined, and that now you understand.
3) Ok so it is ~FI_T, but you were already able to define NCAP_AFC, and so it seems the problem is solved?
4) Good, the PCG issue seems cleared.
5) I didn't know your storage was STS. The simplified equation holds for all other types of storage, and as you didn't give any other information, I assumed your storage is a normal timeslice storage. Look at the documentation, section 6.3.36 Equation: EQ_STGTSS/IPS, and you can see the difference in the formulation when using STS. Then you also have a positive/negative flow from/to the seasonal storage variable, which gives the seasonal storage capability.
Note also that ACT_EFF cannot be used for storage, you would need to use STG_EFF. I can see ACT_EFF defined for storage in your model (although with just a value of 1).
03-06-2019, 10:34 PM (This post was last modified: 03-06-2019, 11:15 PM by Antti-L.)
Small follow-up: The model you attached initially solved in 3695 seconds on my computer, which is a rather long time to wait. For curiosity, I tested if I can reduce the solution time by improving the numerical stability of the model. After only a few small adjustments, the solution time was reduced to 192 seconds. The time savings were thus about 95%. So, I think that may already demonstrate that your original model might well be characterized as badly scaled (there were indeed some very high / very low coefficients and some very high marginal prices).
In case it is of interest, the adjustments I made were the following:
• I removed dummy import flows from the model (had to add some supply of DEMHYGNINDcap & DEMHYGNINDmer in 2017)
• I disabled the dummy import processes (IMPNRGZ, IMPMATZ, IMPDEMZ) altogether
• I defined OILRES, OILCOM, GASRES and GASCOM at the ANNUAL level (DAYNITE was a bad choice, because the fuel techs were ANNUAL)
• I scaled your car-kilometres to billion vkm, to get a reasonable efficiency of 1.094 vkm/MJ for H2TRACAR (instead of ACT_EFF=1094238126)
• I set all ACT_COST that were defined between 0 and 1e−3 to 1e−3
• I set all NCAP_COST and NCAP_FOM that were defined below 1e−3 to zero
• I set all NCAP_AF(UP) that were defined below 1e−3 to zero.
(03-06-2019, 10:34 PM)Antti-L Wrote: Small follow-up: The model you attached initially solved in 3695 seconds on my computer, which is a rather long time to wait. For curiosity, I tested if I can reduce the solution time by improving the numerical stability of the model. After only a few small adjustments, the solution time was reduced to 192 seconds. The time savings were thus about 95%. So, I think that may already demonstrate that your original model might well be characterized as badly scaled (there were indeed some very high / very low coefficients and some very high marginal prices).
In case it is of interest, the adjustments I made were the following:
• I removed dummy import flows from the model (had to add some supply of DEMHYGNINDcap & DEMHYGNINDmer in 2017)
• I disabled the dummy import processes (IMPNRGZ, IMPMATZ, IMPDEMZ) altogether
• I defined OILRES, OILCOM, GASRES and GASCOM at the ANNUAL level (DAYNITE was a bad choice, because the fuel techs were ANNUAL)
• I scaled your car-kilometres to billion vkm, to get a reasonable efficiency of 1.094 vkm/MJ for H2TRACAR (instead of ACT_EFF=1094238126)
• I set all ACT_COST that were defined between 0 and 1e−3 to 1e−3
• I set all NCAP_COST and NCAP_FOM that were defined below 1e−3 to zero
• I set all NCAP_AF(UP) that were defined below 1e−3 to zero.
Thank you very much Antti for pointing out this.
In fact, I wanted to ask you about this long time for solving. From your last reply, I suspected that my model was badly scaled. The problem was that my model comprises of mainly three areas: electricity sector, hydrogen for mobility and hydrogen for industrial feedstock. Since electricity sector was all in PJ and MillionEuro, I set all other sectors also in PJ and MEuro to avoid later confusions and probable inconsistency in currency units. This is why many of my input values and output values were too small and caused problems. Then I kept my values in hydrogen sector in GJ units and adjusted the cost accordingly. This has improved the solving time considerably. But I didn't know that the solving time improved because of this . But now you have pointed it out.
I have one question related to time taken for synchronising
1) In my model, there is a scenario file called IMP-Price. When synchronising this file, it takes very long time, around 3-4 hours. Any idea what could be the problem?
I have a follow up question on storage,
1) As you told in the earlier reply, there could be simultaneous inflow and outflow without investing in storage capacity. Did you see any capacity after improving the scale of my model? In my model, still there is no capacity investment for HYGNSTG_new for years before 2045. If this is not happening despite of improving the scaling of model, it means that I am not able to have an idea about of the storage capacity required. Do you have some suggestions to solve this problem?
I have a couple of questions related to electrolyser modelling. I will post it in the other thread.
1) Long import times of VEDA templates into VEDA database is a VEDA related issue, it is not related to TIMES. So, please ask about it on the VEDA Forum. I think only the VEDA developers would be able to answer it.
2) No, I am not seeing any activity or capacity of HYGNSTG_new before 2045. That means that this storage technology is not needed (it is not cost-effective to invest into it) before 2045. It is not clear to me why you say that you are not able to have an idea about of the storage capacity required? Do you think that the model should nonetheless invest into the relatively expensive storage already before 2045, although the solver says it is not worth it?
(06-06-2019, 11:22 PM)Antti-L Wrote: 1) Long import times of VEDA templates into VEDA database is a VEDA related issue, it is not related to TIMES. So, please ask about it on the VEDA Forum. I think only the VEDA developers would be able to answer it.
2) No, I am not seeing any activity or capacity of HYGNSTG_new before 2045. That means that this storage technology is not needed (it is not cost-effective to invest into it) before 2045. It is not clear to me why you say that you are not able to have an idea about of the storage capacity required? Do you think that the model should nonetheless invest into the relatively expensive storage already before 2045, although the solver says it is not worth it?
1) Ok. I will ask in the VEDA forum.
2) I understand the logic. But in my case I am trying to represent a hydrogen refuelling station where as per the layout I have represented the hydrogen flows from electrolyser - compressor - storage and finally to the vehicles. So I desire to get a capacity for the storage so that there is an investment cost involved. In reality also, the hydrogen flows through the storage. So when there is no capacity in storage involved, I don't get any investment cost for the storage. However, for an Hydrogen refuelling station there will be a storage. I think what I could do is to model the storage capacity to represent the outflow (by defining NCAP_AFC) and input the cost as cost per year. Do you have any other suggestion?
Yes, you could bound the outflow of the storage in each timeslice to be at most the storage level at the beginning of that timeslice. In that way you cannot have any output flow without storage activity (and corresponding capacity).
(07-06-2019, 03:11 PM)Antti-L Wrote: Yes, you could bound the outflow of the storage in each timeslice to be at most the storage level at the beginning of that timeslice. In that way you cannot have any output flow without storage activity (and corresponding capacity).
Sorry I did not completely get what you have told. The outflow of the storage in each timeslice can be restricted to be within the storage level at the beginning of every time slice. This will ensure that there is storage activity and capacity. Is this right? But how do I do it? By inputting FLO_SHAR to be what value? What does 3 and 1 signifies in your example? I referred to the documentation II to understand the example provided by you. Whether 3 is the interpolation rule? What 1 signifies? Is that 1 an absolute value for the year 2020?
The outflow of the storage (FOUT) can be restricted to be in each timeslice at most the storage level (ACT) at the beginning of that time slice, multiplied by any user-specified constant (CONST).
So: VAR_FOUT(r,v,t,p,c,s) ≤ CONST(r,v,p) × VAR_ACT(r,v,t,p,s)
The TIMES parameter FLO_SHAR can be used for specifying that constant CONST. In my example, the constant was specified to have the value 1, and the interpolation option for it was 3. If you are not familiar with the TIMES interpolation options (specified with year=0), please consult the documentation.
That example would ensure that there is storage activity and capacity for HYGNSTG_new, whenever there is an outflow. As I understood, that was what you wanted?
However, I note that you already have the existing storage capacity for HYGN in the model: HYGNSTG, until 2040. So, it is not obvious to me why you think that this capacity is not sufficient for hydrogen refuelling, but you expect also that new storage capacity would have to be built, although the hydrogen delivery logistics seem to be able to match the demand without the need for additional storage capacity.
(07-06-2019, 04:36 PM)Antti-L Wrote: The outflow of the storage (FOUT) can be restricted to be in each timeslice at most the storage level (ACT) at the beginning of that time slice, multiplied by any user-specified constant (CONST).
So: VAR_FOUT(r,v,t,p,c,s) ≤ CONST(r,v,p) × VAR_ACT(r,v,t,p,s)
The TIMES parameter FLO_SHAR can be used for specifying that constant CONST. In my example, the constant was specified to have the value 1, and the interpolation option for it was 3. If you are not familiar with the TIMES interpolation options (specified with year=0), please consult the documentation.
That example would ensure that there is storage activity and capacity for HYGNSTG_new, whenever there is an outflow. As I understood, that was what you wanted?
However, I note that you already have the existing storage capacity for HYGN in the model: HYGNSTG, until 2040. So, it is not obvious to me why you think that this capacity is not sufficient for hydrogen refuelling, but you expect also that new storage capacity would have to be built, although the hydrogen delivery logistics seem to be able to match the demand without the need for additional storage capacity.
Thanks for the clarification Antti. Yes this is what I wanted. I will incorporate this and hope it works for me.
My existing capacity is very high in the model. In fact, this will be reduced to that of a 130 kg/day hydrogen refuelling station.
