I added a Site Context/Shade.
I found the surface was modelled as Shading:Building:Detailed in the idf file.
I think Site Shades should be modelled as Shading:Site:Detailed rather than Shading:Building:Detailed, otherwise the Site Shades rotate when the Baseline case rotates for ASHRAE90.1 compliance.
I realize that this is partly a matter of opinion but we found the EnergyPlus Shading:Site:Detailed to be problematic and misleading when we first started using EnergyPlus. So we opted not to use it in our schema as long as the schema’s primary purpose continues to be the faithful translation of geometry over to energy modeling formats. I can list several reasons why it is problematic but I’ll note the two most significant ones here that swayed our opinion:
For ASHRAE 90.1 compliance, we have some better recommendations to deal with the rotation, either by actually running the Rhino “Rotate” command or using the HB Rotate component. This way, you can specify the origin of rotation and get a visual of any geometry collisions that result. Alternatively, you could estimate ASHRAE 90.1 compliance using the Appendix G recipe that we have written, which, if my memory serves me correctly, rotates the context around the geometric center of the Model (Room) geometry instead of the EnergyPlus origin. It may not totally avoid collisions but it’s at least much less likely to encounter them compared to what EnergyPlus Shading:Site:Detailed does.
Of course, if you understand our concerns and know what you’re doing, I’m happy to help you write a measure or a component that post-processes the OSM in a way that converts the Pollination Site shade geometry into EnergyPlus Shading:Site:Detailed. This way, you could export a model with this type of shading from Pollination. But hopefully you see why we thought it was really dangerous to use EnergyPlus Shading:Site:Detailed and how it could easily create situations where people were modeling something different than they were expecting.
@chriswmackey Thank you for your reply.
I know the problem 1. When I model Shading:Site:Detailed in Rhino with our internal energy modelling tool, I rotate all the site shading surfaces around the origin (0,0,0) in advance. For example, if the North Axis of the project is 40deg, I rotate all the site shading surfaces -40deg (= 40deg clockwise) around the origin in Rhino, and export the corrdinates of the surfaces to the idf file. The center of the building needs to be the origin in Rhino.
I expected Pollination to do this process automatically because Pollination has different commands PO_AddBuildingShades and PO_AddSiteContext, but it truns out that Pollination doesn’t do so.
PO_AddBuildingShades and PO_AddSiteContext are essantially the same command, right?
For the problem 2, we don’t need to rotate the Baseline building if the building geometry collides with the context, wchich is the case of the Exception 1, 5. Building Envelope, Table G3.1, ASHRAE90.1. We check if the Baseline building should be rotated or not at the start of energy modelling.
Hey @keigonomura
Sorry for the late response here. To answer this:
Not exactly because building shade has a different default reflectance from site shade. Site shade gets the (fairly dark 0.2) default E+ reflectance while Building shades are slightly more reflective. And these two objects get different tags in the Honeybee model even if they are translated to the same E+ object.
So I agree that the workflow you mention is important and we support it through the Appendix G recipe that we have written where we identify the objects that have been tagged as site and we rotate them while keeping everything else static as we change the North. Now that you mention the Appendix G exception there, were should add a toggle input to the recipe to turn this off in the case that the exception applies. But Appendix G is just one use case of a model and the Appendix G idiosyncrasies should not govern everything that you can run with the model.
In summary, I’m just trying to highlight that it’s very confusing to ask people to set up their building geometry and their site shade geometry using different two North values (with the building on a project north and the site shade on true north). I would much rather have people set up their models using one and only one project north where all geometry is correctly coordinated. Then, if we’re running a special type of simulation where these two things are considered something different (eg. Appendix G), we can automatically treat the two different types of shades differently in Honeybee before we export them to EnergyPlus.
