black sky temperature computation inconsistency

[Mathadon]

When computing the black sky temperature in Annex60.BoundaryConditions.SkyTemperature.Examples.BlackBody using both of the provided options I get:

There is a delay of 1800s between the two computations, which suggests that one of the input signals for these computations is read using a CombiTable1Ds with a wrong delay: HHorIR may not need to be delayed by 1800s, or the cloud coverage should be delayed.
@mwetter do you know which one it is, or should I dig further in the definition of TMY3?

[mwetter]

@Mathadon Can you please check which of the time series has a wrong offset. Please see also the note about shifting the solar radiation data in the info section of ReaderTMY3.
Also, when fixing this, please update the test so that both options are tested and part of the reference results

[Mathadon]

You mean that I should make sure that both variables are in the reference results somewhere?
edit: when reading it again it's pretty clear that's what you mean..

[Mathadon]

The TMY3 report (http://www.nrel.gov/docs/fy08osti/43156.pdf) contains:

but does not seem to reference infrared radiation. So I'm not sure where that data comes from and what convention they use. However all other irradiance are in units of average Wh per hour, so if this would be correct then the current implementation is correct.

Since we get our files from energyplus: they mention the horizontal infrared radiation in the documentation (https://www.energyplus.net/sites/default/files/docs/site_v8.3.0/EngineeringReference/05-Climate/index.html) but they do not mention the convention that is used.

I assume that, since EP seems to have added this variable to their weather files, we have to offset the time-axis for this variable to match the TMY3 implementation. I will adjust the implementation accordingly.

[Mathadon]

This will be fixed in #670
New result is: