rewrite functions in pv_model #689
Conversation
| @@ -333,7 +334,7 @@ final case class PvModel private ( | |||
| val e0 = 1.000110 + | |||
| 0.034221 * cos(jInRad) + | |||
| 0.001280 * sin(jInRad) + | |||
| 0.000719 * cos(2d * jInRad) + | |||
| 0.00719 * cos(2d * jInRad) + | |||
There was a problem hiding this comment.
According to Iqbal, this is 0.000719 with three zeroes. The primary source, Spencer, also states the same. Duffie and Zheng as well. Please check again.
Furthermore, could you add the missing sources I just mentioned to the list of sources in documentation as well?
There was a problem hiding this comment.
This is Duffie p. 9, where I noticed the 2 zeros only. Can you maybe send me the PDFs of the other books, so I can look it up aswell?
There was a problem hiding this comment.
Interestingly, the fifth edition of Duffie seems to differ from all earlier editions in this point. Given that the cited sources stayed the same and I didn't find any other explanation (and the layout seems broken in this edition for the first time), I assume that the change did not happen on purpose and the number with three zeros is still correct. There should be some more investigations here, though.
| @@ -551,12 +581,12 @@ final case class PvModel private ( | |||
|
|
|||
| if (eDifH.value.doubleValue > 0) { | |||
| // if we have diffuse radiation on horizontal surface we have to check if we have another epsilon due to clouds get the epsilon | |||
| var epsilon = ((eDifH + eBeamH) / eDifH + | |||
| var epsilon = ((eDifH + eBeamH / cos(thetaZInRad)) / eDifH + | |||
There was a problem hiding this comment.
Both Duffie and the original Perez use the formula as before. Where did you find the formula with cos thetaZ again?
There was a problem hiding this comment.
This is my reference (Duffie p. 95f). Note that "I_b,n" is not the beam radiation on a horizontal surface, but rather the beam radiation on a surface normal to the direction of the sun. This can be calculated by dividing the beam radiation on a horizontal surface "I_b" (=eBeamH in code) by cos(ThetaZ). This is also demonstrated in Duffie: example 2.16.2
| // variable that accounts for cases when the integration interval is shorter than 15° (1 hour equivalent), when the time is close to sunrise or sunset | ||
| val timeFrame = (omega2 - omega1).toDegrees / 15d / duration.toHours // original term: (omega2 - omega1).toRadians * 180 / Math.PI / 15, since a one hour difference equals 15° |
There was a problem hiding this comment.
I'm not fully convinced by your proposal yet.
The original problem is that the ratio between a and b can tend to infinity because the radiation on the horizontal surface goes to 0, while the radiation on tilted surface can stay fairly big if tilted towards sunset.
The solution proposed with R_{b,ave} = a/b is to calculate some sort of average over a time period between omega1 and omega2. This way, the extreme values calculated when using just one point in time close to sunrise or sunset gets reduced. This works because the value further away from sunrise or -set pulls down the average again.
All this was just how it's supposed to work. If now the time slice between omega1 and omega2 is very small, the "relief" we get from the second value is quite reduced. Now it seems like some sort of "crutch on a crutch" or "workaround around a workaround" to try to calculate our way back to the time interval of one hour. This is because calculating an average from a time interval is already a workaround (which could be debatable, I guess). And furthermore this would only work if the change in radiation is proportional to the change in angle omega, which doesn't seem clear to me.
Curious about your thoughts.
There was a problem hiding this comment.
I am not quite sure what you mean by "calculate our way back to the time interval of one hour". If the difference between omega1 and omega2 is very small, we are not looking at a full hour, but rather a few minutes. The problem is that the available weather data contains the radiation energy of one full hour in Wh/m^2, which would obviously result in a false result if we multiply it by R_b,ave. This is why there is the linear factor "timeFrame" between 1 and 0, which should solve this problem.
Also, I partially get what you mean by "workaround around a workaround", but doesn't that also apply for the current implemenation aswell? There, the problem is solved by artificially keeping the difference between omega1 and omega2 fixed, which is inaccurate at times close to sunrise or sunset.
Besides, can you please explain why the change in radiation must be proportional to the change in omega?
Furthermore, if you already looked at the integration test, did you notice anything odd? Were there any very high peaks?
# Conflicts: # src/main/scala/edu/ie3/simona/model/participant/PvModel.scala
There was a problem hiding this comment.
I also have two more points regarding documentation (readthedocs):
The link to source for Iqbal.1983 has become invalid. Could you find a new link here (could just be a link to the respective page of the publisher, if nothing else is available)? Also please check all other links.
Also related to literature: Could you also indicate page numbers for each source? This has already been done for some sources, but is missing for others. It can speed up understanding the model a bit.
resolves #688
I will try to optimize the beam radiation for times close to sunrise or sunset. I will adjust the case distinction of omega1 and omega2, also allowing for smaller intervalls between them. This will be balanced out by multiplying the power with the time difference between omega2 and omega1, thus not creating very high peaks in power outputs in the morning (or evening).
Also, I removed the condition Theta_G < 90°, since that should only result in a negative value of r, which is already accounted for, making it unneccessary.
Please let me know what you think!