new weather file causes diffuse solar irradiation peaks

[Mathadon]

There are diffuse solar irradiation peaks in the new weather file. Setting time zone to 2 fixes the problem.

[Mathadon]

Green curve:

commit 1bf01dd

[Mathadon]

Root cause seems to be the computation of skyBrightness.skyBri.

[Mathadon]

Relative air mass is correct: it peaks at 19:03 on march 26th.

[Mathadon]

The problem seems to be that the diffuse solar irradiation is shifted by approximately 1 hour. The weather file is thus again wrong.

[Mathadon]

@mwetter I have run the script java -jar ../bin/ConvertWeatherData.jar <filename> to generate the weather file: https://github.com/open-ideas/IDEAS/blob/master/IDEAS/Resources/weatherdata/Brussels.mos as instructed in IDEAS.BoundaryConditions.WeatherData.ReaderTMY3 using the EnergyPlus EPW file for Brussels. This file seems to contain shifted diffuse solar irradiation data (the time zone seems to be off by one hour) and possibly other data are also shifted.

Example:

The diffuse solar irradiation is non-zero while the solar altitude angle is smaller than 0.

Is there by any chance a bug in the conversion script (the time zone could be wrong) or is the source file wrong?

[Mathadon]

To rule out further implementation error in IDEAS:

9007200.0	5.1	3.9	92	100900	0	1358	276	0	0	0	0	0	0	0	280	4.1	1	1	10.0	22000	9	999999999	0	0.1830	2	88	0.000	0.0	0.0	
9010800.0	5.0	3.3	89	101000	1	1358	279	0	0	0	0	0	0	10	260	5.1	2	2	10.0	22000	9	999999999	0	0.1830	2	88	0.000	0.0	0.0	
9014400.0	5.0	3.3	89	101100	129	1358	284	 ---> 26 <---	0	26	2900	0	2900	900	270	5.7	4	4	10.0	22000	9	999999999	0	0.1830	2	88	0.000	0.0	0.0	
9018000.0	5.7	3.8	88	101200	348	1358	279	149	207	96	15900	16100	11900	1880	280	5.1	2	1	13.0	22000	9	999999999	0	0.1830	2	88	0.000	0.0	0.0	
9021600.0	7.6	4.2	79	101300	556	1358	296	255	149	194	27800	13700	22500	4570	290	6.2	5	4	13.0	22000	9	999999999	0	0.1830	2	88	0.000	0.0	0.0	
9025200.0	7.5	4.8	83	101400	737	1358	304	199	21	188	22900	1600	21700	7970	300	6.2	9	7	13.0	480	9	999999999	0	0.1830	2	88	0.000	0.0	0.0	
9028800.0	7.9	4.5	79	101400	880	1358	306	253	21	240	29300	1700	27900	10500	290	6.2	9	7	13.0	540	9	999999999	0	0.1830	2	88	0.000	0.0	0.0	
9032400.0	9.0	4.5	73	101500	974	1358	311	289	24	272	33600	1900	31800	12150	290	6.2	9	7	15.0	600	9	999999999	0	0.1830	2	88	0.000	0.0	0.0	
9036000.0	9.3	4.3	71	101500	1015	1358	305	583	295	362	63200	29700	41100	11560	300	5.7	5	5	15.0	22000	9	999999999	0	0.1830	2	88	0.000	0.0	0.0	
9039600.0	9.8	4.3	68	101500	997	1358	305	605	396	313	66100	39900	36200	9550	300	5.4	4	4	16.5	22000	9	999999999	0	0.1830	2	88	0.000	0.0	0.0	
9043200.0	10.3	4.2	66	101600	924	1358	307	576	473	253	61700	46600	31300	6870	310	5.1	4	4	18.0	22000	9	999999999	0	0.1830	2	88	0.000	0.0	0.0	
9046800.0	10.4	4.1	65	101600	800	1358	302	137	0	137	16400	0	16400	6480	320	5.7	10	2	18.0	3000	9	999999999	0	0.1830	2	88	0.000	0.0	0.0	
9050400.0	10.9	3.4	60	101600	633	1358	300	370	150	300	40800	14500	33600	7750	320	5.7	2	1	18.0	22000	9	999999999	0	0.1830	2	88	0.000	0.0	0.0	
9054000.0	10.4	2.5	58	101700	434	1358	297	176	149	129	19300	13000	15100	2900	320	4.6	5	1	20.0	22000	9	999999999	0	0.1830	2	88	0.000	0.0	0.0	
9057600.0	9.6	3.1	64	101700	218	1358	305	50	0	50	5600	0	5600	1730	310	3.1	6	5	20.0	3000	9	999999999	0	0.1830	2	88	0.000	0.0	0.0	
9061200.0	8.5	4.2	74	101800	26	1358	308	 ---> 2 <---	0	2	300	0	300	90	310	1.5	9	7	20.0	1800	9	999999999	0	0.1830	2	88	0.000	0.0	0.0	
9064800.0	7.6	3.9	77	101900	0

