I just want to make sure that this is the preferred methodology…as the Honeybee Glazing Parameter does not have a NORTH geometry node (like the analysis components have), I’ve been doing a “list shift” on the glazing parameter input values to assure that the glazing WWR values align with the custom north orientations that an analysis might utilize.
correct me if I’m wrong, but in honeybee, when we tell what orientation has what WWR, the geometry doesn’t know the North Orientation yet that an analysis component might use, so if we over-ride the north orientation, the two will conflict…example…you say you want North WWR to be 100% but then rotate the building 90 degrees, it will be off…
I added this list shift to my scripts when importing the list of WWR into the glazing component…hopefully this makes sense…the “A” input in the division component is the North orientation override in degrees…in this example I did a 90 deg rotation so it’s shifting the North WWR of 20% by 2 spots…so Honeybee glazing thinks it’s adding it to the East façade, but really it’s the north because the building analysis is rotated only at the analysis components.
Is this the best way to do this or is there another preferred methodology?
@chris, any insight from your perspective?
Interesting thread. Thanks.
Your workflow seems good to me. Just a remark, the 90 deg rotation is making the north towards west and not east (rotation is CCW).
The one thing you should be careful is when using the HB_rotateHBObj. Need to be coordinated when to use this component and when to set the north fix. Can be a bit tricky to figure it out.
Attached an example of what you did, in case somebody wants/need an example to understand (BTW, what is the lnc component you used? Couldn’t find it and the file works without it).
-A.
FixGlazeRatioWithNorthInSimulation.gh (487.1 KB)
good call on the HB_rotateHBObj as an option…I haven’t used that component in the past as I usually want my geometry to remain visual as is in the Rhino file, but that would definitely work as well.
The Inc is the “round to increment” component…as I only want a integer between 0 and 8 input into the list shift…for example, if the custom north angle is 25 than a list shift of -1 occurs (rounded up to -1 rather than -0.55556)…the round to increment is needed because it puts the shift in the right orientation pie as each pie is 45 deg “wide”.
awesome example you put together too…thanks for doing that!
The thing is if you use this component and want also that the glazing size will be defined according to the north definition you should define the glazing AFTER the zones rotation.
Still don’t find the Round to increment component … weird. But i think my example doesn’t needs it. Please check it works for you.
-A.
-A.
The example does work but it looked like you could only enter in custom orientations that were a factor of 45…does the basic integer component round up/down? If so, that could be used to allow any custom angle input.
The slider was edited so it takes the number and multiplies it by 45 (edit the slider to see). In case of need you can be more/less accurate with the angle. Though the list of ratio values should be addapted accordingly.
-A.
