Veda2.0 Released!


ELC Car as night storage technology
#1
Hi Amit,

Today, I found a very helpful tutorial on the VEDA Support website about how to model an electric vehicle as a night storage device. 
support.kanors-emr.org/#VEDA-FE/SubFile_ModelLibrary/NIGHTSTORAGEDEVICES.htm

I have a few quick questions about the tutorial, and how I might be able to adapt this technology to our CA-TIMES model.

(1)  The process set "NST" is not one that I've ever seen before.  Do I need to create this set in the SysSettings.xls workbook, or somewhere else?

(2)  The "TimeSlice" attribute is also a new one to me.  I can't find it in the Attributes Master of VEDA-FE.  Should I create it somewhere?

(3)  Can you explain a little bit more about the attribute "NSTTS"?  Is this a binary variable, with 0 and 1 being its only options?  In that case, it seems that in the "TimeSlice" attribute I simply specify the timeslices for which the electric charging is allowed (NSTTS = 1).  In our model, we have 48 timeslices, so the TimeSlice column will contain a long string of characters separated by commas...Or am I wrong about this?  Instead, can NSTTS take on values between 0 and 1, say 0.5.  In the latter case, I could specify that certain timeslices are used for 50% of the charging, and then I could specify another set of timeslices to charge 30%, and another 20%.

(4)  Why is the attribute "STG_EFF" used?  Could we instead use "EFF" or "CEFF"?

(5)  Could I represent plug-in hybrid vehicles (PHEVs) in a similar way as the tutorial for ELC vehicles?  The main difference is that PHEVs use both liquid fuels and electricity, but only the electricity needs to be stored at night for use in the daytime.  The liquid fuel can be stored at anytime.  How can I specify the TimeSlice and NSTTS attributes to apply only to electricity and not to the liquid fuels?

I look forward to hearing from you.
David
Reply
#2
1. NST: You simply need to declare it in the table where the process is declared. For example, DMD, NST in the Sets column.
2. TimeSlice: It is not an attribute; it is an index for parameters and variables. This can be used as a column header in ~FI_T and all Transformation tables. See Process Characterization under Basic Tables on VEDASupport.
3. NSTTS: It is a switch to let the model know which timeslices can be used to charge the storage device. You will need to construct a UC if you want to control the shares across timeslices. But from a modeling point of view, I would suggest that you observe the free solution before constraining the model. This holds for NSTTS as well as the shares.
4. STG_EFF: See the TIMES Doc for this; it is not a VEDA choice.
5. Antti, can you help here? One way to do this would be to model the battery and the car as separate processes.
Reply
#3

On Q5, can’t PHEV be declared as NST technology?  Anyway, liquid fuel wouldn’t be tracked at timeslice level, if it is declared for annual Tsl.

Reply
#4
Yes, a plug-in hybrid can well be modeled as an NST technology.

Doing so will make it possible to either let the model optimize the charging hours withing each day, or to define fixed constraints for the shares of gasoline/diesel and electricity during the day and night hours, or a combination thereof.

As an example, consider that the timeslice levels of your model are ANNUAL, SEASON and DAYNITE, and the DAYNITE level consist of just two timeslices in each SEASON: D (day) and N (nite). You can find an example NST process for modeling a plug-in hybrid in such a model in the attached: uploads/30/demoplugin.zip.

See the User-defined commodity group G-ELCSEAS in SysSettings, the new CARPLUG05 process in NewTechs, and the special G-ELCSEAS share parameters in the transformation file.  In the example, the share of electricity is fixed to 55% in each SEASON, and the the charging is fixed to occur 75% during the nite and 25% during the day.

Note that the NST process is a normal process (because it operates at the ANNUAL level, and only the input flows are at the DAYNITE level), and therefore the storage parameters (e.g. STG_EFF) cannot be used.

Hope this helps,
Antti



