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?
08-06-2010, 01:56 PM (This post was last modified: 09-06-2010, 04:45 AM by AKanudia.)
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.
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.
09-06-2010, 05:34 PM (This post was last modified: 10-06-2010, 03:59 AM by Antti-L.)
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.
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?
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.
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.
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?
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).
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).
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.
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.