search

open-ideas / IDEAS

Modelica library allowing simultaneous transient simulation of thermal and electrical systems at both building and feeder level.
131 stars 56 forks source link

new weather file causes diffuse solar irradiation peaks #1239

Closed Mathadon closed 2 years ago

Mathadon commented 2 years ago

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

Mathadon commented 2 years ago

Green curve:

image

commit 1bf01dd2a3151ccec182edd78931353097cd3649

Mathadon commented 2 years ago
image

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

Mathadon commented 2 years ago

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

Mathadon commented 2 years ago

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

Mathadon commented 2 years ago

@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:

image

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 commented 2 years ago

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:

image

This suggests the same shift.

mwetter commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

Thanks for the confirmation.