I have run an annual indoor comfort analysis and I am trying to display the results with the visualize annual results component.
However, 2 of the 3 zones are displaying the results underneath the floors. Do I have to flip some surface? Or is it a cplane issue.
Baking it seems to bypass the problem as the meshes become visible. But it’s still annoying.
I’m sure I’m doing something wrong at some point. Can’t really upload definition as it is a really demanding file to run.
Theodoros, Attaching the file is always useful to help. Hard to say otherwise …
Long night. You are right of course. You can find the file in this discussion.
After updating from github I now can’t create the recipe. In the preview of the factor mesh it is obvious the surface of one zone is completely screwed (i.e. like upside down). The comfort recipe component is giving factor mesh info not recognised error.
I am attaching the definition. Thanks!
OfficeTower.gh (424 KB)
Well … not good news from here.
I updated the file to the very last github components. The HB_IndoorViewFactor is failing with 1 warning and 1 error:
Getting rid of interior walls has caused the connected zone geometry to not be closed. Try connecting all zones of your building or all zones for each floor.
Solution exception:name ‘testPtsInit’ is not defined
The simulation is taking a lot and the results file is pretty big (~200Mb).
The component i connected for the EP simulation and IndoorViewFactor is the EPWindowShades (as opposed to those you have). Seems to me more correct. But still … no success.
I have not had time to check the file yet but it seems like there may be a bug and I will look at it soon. The first part sounds lime a known bug in the Grasshopper preview:
Hi Chris and Abraham,
Thank you for your replies.
Ye it’s a big file, surface and zone data for the whole year. The shading reps are there so I can check the impact of vertical shading on the building (linking it on and off).
I managed to actually make it run now. One of my zones had a double surface on the one side. I found and closed the brep. Not sure if that was the case but at least now it runs. The preview is still bugged though. I tried to check the normals but didn’t work (changed all normals and problem is still there). Baking does bypass it as all I want is to visualize and save a .jpg for now.
Thanks for all the help!
Once I removed the zone that was not closed in your file and I updated your view factor component to the latest version, all seemed to be good.
I think that the preivew issue that you mentioned is the same as the bug that I posted about on the general grasshopper group (see the link). Hopefully the GH team will fix it in their next version of grasshopper. As the thread says, you can temporarily fix the problem by turning off the breps previewing in the Rhino scene.
A note about shading in the comfort map: if you add shading into the E+ simulation, you should be sure to either drop down the transmissivity of the windows in the Adaptive Comfort Recipe component or plug in the shadeBreps of the Window Shade Generator into the additionalShading input of the View Factor component (the latter is more accurate but it takes the view factor component longer to run). Doing either of these will ensure that direct sunlight falling on the occupants is minimized in the case of shades. Here’s how your image changes when you account for the shades blocking direct sun on occupants:
See attached GH file.
OfficeTower_CWM.gh (711 KB)
Thanks for the advice. Can’t believe I wasn’t accounting for the shades in the adaptive comfort matrices. I guess I thought since they were plugged in the EnergyPlus it was ok. I’m going to redo the simulations now then.
I do have another question though. How do you think I can manage to put shading devices in glazing with curved geomtry? Would it be possible to use a component and somehow create a single, linear geomtry infront of the window to put the shading devices? If not, do you have any advice on the transmissivity values I can use for those 2 windows in order to ‘simulate’ their existence?
Thanks alot for the advice!
Have a nice day.
I have a couple of questions regarding your recommendations here above.
windowTransmissivity: Can i assume that if i give a value (for instance 0.8) it means that the blinds are covering 80% of the window? This is what i understand from the hing in the input, but want to be sure.
The HB_Zones coming out from the EPWindowShades is connected to the runEnergySimulation. The HBZones connected to the IndoorViewFactor come from each individual zone with outdoors facades. Then the output coming from EPWindowShades is also connected here. Are not the shades taking into account twice in this way? Once for the EP simulation and once more for the comfort recipe? I find this a bit confusing … Just want to understand the logic of the process and calculations.
The way I understand the concept of transmissivity is near to the one of transmittance, that is how much incident light the window allows to pass through. I am in no way an expert, but I understand transmittance is used in most glass specifications (VLT) while transmissivity is a value used in Radiance (my limits of knowledge in optics lol). There is actually an approximation of transmissivity from VLT numbers, which is transmissivity=1.09*(visible light transmittance). I feel 0.8 would be the fraction of light allowed, so it would need to be much lower to ‘simulate’ blinds (if blinds have a transmittance of close to 0). Perhaps what it can be used is the weighted average of the visible area of the window, with a transmittance x, to the area of the blinds (with a transmittance of 0?). Even if this is correct it would be faulty I think. Actually now I am curious to know what calculations are happening when we connect the shading breps. Are they assumed to have a transmissivity of 0?
For your second point, I am interested to hear Chris’s thoughts.
No way the windowTransmissivity refers to the properties of the glass/window. Those you get/give when you define the proper material.
The hint in the AdaptComfRecipe says:
windowTransmissivity_: An optional decimal value between 0 and 1 that represents the transmissivity of windows around the person. This can also be a list of 8760 values between 0 and 1 that represents a list of hourly window transmissivties, in order to represent the effect of occupants pulling blinds over the windows, etc. Note that you should only set a value here if you are using this component for indoor analysis where the only means by which sunlight will hit an occupant is if it comes through a window. The default is set to 0.7, which is the trasmissivity of the default Honeybee glazing construction.
I understand here that the intention is to combine the influence of shading devices as for the amount of sunlight that enters the space. What i see in the hint is that i can define this “coefficient” for each hour of the year. In this way is kind of Shading Coefficient for the window That’s why i’m asking.