Storage process with two different commodities flowing out
#1
Hi,

Is it possible to model a storage process with one commodity in (X) and two commodities out (x and y)?

I tried to model this as it is done with a normal process but I in the results am having only Fin and not Fout. I modeled a thermal storage tank with Hot water Comm-In that can satisfy Hot water or Space Heating (Comm-OUT)

I don't think it will work with an auxiliary commodity because none of the possible flow relations are the one I want (proportional to activity, proportional to input flow, inversely proportional to output flow). I would like that the energy In (X in) can go out in the same form of energy (X out) or in another form (Y out) or both but keeping the balance so:

VAR_FIn(X) = VAR_FOut(X) + VAR_FOut(Y) (taking into account efficiency). Is it possible? 

Thanks.
Reply
#2
Yes it is possible to have two outputs and single input in a storage. You must define both outputs and the input in the PCG (primary group). If they are all NRG, that would be easy: define PCG=NRG.  If one of the two outputs is also the input, it should also work well, but thus far I have never modelled such myself.

I find it strange if you have in the results only Var_Fin (input flow) and no Var_Fout (output flow).  Why would the storage in that case consume the input commodity, apparently for nothing?
Reply
#3
Yes, that is what is happening (see image). But I have just put the commodity going IN in the Primary Commodity Group, I will fix it to see what happens.

Thanks.


Attached Files Thumbnail(s)
   
Reply
#4
Dear Antti,

Using PCG = NRG did not work, I also listed both commodities under PCG but it also did not work.

I have not managed to model energy storage with one Input and two Outputs, if someone has done it before, I would appreciate your help with it.
Reply
#5
I have tested it now, and it worked as expected.  So, PCG=NRG worked well in my test.  If you claim otherwise, it would be nice if you could then also provide some evidence for the problem?  

The input files (*.DD, *.RUN) for a model demonstrating the problem, and the name of the storage technology in question, would be quite sufficient.
Reply
#6
Nice! Please find attached the files. Is it possible that you share your test with me?

Thanks for the help.


Attached Files
.zip   STG.zip (Size: 98.19 KB / Downloads: 4)
Reply
#7
Thanks. I ran the model, but I am not quite seeing what the problem is supposed to be.  Huh
I assume the technology in question should be RHUNSTGH02?

Can you explain what seems to be the problem that prompted you to make the statement "PCG = NRG did not work"? As far as I can see, all the model equations related to this storage seem correct. But yes, I do see that the storage RHUNSTGH02 is not being used for anything else but small charging of it to compensate the losses you have defined (you have forced the aggregated annual storage level to be 60, and so the losses have to be compensated by some charging). But otherwise this storage part of the model seems to be working as expected, minimizing the overall costs in a rational way.

So, maybe your problem is simply that the storage is not being used, due to not being competitive? I can see that the prices of the two outputs are nearly flat in each season, and so there does not seem to be sufficient incentive for utilizing the storage. But if you still think that it "does not work", maybe you could point out the equation(s) which you consider incorrect? You can obtain the full listing of model equations by setting LIMROW=99999 in the Control Panel.
Reply
#8
Dear Antti,

Yes, the model does not choose storage and other techs that are not competitive. Then, to check that a technology is working properly, I force the activity (ACT_BND) of the process.

In these results, the relation Var_Act (T1)+Var_FIn(T1)–Var_FOut(T1)= Var_Act(T2)  does not hold. Per instance, In the first period it is used (2020), in the first season S1Q1-S1Q12 there is a VAR_ACT = 0.43732, the same in each TS of all S1. But, it is not charged in the whole season and has you said, that VAR_FIn is only accounting for losses, so, summing up all VAR_FIn does not gives VAR_ACT plus losses. The summary of all VAR_FIn = 0.00024

As I understand, to have a charge (VAR_ACT) the process has to be charged up to that level inside the same season (DAYNITE Level). It seems like the charge was coming from nowhere, that is why I say "Using PCG = NRG did not work, I also listed both commodities under PCG but it also did not work"

I did not mean TIMES is not working, I meant it did not work to solve what I was seeing as an inconsistent result. I thought I was making an error somewhere else. but if it is ok that the relation does not hold in this case and I can not check storage techs in this way, then I would try other ways of triggering this storage process.

Thanks a lot for your help.
Reply
#9
Ok, lets go through your conclusions, one by one:

Diana> In these results, the relation Var_Act (T1)+Var_FIn(T1)–Var_FOut(T1)= Var_Act(T2)  does not hold.

AL> Yes, of course it doesn't hold exactly, because you have defined storage losses as well (and a storage efficiency, which also affects the reported output flows). But if you take into account the storage losses and efficiency, it holds exactly. You already asked earlier how the storage losses are calculated, and I think I gave a rather comprehensive answer to you? See again Part II, pages 254–255, to see how the loss term is added to this equation.

I also verified from the results of your model that the relation holds, when you take into account the storage losses (and the storage efficiency).

Diana> Per instance, In the first period it is used (2020), in the first season S1Q1-S1Q12 there is a VAR_ACT = 0.43732, the same in each TS of all S1.

