Veda2.0 Released!


TSLV
#1

I have been looking at the TSLV declaration of commodities which are not an ELC declared commodituy but are in fact ELC (like IOIELC in the EU model, because VEDA was giving en error (inconsistencies between BY template and Techrep). It seems that it is important to have some consistency between the commodity TSLV declaration and the process producing the commodity when a specific COM_FR is given for the demand (here IOI). If both are annual or at daynite level the total production is equal but the tsl allocation of INDELC (the source for IOIELC) is not the same. When the commodity is SEASON or DAYNITE and the process annual , the quantity produced is higher. Therefore it seems important to take this account if I am correct. When there is no specific COM_FR this problem does not seem to arise.

Reply
#2
Yes, you are right: It is important that the user defines the TSLVL levels appropriately. If COM_FR is defined for the demand (IOI), either both the demand commodity and the demand processes should be defined at the ANNUAL level, or both should be defined at the DAYNITE level (or SEASON, if the load curve is only seasonal). But the electricity input commodity (in your case IOIELC?) to the processes should always be defined at the DAYNITE level (unless you define COM_FR for that commodity as well).
I think such guidelines should be given in the Getting Started User Guide. Are they not yet included there?
Reply
#3
In the Getting Started the commodity and process TSLV is explained but we never said to define both the demand commodity and the processes with the same TSLV. I will update this in the guide.

Thanks
Mauri
Reply
#4
I have a question on how the COM_FR of a DM is transmitted to the different technologies delivering to the demand directly and indirectly: in the EU model IOI demand has a COM_FR and the process delivering the demand is annual. It consumes IOIELE which is TSLV at day night. If the process producing the ioele is TSLV at DAYNITE, no problem; if it is annual its activity in the EQG_COMBAL equation is allocated between TS as the general allocation and not as the IOI allocation while the demand side in the same equation is allocated as the IO COM_FR. I find this rather surprising.
Reply
#5
I think it should not be surprising at all.

If your IOIELE is at the DAYNITE level, you must, of course, have some production processes that can satisfy the demand of IOIELE according to the load curve. Therefore, you must have at least some process producing IOIELE at the DAYNITE level. Any processes that produce IOIELE at the ANNUAL level would be so-called base-load processes, which produce evenly throughout the year. Such a base-load production is, of course, allocated according to the general YRFR allocation, and not according to the COM_FR allocation of IOI. If the base-load production were allocated according to the COM_FR of IOI, the process would be able follow the load over its available capacity, which would make no sense for electricity generation technologies.

However, if the processes producing IOIELC are, in fact, not generating technologies but are just some dummy delivery technologies, you could define for IOIELC the same COM_FR as for IOI, and then you could define both the IOIELC commodity and the processes producing it at the ANNUAL level. In that way the load curve would become effective at the inputs of the processes producing IOIELC.
Reply
#6
Dear above,

Do I understand above thread correct, if I interpret it as the following:

* If I define my Demand commodities with a COM_FR (e.g. space heating)

Do I then need to define the following:
- Demand commodities CTSLvl = DAYNITE (!?)
- Demand process, Tslvl=DAYNITE (!?)

What about the sector-fuels? Do all of them need to be DAYNITE, or is it enough that I define the sector-fuels that will vary (ELC, SOL, District heating) ?


Thank you in advance
/Anna
Reply
#7
If you define your Demand commodities with a COM_FR (e.g. space heating), you neither need to define the demand commodities nor the demand processes at the DAYNITE level.

See the TIMES Starter model for example:  In the Starter model all the demands have a load curve, but the demands are ANNUAL and the demand processes are ANNUAL.  In that way the competing demand technologies serving the same demand will all see the same load curve, which is then reflected in the load profile of the input energy flows (unless the process is modelled as a storage). Subsequently, those input energy commodities that should be tracked at a finer level are defined at the DAYNITE or SEASON level in the model (e.g. electricity, district heat in the Starter model). Solar energy e.g. for residential is tracked on the ANNUAL level in the Starter model, because there is no need for finer tracking upstream. The profile of solar radiation can be taken into account in the demand technologies themselves, by setting a highest share of solar in the summer daytime hours and a lowest share in the winter (assuming it has a supporting energy input, e.g. electricity).

However, sure you could also define the demands and the demand processes at the DAYNITE level, but then you will have a bigger model with probably longer solution times. And then you will have to separately make sure that each individual demand process has an appropriate load profile. So, it is all up to the modeller, but the Starter model presents one good practice.
Reply
#8
Thank you very much Antti for sorting it out!
And for explaining a bit further how it function.
Very useful!!!

Anna
Reply
#9
Hi Antti,

I have some following up questions (after staring to implement above in my model). If I understand you correct, I should avoid defining process and commodities as DAYNITE (or SEASON), thus just leave this blank, correct!?
But are there some that is critical to define as DAYNITE?
- MINing processes of wind and solar (Or, am I better off by using shares on the process)
- IMPort of electricity and district heating (Or, am I better off by using shares on the process)
- Electricity process (Or, am I better off by using shares on the process)
- ELC commodities

Thank you in advance
Anna
Reply
#10
@AnnA:  I have not recommended avoiding to define processes and commodities as DAYNITE (or SEASON).  But this thread was mainly about the demand side, and for demands it is fine, when you want to impose the same demand load profile to all the competing technologies producing the same demand, because it also reduces model size, and makes the demand load profiles much easier to impose.

For all dispatchable electricity and heat generation, electricity trade and transmission processes, sure it is best to have the processes and commodities at the DAYNITE level.

However, I am not defining my solar or wind extraction process on the DAYNITE level, because I can define the "load profile" of solar for my ANNUAL level ELCSOL commodity instead, and as far as I can see, it works very well for all of my PV technologies.  For wind power I am defining the wind profile by using availability factors for the wind power technologies, which also works well, and there is no need for the ELCWIN commodity or wind "mining" processes to be DAYNITE. But I think such design choices are completely up to the modeller.
Reply
#11
Ok, many thanks.

So I would guess the following should work:

Processes:
- All power plants defined DAYNITE (also CHP)
- All sector-fuel ELC processes defined as DAYNITE.
(-Demand processes are no defined by DAYNITE)
- IMPELCxxx and EXPELCxxx, defined as DAYNITE
- (import or mining of other sources, like solar, are not defined as DAYNITE).

Commodities
- All ELC commodities defined as DAYNITE
(- Demand commodities are not defined as DAYNITE)

Is there a thread discussing pros/cons with defining ELCWIN as DAYNITE?
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)