Issues varying COM_FR over years

[SDockweiler]

Dear all

Not used to working with time slices in my model so here goes: 
I am trying to model changes in the commodity fraction over time, because we want to mimic the assumption that more and more production of energy services can be done using flexible electric boilers. In the documentation I read that COM_FR is defined for region, timeslice, commodity and datayear (COM_FR(r, datayear, c, s)). 

So, i defined COM_FR for 11 TimeSlices, one being the "rest"-category. These needs to change over time, so more of the COM_FR gets into the time slices were electricity prices are distributed according to hours. See the attached scenario file below. 



When running the model I get an error, but it just says division by zero. 
LST file were error is located:

Code:

**** Exec Error at line 1862509: division by zero (0)
----1862509 Assignment COM_FR        0.016    11.438 SECS    176 MB  9516

The model works fine when COM_FR is defined for one year only. 
Note that I have not defined YRFR. I also tryed explicitly interpolating between the two years, but same result. 

Have someone already done something similar and can please assist in where I go wrong with the above appraoch? 

Cheers,
Steffen

[Antti-L]

Hmm... this looks like a serious exception handling error (division by zero), which should be fixed.
It would thus be nice to have a reproducible case, is that possible for you to provide (the *.DD and *.RUN files for the case)?  If not, could you please at least attach here the full listing file, *.LST?

I just tried to reproduce the error myself in a test model, but thus far had no success.

[Antti-L]

Sorry, I overlooked this comment:
> Note that I have not defined YRFR.

What do you mean by this? 
G_YRFR is basically a mandatory parameter, can you explain why you would not be defining it?

With that noted, yes, I was now able to reproduce the error if I leave G_YRFR undefined. But when so, I think that the termination into the error is not actually so serious, because the whole idea of having no G_YRFR but defining COM_FR does not make sense to me. But of course, an error message in the QA log would be justified. Could you explain, how it in your view would make sense?

[SDockweiler]

Sorry, I overlooked this comment:
> Note that I have not defined YRFR.

What do you mean by this? 
G_YRFR is basically a mandatory parameter, can you explain why you would not be defining it?

With that noted, yes, I was now able to reproduce the error if I leave G_YRFR undefined. But when so, I think that the termination into the error is not actually so serious, because the whole idea of having no G_YRFR but defining COM_FR does not make sense to me. But of course, an error message in the QA log would be justified.  Could you explain, how it in your view would make sense?

Thanks for your answer, Antti. 

Regarding G_YRFR, it is probably due to my limited understanding of time slices: I started out having YRFR defined, but as it wasnt working I started removed it. It seemed that before these issues it didnt make any difference having both G_YRFR and COM_FR defined, as I defined them to be the same values. Now that I want the COM_FR to differ from the G_YRFR i thought maybe the G_YRFR was the issue. My thinking was that the time slices becomes a bit removed from a "real" year of 8760 hours when i actually create 10 slices that resembles the electricity price variation over the year, and one "rest" time slice that is the average electricity price instead, and then gradually increase the COM_FR for the amount of demand that can be met with price variation. 

I will try with defining G_YRFR again.

[SDockweiler]

Oh and for completeness here is the .lst file.

[Antti-L]

Ok thanks for explaining.
In TIMES, if you have no G_YRFR defined, the model will not have any timeslices apart from ANNUAL. For timeslices with a zero time fraction no flows are assumed possible. A positive flow in a zero time would imply infinite capacity (or power level), but such cannot be modelled with TIMES.

[SDockweiler]

Thanks, much appreciated - now it works!  

But, if I can ask one follow up question: Does it matter what i put in the YRFR? I mean, I want the COM_FR to distribute the demand commodity according to the values put in this table, not the G_YRFR. 

An example, will it matter:

Table 1:


Table 2:


I guess my question is, how TIMES uses the values of G_YRFR when distributing the commodity demand using COM_FR, and thus how I can interpret capacities etc. per time slice?

Thanks again!

[Antti-L]

It can actually be quite useful to read the documentation for learning both the basics and the detailed formulations of TIMES. From Part I (general description of the TIMES paradigm), you can find the capacity-activity relationship explained in simplified terms (more details are given in Part II):
--------
5.4.3 Use of capacity
For each technology p, period t, vintage v, region r, and time-slice s, the activity of the technology may not exceed its available capacity, as specified by a user defined availability factor.

EQ_CAPACT (r,v,t,p,s) – Use of capacity :
VAR_ACT(r,v,t,p,s) ≤ or =
  AF(r,v,t,p,s) × PRC_CAPACT(r,p) × FR(r,s) × VAR_CAP(r,v,t,p)   (5-3)

Here PRC_CAPACT(r,p) is the conversion factor between units of capacity and activity (often equal to 1, except for power plants). The FR(r,s) parameter is equal to the (fractional) duration of time-slice s. The availability factor AF also serves to indicate the nature of the constraint as an inequality or an equality. In the latter case the capacity is forced to be fully utilized.
--------
Here, FR(r,s) stands for the G_YRFR(r,s) parameter. As you can see, if G_YRFR(r,s) is zero, the activity can only be zero in timeslice s, for any technology with a capacity. And you can immediately see how G_YRFR affects the relation between VAR_CAP and VAR_ACT. You can see FR(c,s) employed also in Equation (5-4) (Commodity balance), but there it is, in fact, denoting COM_FR, although defaulting to G_YRFR when COM_FR is not defined.

