nightstorage

[dvanre]

Is it possible in some way to have nightstorage deliver some of its output during the night or should I go for another approach

[Antti-L]

Is it possible in some way to have nightstorage deliver some of its output during the night or should I go for another approach

It all depends how you model your night storage. A night storage process that produces a DAYNITE level commodity can only deliver its output during the non-night timeslices. This has always been so in TIMES, and it is by design. The night timeslices that can be used for the charging are defined by PRC_NSTTS.

On the other hand, night storage processes that produce an ANNUAL level commodity will deliver their output according to the load curve of the commodity produced. Such a process may thus charge its storage during the night, but will produce the output according to the demand variations. This type of process may be useful for demand technologies, which should usually produce their output according to the load curve of the demand. For an example, see the earlier topic http://forum.kanors-emr.org/showthread.php?tid=8, and the attached example: uploads/30/demoplugin.zip.

[dvanre]

Dear Antti

Thank you for your explanation. I have tried to implement it but I donot succeed. We model the plugin hybrid with a battery in front (which is a NST). I attach an excel file which has in one sheet the different elements put in the techrep, syssetting and a scenario file. I must do an error but cannot find it; Thanks

Denise

[Antti-L]

Hmmm... are you modeling a separate technology for the car battery, in front of the car technology? If so, why?  Are you in fact modeling several car technologies that utilize the same battery storage?
That would seem strange to me...

Anyway, I could not find any link to the Excel file you mentioned.

[dvanre]

here it is, uploads/31/plugintestdvr.zip

The battery delivers two types of cars

Thanks

Denise

[Antti-L]

Denise:
Ok, so you have added an NST battery technology in front of the cars.  The approach you have chosen should also work, if the TRACBELC commodity is defined to be at the ANNUAL level, and has the appropriate load curve, and if the TRBATCARNST01 process is also defined to operate at the ANNUAL level.  I cannot see these timeslice level definitions in your file, so I cannot verify whether that is the case.  Can you confirm?

If these levels and load curves seem to be ok, can you tell me how you identify the problem?  You only mentioned that "I donot succeed", but you don't give any hint as to what the problem is that you are seeing....

[dvanre]

TRACBELC was at daynite level, so that was the problem. I donot really understand the logic of the TSLV in this case, it seems that the NST technology TRBATCARNST cannot deliver at daynite level a different quantity than the input at daynite level (if the battery and the output of the battery are at daynite level, I get dummys). I thought a storage technology would just do that. 

Thanks

Denise

[dvanre]

Another question: you speak about load curve but how does it matters if the output are at annual level (I have a QFR for TCL,TCS and the same for TRACBELC).

thanks

[Antti-L]

I am sorry but I don't know what the acronyms QFR, TCL, TCS mean.  Are they related to MARKAL?

You need to specify a load curve for the TRACBELC commodity if you want the input to the night storage (TRARELC) to have some load variation by season. In this case, a seasonal load curve is sufficient for TRACBELC, because the DAYNITE variation is already defined by the FLO_SHAR. If you don't specify any load curve for TRACBEL, the demand of TRARELC by the NST battery will be evenly distributed over all seasons.

It is exactly the same situation as for any demand technologies producing an ANNUAL level demand commodity: You need to define a load curve for the demand commodity, in order to have the load curve reflected in the DAYNITE level inputs of electricity to the demand technologies.

[AKanudia]

Denise has merged the QHR of MARKAL and COM_FR of TIMES

TCS and TCL are short and long distance car travel demands.

[dvanre]

Thanks Antti and Amit

If I understand correctly, the NST technology has to be annual if one wants to have different timeslevel allocation for input and output and if the TSL allocation is not defined through the parameter NSTT. Then it is not possible to see if the output follows the com_fr assigned to it (because the output is annual) but in fact it does not matter as the constraint on the input TSL allocation is the one which is important.