Veda2.0 Released!


Modelling issue with solar PV
#1

Modelling issue with solar PV

We have an hourly Swiss TIMES model (>200 annual timeslices).  Solar PV has been characterised (Tslvl) as Daynite technology.  Then we have introduces ‘zero’ AF for night timeslices.  But the model chooses solar PV as a flexible technology (as if one could switch on/off solar radiation!) and uses its full annual AF (of 10%) during peak hours (see Fig 1)!  uploads/24/STEM-solar_PV.doc

 

Fig.1: Solar PV as Daynite technology

 

If PV is characterised as a seasonal technology, then the model ignores the zero AF for night timeslices.  Thus, electricity is uniformly produced during day and night time (see Fig. 2).  But we don’t want any night time ELC generation from solar PV!

 

Fig.2: Solar PV seasonal technology

 

Is there any way to address this problem? Suggestions/recommendations are most welcome

For the time being, we do not have data for solar PV other than seasonal AF.  So, we want to have something like zero generation during night, but daytime generation must be spread across day time.

As a least resort, we would introduce an hourly AF for all daytime timeslcies (by averaging the seasonal AF), but we end-up with over 200 additional columns/rows for input data.

Thanks

 



Attached Files
.doc   STEM-solar_PV.doc (Size: 42.5 KB / Downloads: 8)
Reply
#2
In general, timeslice-dependent values of TIMES attributes are inherited from higher level timeslices (e.g. ANNUAL) to lower level timeslices (e.g. DAYNITE). Therefore, in most cases you can define a default value at the ANNUAL level, which is then inherited to all DAYNITE timeslices unless they already have a value explicitly defined.

However, the esteemed professors who designed TIMES made NCAP_AF to be an exception to this general rule: An NCAP_AF(ANNUAL) is not taken into account, if any non-zero NCAP_AF values are also defined at some target DAYNITE timeslices. This is a bit unfortunate, and the TIMES code can only be changed if all the main designers and TIMES users agree on the proposed change.

So, only if all the NCAP_AFs for the night-time timeslices are strictly zero, you can use NCAP_AF(ANNUAL) as a shortcut for defining the default AF for all daytime timeslices. But there is also a work-around: You can use NCAP_AFS for defining any non-zero availablity factors for all the night timeslices. Then you can still use NCAP_AF(ANNUAL) to define the default AF for all daytime timeslices, because then there are no explicit non-zero NCAP_AF values specified at the DAYNITE timeslices.

I hope this work-around can be of help for avoiding too many additional rows and columns for the input data. Embarrassed

[Edit:] See also the Tips and Suggestions section for VEDA-FE, where another tip is given.
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  IMPNGZ Dummy Issue subhadipbhattacharya 1 2,031 17-09-2021, 06:58 PM
Last Post: Antti-L
  VFE case export issue james 1 2,097 04-06-2021, 07:44 AM
Last Post: AKanudia
  Uptake of Solar under Solar subsidy xavier 2 2,927 22-04-2021, 04:36 PM
Last Post: xavier
  Solar lower costs impact capacity constraints LucasD 10 8,862 18-12-2020, 03:04 PM
Last Post: AKanudia
  Modelling question of the rate of decline in CO2 emissions zhangshu 3 4,075 11-12-2020, 07:32 PM
Last Post: zhangshu
  Issue after Windows-Office update Luc 7 8,256 11-11-2020, 08:39 AM
Last Post: guozhi1305
Photo SOLVE ISSUE JozefO 10 11,128 08-10-2020, 12:30 AM
Last Post: JozefO
  Issue with constraint: Error Code 172 NeilGrant 5 6,886 28-05-2020, 02:08 PM
Last Post: NeilGrant
  Problem with EV-charging modelling janisd 8 9,410 26-03-2020, 12:18 AM
Last Post: Antti-L
  Issue with EQ_Combal and VAR_Comnet NeilGrant 6 8,246 15-11-2019, 08:18 PM
Last Post: Antti-L

Forum Jump:


Users browsing this thread: 1 Guest(s)