In the case of a room with windows within a glazed atrium, would the 3-phase method be suitable ? If I were to assess the atrium top glazing with several xml and the room window with several xml as well.
Would there be a View and Transmission matrix within another View matrix for the same Daylight matrix?
Would it be better to divide the simulation into as many xmls I shall assess for the atrium top glazing, meaning:
Simulation 1 : Atrium xml 1—> room xml 1, 2, 3
Simulation 2 : Atrium xml 2—> room xml 1,2,3
This case is similar to a light-pipe when you want to calculate atrium to be its own matrix when the roof surface is the sender and the window is the receiver. We haven’t exposed this intermediate level of calculation in Honeybee recipes but you can use the API to create your own component or modify the commands to add this extra step to your calculation.
I remember @sarith once did some studies for light-pipes but I’m not sure if the code is on GitHub.
@OlivierDambron, +1 to what @mostapha said about a separate matrix for atrium. Unless you are doing a Daylight Factor only study, I’d suggest doing a 5-Phase simulation instead of a 3-Phase simulation.
I am doing something similar but here I want to play with the atrium top glazing only (roller blinds deployed or not based on epw hourly direct normal illuminance).
So only one window group (glazed roof) with 2 xml, and the room window are simple window surfaces with fixed properties.
Isn’t the 3-phase sufficient in that case ?
@JocelynUrvoy I think you’d be fine if your atrium is such that majority of the radiation let in through the glazing hits the walls or other contextual geometry. That will somewhat mitigate the error caused due to the Klems patches in three phase.
Current version of Honeybee[+] won’t be able to handle interior windows and by that I mean when it calculates the contribution from atrium roof it will black out other windows. This is already addressed in source code and one can overwrite the material that will be used for studies like this but hasn’t made its way to the recipes.
Thanks for this @Mostapha.
I made a quick test and indeed I get some weird results. Here is an example file testing two glazing properties (clear and diffuse) based on direct normal illuminance in the epw.
I can’t see any assymetry at all on the test surfaces and the results are the same for state 0 (clear) and 1(diffuse) of the roof glazing. The interior windows are a basic clear glass but not in a specific window group so I leave them at state 0.
Does this look normal to you ?
Current version of Honeybee[+] won’t be able to handle interior windows
Is that true for the daylight coefficient method (annual daylight) too ?
Would you recommend running the 2 cases separately (clear and diffuse) with DC and rebuild the results in post-processing (extract the results with clear glass on cloudy hours and the results with diffuse glass on sunny hours) ?
@mostapha
Hi， mostapha，I have question is that how to control 3 window with 4 states respectively and every
window has a unique control schedule .
thankyou~！
It seems that we are indeed turning the scene into black for direct studies:
dctimestep result/matrix/black_CASE…scene…default.dc sky/skymtx_…smx > mp**/direct…scene…default.rgb**
When we calculate TOTAL - DIRECT + SUN with DIRECT that was underestimated due to a black scene, we probably end up with an overestimated TOTAL. Do you see a way around it ?
I’ve been working on 2 cases and noticed something else CASE A (left ) and CASEB (right)
In Case A the black lines correspond to the window groups and blue lines to normal windows.
All blue lines were set into the radscene. The results depict that the internal windows (U glazed profile) were accounted for correctly, whereas the mid and lower windows on the facade seems to have been discarded in the calculation (noticing the red area in case A).
In Case B had to set all facade windows were set as window groups (black lines). All seem to have been accounted correctly.
Maybe this is helpful to note: When using the DC recipe, glazed surfaces in the Scene should be in radscene and all windows in Transmission matrix need to be considered as window groups. Not sure if this is correct.
I can answer this but I prefer not to confuse people for the later reference. This workflow is changing and hopefully the upcoming workflows will be much more explicit and avoid such confusions.