[SDockweiler]

Hi Antti

Thanks regarding the capacities. 

I'm still struggling with changing the COM_FR over time, however. I suspect that they might be overwritten by the G_YRFR because whatever I put in COM_FR doesn't change the results. 

This is my declaration of G_YRFR:
 

And this is two different declarations of COM_FR (separated in two different sub-annual scenario-files):
   

I've declared the relevant demand commodities as DAYNITE (i.e. the "IND*_DMD"s). Also the processes producing this demand has been set to DAYNITE. 
Prices for electricity varies per TimeSlice, and thus I expect more electrification in the scenario were more demand is allowed in the S0W0PXXX-time slices compared to the S0W0PANN (annual average electricity price assumed).  

I guess I'm declaring something wrongly, or perhaps missing some other declarations. 

Thanks in advance! 

Cheers,
Steffen

[Antti-L]

I don't understand your specifications.
G_YRFR must be defined for all timeslices at the most detailed level. Your are defining it for 10 timeslices, plus 0.5 for ANNUAL, which does not make sense to me.  The ANNUAL fraction is always 1 (the fraction of the year for the whole ANNUAL is, by definition, 1).  But anyway, your model will then have only those 10 finest level timeslices (those that have a G_YRFR defined), with a flat G_YRFR profile.

Then, you are defining COM_FR again for those 10 timeslices, such that the fractions are flat over them (all have either 0.001, 0.005, 0.03 or 0.06 as the fraction).  However, because the sum of the fractions must always be 1 over all timeslices on each level, they are normalized to make sure that the sum is 1. So, the result is that for both years (2015 and 2060) you will have a fraction of 0.1 for each timeslice. This is because your fractions are always flat over the 10 timeslices.  So, what you are doing does not really make much sense to me, sorry.

I suggest that you define G_YRFR for all timeslices on the DAYNITE level such that the sum is 1 (not for ANNUAL, because it must be 1). And similarly for COM_FR, the sum must be 1 over the DAYNITE timeslices.  For COM_FR, you could also make use of the inheritance mechanism as explained in the documentation, but the values will then be inherited by weighting (see attached picture). And they are then again normalized to make sure that the sum is 1 over all DAYNITE timeslices. But in your current specification, there is no inheritance, because you are already defining values for all of the 10 timeslices.
     

[SDockweiler]

Hi Antti

The point for me is, that I want to make sure not all demand is fully flexible, and thus can act according to the duration curve of electricity prices. Some firms and processes not being able to react or reduce/increase production lvls, missing technology to do so, etc. 

Maybe I wasn't clear in my TS declaration. I do in fact declare 11 time slices, 10 of which I want to act as normal timeslices were price varies according to the duration curve, and one time slice with no variation: 


Only difference I want is the name of the TS, and then I want to change COM_FR over the TimeSlice over time. I declare G_YRFR and COM_FR for all 11 time slices in each of the previous tables.

[Antti-L]

Sorry, in my mind interpreted the S0W0PANN to represent the ANNUAL timeslice.  But as I see now it is actually a DAYNITE timeslice, it does indeed make sense. But I hope my post contained at least some useful remarks.

I probably cannot comment any more about it without seeing the model. So, if you think something is not working as documented, please provide a reproducible case.

[SDockweiler]

Great - I will share the model with you in a PM.

[Antti-L]

Ok, I received the model files and I generated the model.
I checked the resulting COM_FR and they were fully as defined, and I also checked the demand equations, and I verified that they were formulated as expected, applying the COM_FR to the demand projections (when the demand commodity was on DAYNITE).  There were also some demands tracked on the ANNUAL level, and for them COM_FR is of course, not applied to the demand balance, but it is applied at any ANNUAL processes producing that demand (whenever that has some DAYNITE level inputs).

However, I also see that INDELC is tracked on the ANNUAL level, and so in both cases (final demand either tracked on DAYNITE or on ANNUAL level), any effects on the upstream electricity load profile by timeslice may be eliminated. The modeller is thus assuming that all the industrial consumers have implemented advanced flexibility mechanisms with load shifting and shaving, which indeed seems to be working well, featuring effective demand side management.

So, it all looks working fully according to the modellers intentions. Can you tell me why you would expect more electrification, even if the INDELC demand is modeled to be fully flexible, and so any shift in the individual final demand profiles can be smoothed and shaved out be the consumers, and therefore no effect may be seen on the load profile on the supply side or electricity prices?

[SDockweiler]

Hi Antti

Thank you very much for testing our model. 

First of, the technologies in question, Electric boilers (hot water or steam), can use both INDELC and INDELD electricity commodities as inputs. INDELC being strictly ANNUAL and INDELD being DAYNITE. The SubAnnual scenario file activates the share of INDELD being zero in the VT-base case to be 1 and INDELC to be zero. 

I found the problem though, and as you state in your latest response, it was indeed the fact that i had put DAYNITE for the demands AND for the processes (electric boilers) AND the INDELD commodity. For some reason this makes G_YRFR to overwrite the COM_FR, because when I, as You suggest, put ANNUAL at the processes (electric boilers) and the demands everything works as intended. COM_FR is passed upstream to the DAYNITE use of INDELD for the electric boiler processes. 

I found out since the DEMO 4 model works fine when declaring a development in COM_FR over time. Here the declarations of ANNUAL and DAYNITE were different than mine, and only the input commodity of electricity was DAYNITE.  

Thanks for all you help Antti!