HOYS with minutes

[DambronOlivier]

hi @mostaphaRoudsari ,

I was trying to add more granularity of timestep to generate more images with DC_image-based.

If I am not mistaken, it seems that the HOYS are not taking into account the decimals for a given list of hours. Perhaps it is the way the WEA rounds hours. Would it be causing issues elsewhere to get minutes into the WEA?

Kind regards,
Olivier

[mostaphaRoudsari]

Hi @DambronOlivier, I can't thank you enough for checking all these inputs before the release. Let me check and see how genskymtx will work with sub-hourly data.
Currently the wea data is only generated for each hour and doesn't support sub-hourly data. Even if gendaymtx works fine we need to find a solution to extrapolate sub-hourly radiation values to get this to work correctly.

[sariths]

@DambronOlivier. First up, I too want to thank you for trying out these components before the release. Although, I haven't been participating in any of the discussions, I have been reading all of them.

@mostaphaRoudsari As you pointed out, the issue with doing sub-hourly values has more to do with radiation values than whether gendaymtx can handle it. Gendaymtx will work fine if we modify the wea file to reflect those sub-hourly values.

As far as modifiying the wea file and corresponding radiation values go, this has been studied before:

Walkenhorst O, Luther J, Reinhart C F, Timmer J, “Dynamic annual daylight simulations based on one-hour and one-minute means of irradiance data.” Solar Energy, 72:5 pp. 385-395, 2002.

....which, in turn, is based on ....

Skartveit, A., and J. A. Olseth. "The probability density and autocorrelation of short-term global and beam irradiance." Solar Energy 49.6 (1992): 477-487.

Bottom-line is that we can implement this thing. If we get the interpolation part going rest of the back-end API is already in place.

However, I am not entirely sure if this is "mission-critical" as we'd be interpolating radiation values that are already based on TMY data (typical is the key here). I doubt if we'd learn anything useful from that. I do see a value in being able to do this through gendaylit wherein we can plug measured values from weather stations.

[sariths]

Hi @DambronOlivier and @mostaphaRoudsari , I can confirm that smaller timesteps will work with whatever we have presently. Here is an example: https://www.youtube.com/watch?v=2rXrWhIf-4o&feature=youtu.be

The timesteps in the video are at 1 minute intervals. I generated the data from Daysim which has the interpolation algorithm built-in. We'd have to replicate the same algorithm in HB[+] to make it fully functional. The good news is that as and when we do implement it, we have a ready reference to check our results against.

[mostaphaRoudsari]

Thank you @sariths! Here is the code that we need to add in order to create the subhourly wea file.
https://github.com/MITSustainableDesignLab/Daysim/blob/combined/src/daysim/ds_shortterm.c

[mostaphaRoudsari]

gendaylit has a timeinterval input which might be the solution to this problem. Will write more later.

[Sonderwoods]

Has the reverse interpolation been implemented into HB[+] yet?

[mostaphaRoudsari]

This is now possible if you use wea.from_file classmethod to import wea files with smaller timesteps than 1 generated by Daysim. Not sure if we will ever get the chance to rewrite dc_shortterm in Python.