gendaylit1axis() making less skyfiles

[ebousi]

Dear Sir/Madam,

The gendaylit1axis() function is creating less skyfiles than the necessary one (see Figure).

As a result although the metdata has the full year weather data, the gendaylit adds the skyfile till a certain day of the year (typically end of November).

Thanks in advanc for your support,
Erion

[shirubana]

when you load the weather data, do you have a start_date or end_date ?

Also, do these entries have valid values for DNI, GHI and DHI? I think it cuts values very close to 0.

S.

[ebousi]

Hi Silvana,

Thank you for the very quick reply.

To give some more insights in my example:

• The metdata file has 4608 entries ending on the 31st December
• the trackerdict after applying the set1axis() has 4382 data points, less cause as you said it cuts values close to zero.

The strange things happens when you apply the gendaylit1axis() function, here the datapoints are cutted further, always from the end.

I did a bit more deep research on this, and in my opinion the problem comes from the indexing of the gendaylit1axis() function.

In the photo is part of the gendaylit1axis() function.

        - At point 1 the for loop iterates over the trackerdict dictionairy whih has 4382 points.              
        - However at point 2 the if statement is checking over the metdata dictionairy which continues having 4608 points. 
        - As a result the counter is mixed between the metdata and the trackedict.

PS. The above are just suggestions, there is still a chance I am completely wrong :).

Thank you for the support,
Erion

[shirubana]

@ebousi Is there any possibility you can share the weather file (if you want to anonymize it with a similar but diffferent lat or lon or name), to my NREL email to test this? I just tested it and are not seeing this behaviour on another weather file. silvana.ovaitt@nrel.gov

[magnetohack]

I experience the same issue - that hourly full-year simulations with a single axis tracker stop short of completing the full year. From what I can tell, the problem stems from incorrectly assuming that trackerdict and metdata share a common integer index, as @ebousi points out. This will likely cause mixing of irradiation data and tracker angles that do not correspond.

trackerdict gets created as an empty dict and initialzed in _set1axis (lines 3275-3287 of 'main.py' (see screenshot)), based on timestamps in the epw file. However, since only ghi>0 and valid tracker angles are kept, trackerdict and metdata will not generally be of the same length, and entries indexed with an integer will not correspond between the two.

If trackerdict instead get initialized with

trackerdict = dict.fromkeys(times)

(that has been commented out in line 3274), the problem goes away - as trackerdict gets to have the same length, keys and order as the metdata.

The approach of indexing these data structures with integer indices that strictly require length and order to correspond seems risky, especially when pruning entries (ghi<0, etc.) various places in the code. Perhaps it would be safer to use the datetime index to look up the corresponding entries between dictionaries?