Question regarding TIMES modeling of loadcurves
#1
Lukasz Wrote:I am writing you with a question regarding the modeling of loadcurves for commoditities, which are not Demand-Commodities and can have a flow from more than one source.
My question relates to the commodity VEHSTI (VehicleStorageIN) : I would like to place some sort of FLO_FR, UC_FLO on Timeslice level (here: weekly) to enforce an exogenously given loadcurve for that commodity.
How to implement an enforced loadcurve (distribution of Flows per TS) for commodity VEHSTI?
 • From my understanding a FLO_FR will not work since it is defined PER process and not as a sum of processes, correct?
 • How to model a load curve for a commodity (which is not a demand) and which can come from a variety of processes?
Indeed, FLO_FR can be used for defining load curves for individual process flows only, and it is rarely needed. The standard way of defining load curves in TIMES is to specify COM_FR for the commodity. This is especially convenient for demands, because the resulting load curve is imposed both for the total demand, and also for any individual processes operating at the ANNUAL level producing the demand. Therefore, all the competing technologies producing the demand will see the same demand load curve (as long as the technologies are normal processes at ANNUAL level, or NST processes where also the demand itself is ANNUAL).

If I understand correctly, you seem to want to define an exogenous load curve for the total production of an "intermediate" weekly level commodity, upstream of the demand (as you said you want it for the "sum of processes"). If so, let's assume this commodity is C1.

One easy way of forcing an exogenous load curve for the total balance of C1 would be to use the same method as for ANNUAL level demand technologies. That would only require introducing a single new "load process", operating at the ANNUAL level, consuming C1 and producing a new weekly level commodity C2 (=PCG of the process). Then you would just need to change the input of all processes that were originally consuming C1 to consume C2 instead, and define the load curve for C2 by using COM_FR. This method is illustrated in the top part of the Figure below.  Of course, FLO_FR could also be used for such a load process, instead of COM_FR for C2, but it would just create more extra equations.

Another way is to define the load curve by using user constraints. As such constraints might become quite large in non-zeros if there are many timeslices on the target level, I would rather suggest a nested constraint, as illustrated in the bottom part of the Figure below. The example defines an exogenous load curve for the ELC commodity in the DEMO model. Note that  the example works only for the production of ELC from normal processes; including IRE or storage processes would require additional consideration, or changing it to operate on VAR_COMPRD instead of VAR_FLO.

I tested the example myself with the DEMO model, and it worked perfectly well, verified to work fully as expected.


Attached Files Thumbnail(s)
   
Reply
#2
(18-07-2019, 09:20 PM)Antti-L Wrote:
Lukasz Wrote:I am writing you with a question regarding the modeling of loadcurves for commoditities, which are not Demand-Commodities and can have a flow from more than one source.
My question relates to the commodity VEHSTI (VehicleStorageIN) : I would like to place some sort of FLO_FR, UC_FLO on Timeslice level (here: weekly) to enforce an exogenously given loadcurve for that commodity.
How to implement an enforced loadcurve (distribution of Flows per TS) for commodity VEHSTI?
 • From my understanding a FLO_FR will not work since it is defined PER process and not as a sum of processes, correct?
 • How to model a load curve for a commodity (which is not a demand) and which can come from a variety of processes?

Thanks Antti, although I had some trouble with your second approach (I didn't quite get the nested contraint running), the first method worked fine.
I just had to define BOTH, the "load process" and the new commodity C2 on an annual level to make the COMFR work. For some reason with C2 on weekly level my "construct" didn't work. Also the first approach is much smaller in database size, I can only recommend it. Thanks again Antti!
Reply
#3
For the sake of avoiding any confusion to other Forum readers, I would like to emphasize that if the commodity C2 mentioned above is defined on the ANNUAL level, and is then consumed by a number for WEEKLY level processes P1, P2,…,Pn, there is no way of ensuring that the total load from the inputs of C2 will follow the exogenous load curve. This can be easily seen by looking at the commodity balance equation in this case, which would look like following:

 VAR_ACT(LoadP,C2,ANNUAL)  ≥/=
 VAR_FLO(P1,C2,WS1) + VAR_FLO(P1,C2,WS2) + … + VAR_FLO(P1,C2,WSn) +
 VAR_FLO(P2,C2,WS1) + VAR_FLO(P2,C2,WS2) + … + VAR_FLO(P2,C2,WSn) + … +
 VAR_FLO(Pn,C2,WS1) + VAR_FLO(Pn,C2,WS2) + … + VAR_FLO(Pn,C2,WSn)

Here, the process LoadP is the ANNUAL level load process mentioned above, and the timeslices WS1, WS2,…WSn are the WEEKLY level timeslices.  As you can see, the equation just ensures an ANNUAL level balance between the production and consumption of C2, and nothing else. As also shown in the equation, the input flows to P1, P2, …, Pn will all still be on the WEEKLY level (because those processes are defined on the WEEKLY level), and therefore the load curve defined for C2 does not have any impact on the process transformation of these processes either. Thus, I would like to discourage any users from trying to define a load curve for C2 in that way.

Instead, defining C2 on the WEEKLY level as I suggested, works fully as expected and as requested by Lukasz, enforcing the exogenous load curve on both C1 and C2. I have also fully verified that by testing.

So, Lukasz: What exactly do you mean by saying "For some reason with C2 on weekly level my "construct" didn't work"?  As described above, I don't see how defining C2 on the ANNUAL level could possibly work as you wanted, if you have WEEKLY level processes downstream (consuming C2), and the total load curve for C2 should be as exogenously defined. Instead, defining C2 on the WEEKLY level works as expected.  If you claim that it does not work, could you please provide more information.

And, as I mentioned, I also tested the user constraint, and it worked fully as expected. If you claim that it does not work, could you please provide more information.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)