Question-and-Answer Resource for the Building Energy Modeling Community
 | 1 | initial version |
Yeah, there is a big disconnect here. Your results are for "CIE skies", which Mostapha (and I) are assuming were generated with gensky. Gensky takes location (lat/long) and time of day as Mo said, as well as the very general sky conditions (clear, overcast, "intermediate"...). Comparing these results to the (presumably) exterior global/direct normal/diffuse horizontal values which (again, presumably) came from an epw file is apples and oranges, since the epw data on any given day will vary significantly from these ideals of totally clear or overcast. (This is why climate based daylight modeling has come about in the first place.)
As Mo said you could use gendaylit for your sky generation, using these actual exterior values from the epw file as your inputs (climate based!). You could also use gensky as it appears you have been, and simply place a calculation point above your model, free of obstructions (or calculate for 0,0,0 with the same sky and an otherwise empty octree), and calculate illuminance for that point. That way you'd truly have two apples, of the same variety, even. You'd have (total) exterior daylight illuminance (sun+sky), with which to compare to your interior values.
To your last point about validating your results with hand calculations, you can easily do this for the sky model (see pp354-356 in "Rendering with Radiance"). When it comes to the interior points where you're dealing with interreflection though, things can get nasty in a hurry though. Again if you're simply looking to validate the process you'd want to use a really simple model (shallow box of a room with totally diffuse surfaces, clear specularly transmitting glazing, and a centrally located calculation point). Otherwise you're validating at least a couple different kind of apples, if not two different fruits altogether.
| | 2 | No.2 Revision |
Yeah, there is a big disconnect here. Your results are for "CIE skies", which Mostapha (and I) are assuming were generated with gensky. Gensky takes location (lat/long) and time of day as Mo said, as well as the very general sky conditions (clear, overcast, "intermediate"...). Comparing these results to the (presumably) exterior global/direct normal/diffuse horizontal values which (again, presumably) came from an epw file is apples and oranges, since the epw data on any given day will vary significantly from these ideals of totally clear or overcast. (This is why climate based daylight modeling has come about in the first place.)
As Mo said you could use gendaylit for your sky generation, using these actual exterior values from the epw file as your inputs (climate based!). You could also use gensky as it appears you have been, and simply place a calculation point above your model, free of obstructions (or calculate for 0,0,0 with the same sky and an otherwise empty octree), and calculate illuminance for that point. That way you'd truly have two apples, of the same variety, even. You'd have (total) exterior daylight illuminance (sun+sky), with which to compare to your interior values.
To your last point about validating your results with hand calculations, you can easily do this for the sky model (see pp354-356 in "Rendering with Radiance"). When it comes to the interior points where you're dealing with interreflection though, things can get nasty in a hurry though. hurry. Again if you're simply looking to validate the process you'd want to use a really simple model (shallow box of a room with totally diffuse surfaces, clear specularly transmitting glazing, and a centrally located calculation point). Otherwise you're validating at least a couple different kind of apples, if not two different fruits altogether.
