Some questions about how to set up a Radiance Model, for a "not simple room"

Dear @chris,

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?

  • If I have this situation


    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 so, which procedure should I use?
    Set the glass as aperture, without a subfaces parently with the wall, and put directly in the _Apertures input of the _HBModel?

I hope you will have the time to response.
LBT-notSimpleRoom_v2.gh (305.4 KB)

as always, greetings and best regard.
Liam

@LiamRuvio ,

There’s no geometry in your GH file so I can’t see your specific issues:

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.

Sorry dear @chris,

I was convinced that I had internalized everything:
LBT-notSimpleRoom_v3.gh (555.2 KB)

Another doubt, the outside surfaces of the building, can I import as normal _Faces or as _Shades?
P. S., I will run a DF simulation. It is not for a energy modeling.

Thanks for the time.

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).

Amazing @chris,
thanks for the add!!

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?

Thanks and many greetings Chris

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:

  1. 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.
  2. 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.
  3. 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.

I added the ability to plug any _hb_objs into the “Visualize by Type” and “Visualize by BC” components:

So you can now use them to see the orphaned objects just as you would for objects making up rooms

1 Like

Dear @chris,
thanks for the clear explanation about the geometry categorization, based on the matrix simulation.
Very interesting!!

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.


am I doing something wrong?

I used part of your example model for testing the new add.
VizByType_model_creation_workflows.gh (52.0 KB)

Greetings
Liam

@LiamRuvio ,

Your components are not updated. The new components will have a _hb_objs input instead of a _rooms input:


VizByType_model_creation_workflows_CWM.gh (52.5 KB)

You should probably assign a _name_ to your apertures to make them easier to track. But, if you want to get the geometry of any object using its ID, you can just use the following components:

Dear @chris,
sorry, but yesterday with the _LBVersioner, hadn’t updated the component, yes this morning…strange!!

thanks for all your patience and your help!!
Greetings, Liam