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


Forum Jump:


Users browsing this thread: 1 Guest(s)