hello @chris , First of all happy super new year!
I was trying to run an sub-annual daylight simulation with a timestep 4 (every 15 min) but got this error message: 1. Solution exception:Wea timestep must be 1 for this recipe.
Is there a way around this? or better to go PIT for all hoys?
Best,
Olivier
Hi @OlivierDambron ,
This is intentional because all of the methods that perform postprocessing on the illuminance matrices to produce DA and UDI rely on the analysis being at a timestep of 1 in order to have the illuminance values correctly aligned with the occupancy schedule. I was thinking that I would eventually add support for running the annual daylight recipe at a finer timesteps but it requires a significant refactor of these postprocessing methods and so it would take some time.
So I guess it all comes down to what you need out of the analysis. If you don’t need DA or UDI out of the analysis and you just need the matrix of illuminance values, then it doesn’t take much time to make a recipe that does what you want. You’ll see that the Annual Irradiance recipe is perfectly fine with running Wea’s at finer timesteps as long as you also plug the timestep into the recipe. We really only need to tweak a couple of things in that recipe to turn it into an “Annual Illuminance” recipe. In fact, I can probably just add a solar/visible boolean option to the recipe if this would solve your issue.
But, if you need DA or UDI, then you’ll have to wait until we get the chance to refactor these post-processing methods.
hi @chris
Thanks for your anwser.
I won’t need DA nor UDI on a smaller timestep. I’m not sure it would really make a difference, perhaps on the simulation time only.
I’ll find my way through the Annual Irradiance and I’ll tweak the bits to get illuminance on smaller timesteps. Thanks for the pointing this out.
Indeed a boolean option to the recipe would be useful considering it’s the same GH definition behind and the same DC method. Perhaps another optional input for SHGC in the Glass modifier component could be useful. This way users can specify the Transmissivity and the SHGC, and as the recipe is toggled to daylight or solar, the correct value would be considered.
Good to know, @OlivierDambron . I’ll try to add the boolean option for visible irradiance at some point soon.
Just to clarify, you should be using the solar transmittance if you want to evaluate solar load with the Annual Irradiance recipe and not the SHGC, which includes both the directly transmitted solar energy as well as the energy that gets absorbed by the glass and conducts to the interior under standardized thermal conditions.
Changing the glass component to produce two sets of radiance modifiers (one for solar and one for visible) is a bit tricky but you’ll see with the HB Search Modifier Sets component that honeybee ships with different modifier sets that you can use for either visible or solar studies. So I would recommend using those if you’re trying to change your modifiers to suit a solar vs. visible study.
@chris thanks for the much needed reminder.
Regarding the HB Modifier Sets, is the source of the double glazing specs noted somewhere the (looking for the corresponding U value and if with argon or low-e) ?
I think my best shot would be to pick a couple of good Single and Double glazing specs from WINDOW LBNL, calculate their Solar transmittance and build my own set of glazing specs.
If I understand correctly for the Annual irradiance recipe, I stick to the Glass modifier and input the solar transmittance value instead of the Visible?
Hey @OlivierDambron ,
I just finished adding a visible_ option to the Annual Irradiance recipe, which will allow you to run a daylight simulation at sub-hourly timesteps. I should clarify that the recipe still outputs irradiance (in W/m2) when you set this visible_ option to True but these irradiance values will be just for the visible portion of the electromagnetic spectrum. You can convert the visible irradiance values into illuminance by multiplying them by the Radiance luminous efficacy factor of 179.
I might recommend using the Annual Results to Data component to import the visible irradiance values and then multiply them by 179 using the LB Arithmetic Operation component. This will be a little faster than doing all of the math with native Grasshopper components.
I don’t really have a reference other than the default Honeybee-energy constructions, with which these 4 ModifierSets are coordinated. I know that there was some standard from which the 20%Floors/ 50%Walls/ 80%Ceilings comes from (I think it’s an IES standard) but I don’t think that it gave recommendations for window transmittances. In any event, we generally tried to match the specs of not-too-expensive double-pane Low-E windows for the exterior windows and single-pane for interior windows.
If you are using the new visible_ option in the Annual Irradiance recipe, then the reflectances and transmittances of your modifiers should be in the VISIBLE part of the spectrum. Otherwise, if you are using the Annual Irradiance to study broadband solar energy, then the reflectances and transmittances of your modifiers should be for the full SOLAR spectrum. Using LBNL WINDOW to get good estimates for these values is what I would recommend.
