Recently, I had to run a daylight analysis for exterior areas and i was able to run the simulation perfectly fine and get the results. So, i started wondering why we need to create analysis models at all.
While working on live projects, this step (creating analysis models) always becomes an additional step and is always time consuming. Even though the pollination plugins are really helpful, they still require some clean up of the models whether in Revit or Rhino.
I ran a quick test.
Valid Honeybee Model (Closed)
this is a sample honeybee model with glazing on all 4 sides and some columns as shading elements.
This model has a random room, not needed for the analysis, and the rest of the things modelled as rhino breps as shading geometries ( includes both closed and open polysurfaces )
The results are as below. The lux levels for the hacked analysis model(open) are almost double the normal analysis model. I assume this is because of the default glazing properties in the construction set.
@chris@mostapha What are your thoughts on this workflow ? What would be the pros and cons of using this hacky method? This definitely saves a lot of time on projects.
we dont even need a random room to create a valid HBJSON model. Just a bunch of shade geometries creates a model and the simulation is run successfully.
I think I’m missing your point - I haven’t opened the script but both models look legitimate to me, and the results from each reflect how they’re set up with the glazed version giving lower values.
I think what you’re showing is intended functionality unless I’ve missed the point.
You can use rooms in a daylight simulation but they are not required. Both models are valid but the model without a room cannot be used for energy simulations.
If the HB Validate Model component or the PO_ValidateModel command is telling you the Model is valid, then you can assume that’s the case. So you don’t need Rooms for a valid model.
Granted, a Model without Rooms is not simulate-able in EnergyPlus and there can sometimes be advantages to setting up your Daylight simulation model with Rooms. Notably, making sure that all of your Rooms are closed volumes will prevent light leaks in the Radiance simulation. Also, using Rooms of closed solids essentially absolves you from having to check the normal direction of Faces to make sure that they’re correctly assigned as Floor/Ceiling (and are getting the correct corresponding reflectance for floor vs. ceiling). This is because Honeybee Faces of closed Rooms always point outwards from the Room volume, enabling the default assignment of Floor v. Ceiling by normal direction to always be correct.
But there’s no hard in fast rule that you need the Rooms to make the Model valid or to be able to run Radiance simulations with it. So there are many cases where it’s just preferable to take the “orphaned” geometry (that is, the Shades, Apertures and Faces without a parent Room) as they are.
We even have some future Radiance workflows planned that are optimized towards this “orphaned” workflow where you can represent detailed Radiance geometry with Meshes instead of individual planar units. You’ll know when these are being implemented when you see this issue close:
I understand that you need Honeybee Rooms for energy simulations.
But coming back to daylight simulation with radiance, what I understand from Chris’s comment is that for daylight simulations, since we have reflectance from ceilings, floors and walls, we should still work with creating rooms when probably the project is a bit more developed and we are thinking about materiality and reflectance values.
But, in early stage design, where we are running parametric studies which are more geometry based rather than material based, we can go with the " orphaned " geometry model, where we define the entire geometry as shade elements and create a test surface for sensor points.
I hope I have understood your comments and the workflow that I am proposing is valid.
It is still not necessary to use a room-based model at this stage. However, you can set up the default modifiers in a room-based model with a ModifierSet, while still being able to overwrite the default modifiers when creating the Faces, Doors and Apertures. But to address your concerns: yes, the workflow you are proposing is valid.
On the question about room-based or non room-based models, I just want to add that for more advanced stuff like aperture groups or 3-phase simulations the model must be room-based.
Hi @chris
Regarding the HB Validate Model component , I am getting a constant traceback error when I run the component. The Daylight model simulates but I suspect it is not accurate as I get different results from my colleagues , even though we use the same script with the same parameters. This has happened across multiple different models
Do you know what could be the error?
Thanks in advance
What Mostapha said.