means sun rises before 15 April 08:00:00 and after 15 April 1970 21:00:00 while https://www.timeanddate.com/sun/belgium/brussels lists:

This suggests the same shift.

[mwetter]

@Mathadon : There is a time shift in parsing the solar radiation data because TMY3 lists the integrated solar radiation of the hour that precedes the time stamp. See also section "Time shift for solar radiation data" in IBPSA.BoundaryConditions.WeatherData.ReaderTMY3

I remember that we worked with @zuowangda quite extensively on that time shift and the smoothing of the solar radiation because TMY3 lists horizontal radiation, that are then projected on the surface, which can lead to huge peaks if the sun is right at the horizon.

For what it is worth, the BESTEST validation that Ettore conducted did not show any issues. This however doesn't rule out that there is a bug somewhere that hasn't been detected

[Mathadon]

@mwetter I am aware of the solar radiation integration but I figured that this should be fixed by the half hour time offset in the table reader.

After checking further it turns out that the ConvertWeatherData.jar in IDEAS v2.1.0 contained a bug that resulted in the wrong time stamps being generated in the mos file. I.e. time stamp 3600 was skipped and all subsequent time stamps were shifted by 1 hour. This problem is fixed in the master branch but I was not able to run that jar file using the java version of my VM. It does work on Mac though, which is how I discovered the difference.

[Mathadon]

Furthermore, we will change weather file to the Uccle file from https://climate.onebuilding.org since we apparently do not have a license for IWEC.

[mwetter]

@Mathadon : Is the ConvertWeatherData.jar in IDEAS v2.1.0 different from the one used in the IBPSA (and hence probably all other) libraries, or does the one in IBPSA also suffer from this bug?

[Mathadon]

@mwetter

git diff v2.1.0 -- IDEAS/Resources/bin/ConvertWeatherData.jar 
diff --git a/IDEAS/Resources/bin/ConvertWeatherData.jar b/IDEAS/Resources/bin/ConvertWeatherData.jar
index bfe773603..2fec94566 100644
Binary files a/IDEAS/Resources/bin/ConvertWeatherData.jar and b/IDEAS/Resources/bin/ConvertWeatherData.jar differ

It seems like you updated the jar in 2020:

 git log  -- IBPSA/Resources/bin/ConvertWeatherData.jar 
commit eada6113aee0cddd0d1da0f1da1e816d0c59513e
Author: Michael Wetter <mwetter@lbl.gov>
Date:   Wed Nov 11 12:15:17 2020 -0800

    Regenerated and tested binary files

commit d45535601dc00936112785a94c748eb1bf24c92c
Author: Michael Wetter <mwetter@lbl.gov>
Date:   Mon Oct 12 07:12:59 2020 -0700

    Regenerated jar and docs

This fixed the bug so the problem should be resolved in IBPSA.

[mwetter]

Thanks for the confirmation.