Veda2.0 Released!


UC Scenarios and Storage
#1

In Swiss TIMES, a number of UC have been declared for calibration purpose (e.g. ELC import level).  All UCs are kept in a scenario file that must go with BASE case run.

Now we wanted to have a (stringent) variant scenario (i.e. limiting level of ELC import), for which I have created the same UC like one in the BASE, but different data.  This UC is kept in another scenario file. 

However, when I was running a case with this variant scenario, it doesn’t overwrite the UC in the BASE.  So there is not change in result.  I could see the variant UC in result table (User_Con).  So model is using the variant UC, but NOT overwriting the previous one!

How can I make it to overwriting?  In MARKAL, a later declaration scenario always overwrite previous declaration .   Is anything similar in TIMES?  How can I go about it?

Also, STGTSS technologies are doing unusual things, like, technology ACT is more than CAP2ACT values!  Also Var_Act is balancing with neither with input nor output!  Please see an example from two scnearios results, uploads/24/TIMES_Q.doc

OCUME~1LAVANY~1LOCALS~1Tempmso101clip_001.emz">

I noticed this imbalance only after migrating to v.4.3.3



Attached Files
.doc   TIMES_Q.doc (Size: 25 KB / Downloads: 9)
Reply
#2
There is no difference in the overwriting logic between MARKAL/TIMES; this is a GAMS feature. I see only the following logical possibilities:
  • The UCs are not identical (for example, one if FX and the other is LO)
  • Different years have been specified in the two cases (not controled with the "-0" declaration) and the timeseries are being merged
  • The scenario file with BASE constraints is being read after the new one (depends upon the order on the Solve form)

For storage, send a screen shot with one particular technology behaving and misbehaving. Has your model changed since you sent it to me on May 18?

Reply
#3
As Amit mentioned, there is no scenario management at all in TIMES, and I don't think MARKAL has such any better. All scenario management is done by the user shell, VEDA-FE or ANSWER-TIMES. I am sure Amit can give you a complete answer about scenario overriding in VEDA-FE.

Concerning the storage issue, it is difficult to comment your results without seeing the technology characterization (topology, primary group, TSLVL, process attributes, bounds, possible UCs involved etc).

However, remember that the activity of a storage process is the storage level. Therefore, there does not have to be any "balance" between the inputs/outputs and the activity. For example, the activity can be zero, if nothing is stored, but the storage may still have positive inputs and outputs, in the same timeslice. Normally that would make not sense, but this seems to happen in your model. Maybe you have some bounds on the storage output?

Also remember that the activity of a DAYNITE storage can be larger than the capacity (assuming PRC_CAPACT=1), because the activity represents the total storage level in the timeslice, not the storage level of a single day. On the other hand, the capacity is assumed to represent the storage capacity in a single day. For more details, see page 187-191 of the documentation, Part II.

Furthermore, if you have modeled the process using NCAP_AFC, the capacity is not related to the storage level, but the produced output, just like in power plants.
Reply
#4

Amit, Antti, thanks for this diagnostic

the scenario overwriting issues has been solved and problem was with the interpolation (~0) that was not declared in the varinat scenario! LOL. 

On STG, I can understand, STG tech can be used even if not energy is stored, e.g. dumping excess ELC from a base load plant!  But, still unclear, how can flow rate be more than its CAP2ACT level?  Please see attached file for three runs with topology infouploads/24/STEM_PumpSTG.doc

 But I don't see a similary issues with other tech.



Attached Files
.doc   STEM_PumpSTG.doc (Size: 110.5 KB / Downloads: 14)
Reply
#5
Ok, you are now providing quite a lot more information, which is fine!

In the doc you attached, you are apparently showing the activities, inputs an outputs summed over the 207 timeslices. On the other hand the the capacity does not have any timeslice index, and so the capacity figure shown in your screen capture represents the daily storage capacity. Of course the total activity in the whole year can be larger than the daily storage capacity. For example, if the storage would be full for a 100 days' time in a year (and in only one timeslice per day), the total activity could thus be 100*PRC_CAPACT*NCAP_AF times the capacity. This is much higher than the daily capacity.

[Edit:] Actually the explanation above is still very inaccurate, because it assumes that the storage would be full in only one of the daily timeslices in each season, which is typical for large models. If, for example, you would have 24 daily timeslices (for each hour), and only one season, and the storage would be full for 12 hours each day, the total activity corresponding to what was shown in your screen capture would be 365*12*PRC_CAPACT*NCAP_AF times the daily capacity. Consequently, the sum of the activity over timeslices will of course increase with the number of timeslices you have for each day.
Reply
#6

Antti, thanks for clarifying VAR_ACT for STG technologies.  But still I don't understand the logic in VAR_F** with respect to CAP. 

If my understanding is correct, CAP is on annual basis, and so the CAP2ACT (e.g. 31.536 PJ/ annum/GW).  i.e. a technology with CAP2ACT of 31.536 should NOT produce an output of more than 31.536.  Is it correct?  this is what I understand, at least so far.

If so, in our case, for instant, capacity of PUM00 in 2015 is 1.08 GW. So, its max annual output shouldn’t exceed 34.06 PJ (i.e. 1.08*31.536).  But the output (VAR_FOut) shows a figure of 48.31 PJ, despite its AF of 20%.  Similarly, for PUM05, capacity in 2015 is almost zero, but the VAR_FOut is 80.97 PJ.  Can it be interpreted as there is no power plant, but still it is operated!

Reply
#7
No, as I tried to explain to you, the Capacity of a DAYNITE storage represents the amount that can be stored in the storage, on a daily basis. As a DAYNITE storage can be charged and discharged each and every day, the total output in the whole year could be thus be at most 365*CAP*PRC_CAPACT*NCAP_AF, if the storage is charged once per day. And if it is charged and discharged 5 times per day, the total output could be still even 5 times larger! This is all explained in the documentation.

For normal processes the capacity is interpreted like you said: (e.g. 31.536 PJ/ annum/GW).  But you should always remember that the capacity of a storage represents the maximum amount that can be stored, not the maximum output per annum.  Therefore, using the 31.536 as the PRC_CAPACT for a storage might actually not be such a good idea.

[Edit:] If you would like that the storage behaves like a pumped hydro power plant, why are you not using the commodity-specific availability factors?  As described in the documentation, you could define NCAP_AFC(ELC,DAYNITE)=1 (peak availability factor) and NCAP_AFC(ELC,ANNUAL)=0.2 (annual load factor). With these parameters, the technology capacity would then represent the power output capacity.
Reply
#8

Antti, thanks agian.  I could well understand the whole methdology, but the current model output does not reflect what you have described as the total output in the whole year could be thus be at most 365*CAP*PRC_CAPACT*NCAP_AF  But in our case the actual output (VAR_FOut) is more than the 365*CAP*PRC_CAPACT*NCAP_AF

Also Nuclear technology is declared as Annual technology, but its outputs in a given year is NOT uniform across all timeslces.  Please see the files uploads/24/STEM_NUC.doc .  Hourly output in Spring week days are uniform, but in the spring Saturdays/Sundays, it has changed.   (result from old version of VFE did have this issues).



Attached Files
.doc   STEM_NUC.doc (Size: 113 KB / Downloads: 6)
Reply
#9
It seems that you still don't understand what I explained. The capacity of a storage process does not limit the output flow at all, because the input flow does not have to be stored.  In my first message to this topic I already explained that the activity can be zero (and thus also the capacity), but the input and output flows can nonetheless be positive. But you still don't understand it?

The storage capacity only limits the storage operation: it limits the amount that can be kept in the storage "stock".  How can it be so difficult to understand this very simple and natural storage operation?

Perhaps you should devote some more time to reading the documentation.
Reply
#10

Clearly I understood storage concept, but I’m struggling to understand why model choose a technology, capacity of which is zero?

Normally, in any technology, if capacity is zero, then its activity must be zero.  Why an exception to STG tech?  Looks like, STG can simply ‘transport’ energy carrier (in/out) without paying for activity cost?  It doesn’t sound logic to my sense.  It is not happening in other technology, but only in storage technology.  Sorry to bother you againConfused

