I want to test a workflow of a Daylight analysis with the new LBT, with a “not simple room” model, and I found some points that are a bit unclear for me.
In this case I took a large building and recreate only the Atrium and the outside building fasades.
The first problem I encountered is that if I want to create a HBroom of the Atrium, I run into this error: “Volume is not closed”, but I’m sure it is.
The component tells me to preview the output to see the holes, but nothing is shown. In this case, can a room be generated, or do I have to go directly to creating everything with the HB_Model component?
If I connect the surfaces directly to the _HBModel, seems to work fine, but I encountered a problem with the _VisualizeByType (when connected with the _HBModell), which does not divide and show my surfaces correctly in the categories like floor, wall, etc.
Another little questions:
If due to a construction error in Rhino, HB does not generate the openings (because when the openings are not perfectly planar to the walls, the aperture are not generated), would there be a quick way, to see which aperture´s surface aren´t recognized?
what should I do? Create an apertures on both walls (as in the screen), which I think is incorrect because it would calculate the window trans value 2 times, or create the whole frame of the wall, and insert the glazing as a single surface (how the 2nd screen) and lose that the model is closed volumetrically?
If you are getting a warning about the room volume not being closed, this is because the PLANAR representation of the room that is going off to Radiance is not closed, even if the CURVED Rhino Brep is closed. Passing the solid Brep geometry through the “HB Planarize Brep” component will ensure that the solidity of the Brep is preserved as part of the planarization process.
Also, when the component is telling you to “preview the output to see the holes”, it’s recommending that you connect it up to a “HB Visualize All” component and/or Bake it in order to see exactly how the geometry has been translated into a planar Radiance-compatible format.
I can add a warning in the “HB Add Subface” component that tells you the apertures that have not been assigned to any parent Face. I can see this will be very helpful in catching errors. I’ll do this soon.
You should model your situation volumetrically and not like your first example. There’s a way of modeling this specific case volumetrically with closed Room logic and a single aperture assigned to the Room envelope. If I get your geometry, I can put together a sample that shows it if it’s not clear. Also, unlike energy modeling, you don’t have to use the Room logic in your Radiance model if you don’t want to. The only Radiance recipes that will actually make use of the Room logic are 3-Phase and 5-Phase, which we don’t have yet. But, if you think you won’t be running those types of studies on your Model (or running the model through EnergyPlus), then you can just model the aperture as an orphaned aperture and the rest of the room geometry as orphaned faces.
I just added a warning into the “HB Add Subface” component for the case that surfaces are not matched with a parent Face:
I will try to take a look at your geometry when I can but, if you’re only running DF, then it’s more work than it’s worth to build your model with hierarchical relationships. You can just keep your model flat (the first option that I describe here).
As long as geometry represents walls, roofs, or floors, you should model it as a Face since Faces get their default modifiers assigned based on their normal direction. Granted, if you are overriding the modifier anyway, it doesn’t matter much. But anything that’s not a wall, roof, floor, aperture or door should be modeled as a Shade (including indoor furniture, exterior shades, surrounding context like trees, etc).
however the _VisualizeByType component, still does not show me the various categories in a suitable way, if it has the HBModel as input.
a little question only for my knowledge about this quote:
For simulation purposes, what changes between a HBfaces and an HBaperture, if they have the same Glass modifier? Same speech between a Face and a Shade, with the same Opaque Modifier?
Is it just a way to better categorize the surfaces, or does it affect the simulation result, p.e. of a DF analysis?
If you let me know what specifically is wrong, I can investigate.
To answer your question, you are right that there are a lot of Radiance study types where the distinction between Face and Aperture doesn’t matter since you can override the Radiance modifier of any object to be whatever you want, whether it’s a Face, Aperture, Door, or Shade. So a Face and an Aperture with the same geometry and modifier in a daylight factor study are virtually equivalent. However, it becomes important to choose the right object in the following cases:
Dynamic geometry - Admittedly, we don’t have any recipes yet that handle dynamic geometry like dynamically tinting windows, roller shades/blinds, trees that change transmittance with the seasons, or ground surfaces that change reflectance with snow cover. But all of these are coming soon and it’s important to choose the right object type for these cases since the only objects that can be dynamic are Apertures and Shades. Faces (that is, walls, roofs, and floors) must always be static. This is intentionally done since you have to compute the contributions of each dynamic geometry group and each state of that group separately. And you usually need to do it differently for openings in building envelope Faces (aka. Apertures) than you do for things that are completely outside or inside the building (aka. Shades). So Apertures and Shades have properties for assigning dynamic groups and each are slightly different for the way these dynamic geometry elements are computed.
3 and 5 phase studies - This is another case you’re computing relationships and contributions. So again, you need to pick the right object type.
Combined Energy and Radiance models - I guess it goes without saying that you need Honeybee Rooms in order for a model to be simulate able in EnergyPlus (orphaned objects cannot be simulated there)
Hopefully, this clarifies the use cases where the distinction between objects is important.
Actually, I see what you mean about orphaned Faces, and Apertures not showing up in the visualize components. This is primarily because the component is meant to take _rooms. I’ll look into whether I can change this to _hb_objs to support all of the different types of objects.
thanks for the clear explanation about the geometry categorization, based on the matrix simulation.
About this, thanks for the add.
As you wrote, now I see a warning message, with the ID of wich aperture are to be fixed, but is there also the possibility of having them displayed in Rhino? Otherwise is difficult to understand their position.
even here, thank you for taking this change into consideration.
But after updating the components, unfortunately still the surfaces floor/wall/ceiling, etc, (unless they are grouped in the HBroom component), are not displayed by the _VisualizeByType if it is connected with the _HBModel.
I have tested either with orphaned and child faces.