AL> No, the VAR_ACT are definitely NOT exactly the same in each TS of all S1. For example, for timeslices S1Q1‒S1Q2 we have the following results:
 VAR_ACT(S1Q1) = 0.437319519
 VAR_ACT(S1Q2) = 0.437311737
 VAR_Fin(S1Q1) = 0.000012238
 VAR_Fout(S1Q1) = 0.000000036

And the loss can be calculated as 0.000019969.  So, we have the relation
  VAR_ACT(S1Q2) = VAR_ACT(S1Q1) + VAR_Fin(S1Q1) ‒ VAR_Fout(S1Q1) / 0.7 ‒ LOSS(S1Q2)
   0.437311737 = 0.437319519 + 0.000012238 ‒ 0.000000036 / 0.7 ‒ 0.000019969

The relation holds well.  I think everything works exactly as one may expect. Would you not agree?

Diana> Summing up all VAR_FIn does not gives VAR_ACT plus losses.
AL> Of course not, as it shouldn't give that amount. Neither in reality nor in the model. However, summing up all VAR_Fin, and subtracting the sum of all VAR_Fout divided by the storage efficiency, gives exactly the sum of the storage losses. For example, the sum of the losses in the season S1 is 0.000240, and the sum of those net inputs flows is exactly the same, 0.000240.

Diana> As I understand, to have a charge (VAR_ACT) the process has to be charged up to that level inside the same season (DAYNITE Level).
AL> No, certainly not. VAR_ACT represents the aggregate storage level.  If there is no charging/discharging and no losses, the storage level can of course stay at any constant value without any charging up!  And if there are small losses (like in your case), only the losses need to be compensated for by some charging up. That should be very obvious, and so it seems you do have a fundamental misunderstanding here.
Reply
#10
Dear Antti,
 
"I think everything works exactly as one may expect. Would you not agree?" :

It was not acting as I was expecting because I was expecting the storage process to charge that VAR_ACT, so, I was expecting VAR_Fin inside one season to reach that level. I did not know ACT_BND acts like an exogenous charge ("any constant value without any charging up").

I said this relation does not hold because it was consistent between two consecutive TS (as you showed and as I calculated, including storage losses and efficiency calculations which were clearly explained) BUT for me, it was not holding inside the season because I was expecting a Fin to generate that VAR_ACT inside the season).

Summing up all VAR_FIn does not gives VAR_ACT (please ignore the plus losses). Yes, I did the same calculation than you and it only gave me the losses as I told you ("that VAR_FIn is only accounting for losses") and what I was expecting is that the VAR_Fin will generate either in one TS or in several TS the level of energy showed, maintaining the relation cited above and accounting for losses and efficiencies.
_________


Yes, I had a misunderstanding, I thought that if I force an ACT_BND for a storage process, it was not going to be like an exogenous charge, I thought defining an activity bound will force a Fin until reaching that storage level. It did not occur to me that it will be like an exogenous charge because you have another attribute for that (which I have never used).

I am sorry if I cannot fully understand TIMES modeling tool, I am new with TIMES and that is why I am trying to understand how the calculations are done, so I can understand what my inputs and my results mean, and I can analyze my results properly.

The way forcing ACT_BND acts in STG processes is clear now. Thanks a lot for your help.
Reply
#11
Dear Diana,

I am sorry that despite my attempts I still have not been able to explain it well to you. However, for the sake of other Forum readers, I think I need to comment also on the new conclusion you made:

Diana> Yes, I had a misunderstanding, I thought that if I force an ACT_BND for a storage process, it was not going to be like an exogenous charge, I thought defining an activity bound will force a Fin until reaching that storage level. It did not occur to me that it will be like an exogenous charge because you have another attribute for that (which I have never used).

AL> That is not at all true:  The ACT_BND(LO) you defined was NOT at all working like an exogenous charge.  Could you please take a look at the documentation again, Part II, page 254.  There you can see how an exogenous charge (STG_CHRG) would enter the storage equation:

   Var_Act (T1) + Var_FIn(T1) – Var_FOut(T1) + STG_CHRG(T1) – LOSS(T1,T2) = Var_Act(T2)

As you can see, an exogenous charge would be an additional term in the balance, and treated similarly as the endogenous charge Var_FIn(T1).  Any such exogenous charge would subsequently have to be discharged (or consumed for the losses) at some later timeslice.  However, the ACT_BND(LO) you defined does not allow for any later discharging: the forced amount stored has to be retained in the storage, as you should immediately see from the equation, bearing in mind that the DAYNITE timeslices under each season form a cycle. So, if you force some storage level with ACT_BND(LO), it does not at all increase the amount of energy that can be discharged from the storage.

The only direct impacts of an ACT_BND(LO), forcing increased storage levels, are 1) it requires sufficient capacity to accommodate those increased storage levels, 2) it increases the costs on activity (if defined), and 3) it causes additional storage losses, as explained in the documentation.  Consequently, ACT_BND(LO) would, in fact, tend to decrease the amount that can be discharged, assuming the amounts charged remain unchanged. That is so because the storage losses would then become higher (if the forced storage levels are higher than what they would otherwise be).
Reply
#12
Dear Antti,

Thanks for the clarification.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)