Attached Files
.zip   demoplugin.zip (Size: 124.08 KB / Downloads: 22)
Reply
#5
AKanudia Wrote:
4. STG_EFF: See the TIMES Doc for this; it is not a VEDA choice.
I must disagree here: Of course this is a VEDA choice.
Remember that there are no EFF or CEFF parameters in TIMES. VEDA-FE currently converts these efficiency parameters always into the TIMES ACT_EFF parameters for normal processes, and into IRE_FLO parameters for IRE processes. In the same way, if the process has been defined to be of type "STG", VEDA-FE might as well convert EFF into STG_EFF. So, it would, indeed, be possible to use EFF instead of STG_EFF in the same way as we can use EFF instead of ACT_EFF, if only VEDA would be a bit smarter.
But such additional "smartness" might cause a notable overhead if not carefully implemented. Therefore, I am not suggesting that VEDA should be made more smart in this respect, unless it would be guaranteed to have a negligible impact on performance. I would actually recommend to use the genuine TIMES parameters, because the TIMES attributes have been more or less fully documented, and you can thus know how the TIMES attributes are supposed to work. Therefore, I think the current decision of not converting EFF into STG_EFF is a good choice.
Antti
Reply
#6

Hello,

I am currently trying to build a Nightstorage device into my model. I am encountering a problem. My (I am using a small sandbox model) model uses the Nigthstorage technology to satisfy the demand, but the process does not consume any input commodity. It is basically working as a demand importing zero cost technology… I am using the following process data:

 

~FI_Process

 

 

 

 

 

 

 

 

Sets

Region

TechName

TechDesc

Tact

Tcap

Tslvl

PrimaryCG

Vintage

*Process Set Membership

Region Name

Technology Name

Technology Description

Activity Unit

Capacity Unit

TimeSlice level of Process Activity

Primary Commodity Group

Vintage Tracking

IMP

 

Import1

Import for Input1

PJ

PJ/a

DAYNITE

 

 

 

 

Import2

Import for Input2

PJ

PJ/a

DAYNITE

 

 

DMD

 

Demandprocess

Demandprocess1

PJ

PJ/a

DAYNITE

 

 

NST,DMD

 

Nitestorage

Nitestorage1

PJ

PJ/a

DAYNITE

 

 

 

 

 

 

 

~FI_T

 

 

 

 

 

 

 

 

 

 

TechName

*TechDesc

PRC_NSTTS

Comm-IN

Comm-OUT

CUM

COST

EFF

CEFF

Stock

AFA

FIXOM

VAROM

Life

CAP2ACT

*Technology Name

Technology Description

Charging TimeSlice

Input Commodity

Output Commodity

Reserves Cumulative Value

Extraction cost or Import Price or Export Price

Efficiency

Commodity Input Efficiency

Existing Installed Capacity

Annual Availability Factor

Fixed O&M Cost

Variable O&M Cost

Lifetime of Process

Capacity to Activity Factor

Demandprocess

Demandprocess1

 

Input1

Demand1

 

 

 

1

20

 

 

100

100

 

Nitestorage

Nitestorage1

Wi-WD-D2

Input1

Demand1

 

 

1

 

20

 

 

100

100

 

 

I tried implementing the process from the earlier posted DEMO model but it does not produced any results.

Is anybody having a similar problem or can tell where I went wrong?

Thanks a lot!

Seb

Reply
#7
If you really want to have a DAYNITE level NST process like in your example,  specifying PRC_NSTTS is required, or the process will not work.
I don't think you can specify PRC_NSTTS in the ~FI_T table in the way you have done in your example.  It is a parameter in VEDA, and so I guess it is best to define it  in a scenario file. Check in the browser (TIMES View) that this parameter is getting defined.
Reply
#8

Hey,

I finally managed to run the NST storage.

The process operates on a DAYNITE level: it takes up a commodity on DAYNITE and produces an output on an ANNUAL level.

Is there any possibility for producing an output on DAYNITE level?

I had to define the demand as ANNUAL because on any other level, the NST would not work.

Any idea how I could do this?
Thanks! Seb

