When using gendaymtx to generate the sky matrix, it was observed that non-zero luminance values for each sky patch can still be outputted even when the solar altitude is less than 0. The input file is as follows: input weather tape output
Additionally, the sky matrix produced by the combined use of gendaylit and genskyvec, as opposed to using gendaymtx, can sometimes show significant differences.
For example: #17.5.wea
place Changsha_CHN
latitude 28.22
longitude -112.92
time_zone -120
site_elevation 68.0
weather_data_file_units 1
11 2 17.500 0 47
The gendaymtx command has a completely different implementation of the Perez sky model from gendaylit, and this will occassionally cause discrepancies, especially around sunrise and sunset.
The main difference in your two commands is that you have specified the year (-y 2024) in your gendaylit command, triggering the more accurate per-year sky model. There is no such option in gendaymtx as it is designed for TMY data, so it uses the generic solar calculation. If you take the -y option away from gendaylit, you will at least be starting from the same solar positions in each command.
I don’t know what to say about the final plot. I agree that it looks weird, but I don’t understand what happens in the Perez model at sunrise and sunset.
You call gendaylit with a timestamp where the sun is already set.
If you look at the manual page of gendaylit you will find the solution, which is to use -i 60 in your case:
“-i time_interval[min] If gendaylit is used with weather files, the specified instantaneous points of time may be incorrect. This error occurs due to the fact that measurement results are frequently defined for time intervals, not for specific points of time. Although gendaylit is working correctly, this may lead to wrong outputs especially at low sun altitudes. The -i option allows to specify the time interval of the measurements in minutes, causing the solar position to be corrected for low sun altitudes. A warning message is returned if a correction has been performed”.
If you want to read a bit more about this, you can check the presentation here
Using the -i option can address the issue of incorrect output from gendaylit, yet a notable difference between gendaylit and gendaymtx persists. The sky luminance produced by gendaymtx is evidently unusual.
Below is an example of the sky luminance for Changsha City at 17:30 on November 2nd, as generated by gendaymtx.
Jan is coauthor of gendaylit, but I wrote gendaymtx by wrapping the Perez sky implementation of Ian Ashdown, which he made available to the public.
As I said, I don’t understand the intricacies of the Perez sky model, nor how to account for its behavior near sunrise and sunset. I suggest you run both programs, gendaylit (without -y) and gendaymtx for the same times and locations before and after sunset, and determine when the disagreement becomes serious, if it ever matches.
In reference to Jan’s comments about time steps, gendaymtx takes the exact times given in the .wea file without adjusting for sampling differences that might be present in the weather tape.
I conducted a series of tests and found significant differences between the results calculated with gendaymtx and gendaylit before sunrise and after sunset, as well as a few minutes after sunrise and before sunset.
Hi Greg,
Perhaps the reason is that the sky brightness was limited to 0.6, yet there was no such limitation in gendaymtx.
void check_parametrization()
{
if (skyclearness<skyclearinf || skyclearness>skyclearsup || skybrightness<skybriginf || skybrightness>skybrigsup)
{
/* limit sky clearness or sky brightness, 2009 11 13 by J. Wienold */
if (skyclearness<skyclearinf){
/* if (suppress_warnings==0)
fprintf(stderr,"Range warning: sky clearness too low (%lf)\n", skyclearness); */
skyclearness=skyclearinf;
}
if (skyclearness>skyclearsup){
/* if (suppress_warnings==0)
fprintf(stderr,"Range warning: sky clearness too high (%lf)\n", skyclearness); */
skyclearness=skyclearsup-0.001;
}
if (skybrightness<skybriginf){
/* if (suppress_warnings==0)
fprintf(stderr,"Range warning: sky brightness too low (%lf)\n", skybrightness); */
skybrightness=skybriginf;
}
if (skybrightness>skybrigsup){
/* if (suppress_warnings==0)
fprintf(stderr,"Range warning: sky brightness too high (%lf)\n", skybrightness); */
skybrightness=skybrigsup;
}
return; }
else return;
}
Another issue arises the sun’s zenith angle was simply set to 90 degrees when the altitude is less than zero. I altered the gendaymtx source code to include the sky brightness limitation and added the -i option to define the measurement’s time interval in minutes just like what’s done in gendaylit. After recompiling, it produced identical results.
The modified source code is here gendaymtx.c - Google Drive
yes, at that time my colleague, Wendelin Sprenger, did exhaustive tests with measured data where we encountered several issues during sunrise and sunset. As solution we introduced the -i option to avoid the problematic of sun position below horizon, but still measured significant irradiances. Further we limited some parameters that seemed to overflow to physical reasonable values, this is what you found out to be the reason of the difference. However, one thing should be said: I would not expect neither measurements nor models to be correct close to sunset/sunrise since the measurements of such an extreme condition are extraordinary difficult and in-cooperate high uncertainties. The previous version of gendaylit was simply stopping and not delivering any value if sun was below horizon or values were overflowing (if I remember correctly we used the same thresholds than before). This was counterproductive when running simulations on time-step basis that include data around sunrise and sunset. To enable such simulations we did these changes, but had originally the warnings enabled, not sure why we commented them out. Maybe we should enable them again.
Ian did an independent Perez model implementation just some months before ours that was based on the previous version of gendaylit, that didn’t have these functions - that’s why those two implementations gendaymtx and gendaylit are not exactly the same. But with each of such studies they become closer and closer .
.