Why does Analaysis Period have a 1 hour offset?

[edpmay]

I am trying to align some calculations, and getting tripped up by the way Ladybug handles analysis-periods relative to the EPW data?

Scenario:

If I have some normal EPW data:

and if I apply an analysis period of 1 day (Jan 1), I would expect to get the values in the EPW for day 1 (for instance, for dew-point, in the example here shown here, staring at the value of ‘-2.8’):

but instead it is ‘offset’ by 1 hour. Meaning: the first value it returns is actually hour 8760, and it ‘dops’ the line for hour “1996, 1, 1, 24,…”:

---

So is ladybug’s analysis period always ‘offsetting’ the data by 1 hour like this? I find that confusing as it does not align to the dates listed in the EPW file?

Or am I supposed to be handling the analysis period differently somehow?

I would have expected to just get all of the lines with the 1/1 date?

best,
@edpmay

---

Example:

example.gh (23.7 KB)

[XiAO]

I also meet this issue recently.

I use the data from the Photovoltaic Geographical Information System (PVGIS) of European Commission.

I choosed one hour, which is on the PVGIS site for example 12, it will apears on the detailed pdf sheet (generated by PVGIS site) as 11:45, in grasshopper with ladybug it will be 11.

Curious about whether it is a general rule, since grasshopper starts with 0 instead of 1 in its counting system.

[MatteoMerli]

Hi @edpmay,

I also find it difficult to understand the convention adopted by LBT.

There are a few threads related to this, but none of them clarify the issue:

1. Comparing different TMY/EPW providers : inconsistency of data? - #18 by lionpeloux
2. Mismatch between the sun position and the red region of the sky dome - #7 by Kta
3. EPW first hour of the day - #2 by mostapha
4. Ladybug Analysis Period Explained - #2 by chris

One thing that is clear is that EnergyPlus considers time from 1 to 24, where Hour 1 refers to the time interval 00:00:01 AM to 1:00:00 AM, Hour 2 is 1:00:01 AM to 2:00:00 AM (hh:mm:ss), and so on. In other words, the values of the variables are the average or sum (depending on the type of variable) of the entire time bin prior to the timestamp (source). The same applies to EPW files (source).

When analysing weather data through the LB Import EPW component, it seems that LBT expects users to continue using the 1-24 convention, shifting all values by +1 and using the last value of the year as the first.

Or am I supposed to be handling the analysis period differently somehow?

I wondered the same, but even if the hypothesis above was correct, it wouldn’t work in practice, because the Apply Analysis Period component still asks for values between 0 and 23. Let’s say that it would work for Hour 1 (input 1 to get the second value in the list, which corresponds to the first in the EPW), but it wouldn’t be possible to input 24 to get the last value in the list…

Personally, this creates me issues when I compare E+ outputs with the weather data extracted from LB Import EPW, as they are offset by 1 hour.

Perhaps only @chris, @mostapha, @AbrahamYezioro or someone from the LBT team can clarify us the reasoning behind this choice or point us to another post where it has already been explained, which I may have missed.