Reply
#11

For STG, must input and output energy carrier be same?

Reply
#12
Kannan Wrote:Normally, in any technology, if capacity is zero, then its activity must be zero.
Yes exactly, and this is the case also for the EHYDPUM00 technology in your model.
Kannan Wrote:Why an exception to STG tech?
STG is not an exception to this default rule, unless you explicitly introduce an exception. Your results clearly show that the activity is positive only when the necessary capacity exists.
Kannan Wrote:Looks like, STG can simply ‘transport’ energy carrier (in/out) without paying for activity cost?  It doesn’t sound logic to my sense.
Yes, here you are right. But it is logical, because the storage is not utilized at all for such a by-passing flow. So why should you have to pay for the flow, if you are not getting any storage services? Normally the possibility of such a by-pass flow doesn't affect the solution in any way, but in your case it apparently does. I suspect that you have some lower limit on the pumped hydro output flows, or on the total hydropower output, which leads to the nonsensical by-pass flows through the STG processes. The output flows appear to be quite artificially increased in your model, despite the large efficiency losses.

You could prevent those flows by introducing another user-constraint, but I think you should investigate why your model behaves in such a strange way. You should identify the constraints that cause those artificial pumped hydro by-pass flows, and see whether the constraints fully make sense.

And, as I recommended earlier, you could model the pumped hydro processes as pumped hydro power plants instead of pure storage devices. That would also eliminate the problem.

Finally, if this is considered a real problem, you could also make a proposal for changing the TIMES code in such a way that the output from a storage would be limited to the discharge of storage activity.

Reply
#13
Kannan Wrote:For STG, must input and output energy carrier be same?

No, for timeslice storage (TSS) they don't have to be the same. But if they are different, you should define the Primary Group of the process to be a commodity group consisting of both the input and output. If they are both NRG, and there are no auxiliary inputs and outputs, you can just use NRG as the PG (EDIT: Using NRG as the PG will work only with TIMES v3.1.3 and above; with earlier versions you therefore must define a user-defined commodity group containing the input and output and set the group as the PG).

For inter-period storage (IPS), the input and output must be the same commodity C = PG.

Note that an NST process operating at the ANNUAL level is not a storage (STG) process but a normal process with a night storage capability, and so the advice above does not apply to those processes.
Reply
#14

Antti

In our model, I have a storage technology, defined as ELE,STGIPS.  I noticed in the results that it shows commodity output and activity, but I don’t see any commodity input.  Looks very strange!  Am I missed something?

Yet another question is, in calibration, how stored-energy can be modelled for storage technologies?  e.g. in pumped storage, 65% charged. can it be an activity bound?

[QUOTE=Antti-L] , you could model the pumped hydro processes as pumped hydro power plants instead of pure storage devices. That would also eliminate the problem.

Is anything like pumped hydro process that I can define and model?

Thanks

Reply
#15
Well, I cannot be sure what is going on the basis of such a brief description, but can only give some general comments.

1. Is the technology in question an electricity (or hydro) storage? If so, note that STGIPS is an inter-period storage.  Inter-period storage technologies can only operate on the ANNUAL level, but you could combine them with timeslice storage for achieving both inter-period and timeslice storage capability.
2. For inter-period storage, it is important that you define the initial storage condition in an appropriate way. For a storage technology that is available from the beginning of the model horizon, the initial storage level is set equal to STG_CHRG at the BOH.  However, if the technology is defined to become available later, the initial storage level is always assumed zero.

Thus, I suspect that in your case the storage technology becomes available only after the beginning of the model horizon, and you have forgotten to set a bound for the initial storage level. Thus, I don't understand how you could have outputs without inputs, unless you have defined some initial storage with STG_CHRG, which can then be discharged.

There are no special pumped hydro processes in TIMES, but you can use NCAP_AFC for defining the process availabilities. When doing so, the process capacity represents the output capacity, just like in power plants, whereas normally for storage processes the capacity represents the maximum nominal amount that can be stored. In both cases you can use activity bounds for limiting the amount of energy stored.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)