Reply
#9
Well, it does work in my test models. Nothing special is needed for it to work, just the PRC_NSTTS parameter is important.  Maybe you could post your whole sandbox model here if it is small (zip or rar compressed), so that one could have a look at it and see what might be wrong.
Reply
#10
uploads/71/TestNIGHTSTORAGE.zip

Hi,

here is my sandbox model, it only works on annual demand level...

Thanks a lot for looking at it!
Seb


Attached Files
.zip   TestNIGHTSTORAGE.zip (Size: 533.33 KB / Downloads: 12)
Reply
#11
Thanks for uploading the sandbox model (although you could have left out the database files *.mdb to reduce the size of the ZIP). I can see multiple issues in your test model.  I would be happy to upload a working example later today.  But before doing that, it would be helpful for me to know why you want to model the demand for the CAR travel (commodity CAR) at the DAYNITE level (and the CAR technology as well)? Is there some good reason for that?
Reply
#12

Hi Antti, thanks!

I am planning to analyze the emission trade-off between electric cars (plus increased electricity production) and internal combustion engine cars.

Doing this, I want to use NST devices (as cars), so the model can use cheap off-peak electricity. Additionally, I want to use a demand curve that follows the user behavior on a DAYNITE level. (e.g. high demand when people go to work, go back home and travel during weekends).

Best regards,

Seb

Reply
#13
Ok, I understand your concern, but it seems that you have misunderstood the TIMES functionality here:  Using DAYNITE level demand and a DAYNITE level car technology is not necessary for the modeling of demand load curves and the use of cheap off-peak electricity. That can be done equally well with an ANNUAL level NST technology.

It seems that you have also misunderstood the TIMES concept of DAYNITE level NST process producing a DAYNITE commodity: This type of process is forced to charge the storage only at the PRC_NSTTS timeslices, and it can produce its output only at the non-charging timeslices. This means that it cannot follow the load curve, unless the demand is zero at the night timeslices.

I expanded your test model a bit, and included four alternative ways to model the plug-in hybrid car, which are basically all equivalent. One of these is the DAYNITE-DAYNITE level NST alternative (both the demand and the process are at DAYNITE level). Other alternatives are a DAYNITE-DAYNITE level general timeslice storage (this would be better if you want the process to be able to follow the load curve, or to restrict the fraction of charging that can occur during the night), a DAYNITE-ANNUAL level NST storage (this type of storage can also satisfy any load curve), and a ANNUAL-ANNUAL level NST process (which is a normal process, like the one in the DemoPlugin example).

Finally, I included also an additional variant of the ANNUAL-ANNUAL level NST process, which has also a FLO_SHARE parameter constraining the share of electricity in the total fuel input. These kind of share constraints can only be specified for normal processes, and therefore I think the ANNUAL-ANNUAL alternative may actually be considered the best one for practical modeling of plug-in hybrid cars. For this variant, you can even specify constraints on the fraction of charging that can occur at different timeslices (as demonstrated in my earlier DemoPlugin example).

See: uploads/30/TestPlugin.zip


Attached Files
.zip   TestPlugin.zip (Size: 66.99 KB / Downloads: 42)
Reply
#14
Hey Antti,

thanks a lot for your long explanation. Your TEST model works perfectly. Now I am encountering problems, I tried to simply copy the processes into another model, and nothing work afterwards.
I did the following: I moved the data from the BY trans into a scenario, the commodity definitions and the demand into a by template and the processes into a SUBres. Also I copied the comodity group definitions (from the syssettings) and I adjusted the timeslices.

Do you have any idea what I am doing wrong?

Best regards and thanks a lot.
Seb
Reply
#15

Nope, no idea.  I actually don't know so much about VEDA yet, only about TIMES. But like you, I would be very interested to know why all that happens.

I am well aware that I should attend one of those excellent VEDA training courses given by Maurizio Gargiulo and Kathleen Vaillancourt, but so far I have been too lazy to do all the homework.

Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)