Open BSchilperoort opened 1 year ago
Thanks a lot, Bart. I think your suggestion is a good solution. We need to know the accurate solar zenith angle - time zone is just an intermediate variable. Possible fix: change calcsolarzenithangle to use UTC as input time, and apply the longitudinal correction for solar time there. The "timezone" is then not needed anymore either and can be removed from the code.
https://www.ncei.noaa.gov/sites/default/files/2021-08/Angle_Calculations.pdf Bart, please check this document - it gives the needed approximations for calculating the solar zenith angle using GMT/UTC and local latitude, longitude.
The symbols are better defined in: https://en.wikipedia.org/wiki/Solar_zenith_angle {\displaystyle \cos \theta {s}=\sin \alpha {s}=\sin \Phi \sin \delta +\cos \Phi \cos \delta \cos h} where
{\displaystyle \theta {s}}\theta {s} is the solar zenith angle {\displaystyle \alpha {s}}\alpha {s} is the solar altitude angle, {\displaystyle \alpha {s}}\alpha {s} = 90° – {\displaystyle \theta {s}}\theta {s} {\displaystyle h}h is the hour angle, in the local solar time. {\displaystyle \delta }\delta is the current declination of the Sun {\displaystyle \Phi }\Phi is the local latitude.
The model requires the solar zenith angle as an input variable, namely:
ScopeParameters.tts
. This variable is used in quite a few calculations.For loading the variable into the model, there are two options. Either a file is supplied (not used in the current model version), or the solar zenith angle is calculated.
The calculation takes place here: https://github.com/EcoExtreML/STEMMUS_SCOPE/blob/6bf0e9f7c63e752236cb45dc7badf76d97982fe6/src/%2Bio/loadTimeSeries.m#L36-L37
The second input argument of
calcsolarzenithangle
here should be the local solar time. E.g., at 12:00 the sun should be at its highest point. However, the input data applies a correction from UTC time with a "timezone" function.The timezone function is defined here. It returns the offset from GMT in whole hours. However, this is not the exact same as the local solar time. Depending on what the longitude is, there will be a fixed bias in the solar zenith angle.
An example:
calculateTimeZone
will return 0. At this site/location, the model solar zenith will always be leading the real solar zenith by ~30 minutes.Possible fix: change
calcsolarzenithangle
to use UTC as input time, and apply the longitudinal correction for solar time there. The "timezone" is then not needed anymore either and can be removed from the code.@yijianzeng @Yunfei-Wang1993