Storing IndoorViewFactor viewFactorInfo

Hi All,

I’m working on a masterplan looking at the outdoor comfort performance of its streets and pavements.

I’m using the Honeybee microclimate map tools as the basis for this but wondered if there’s any way of reusing the viewFactorInfo without having to recalculate every-time I open the GH file.

For a sense of scale I’m trying to determine the view factor between approximately 30000 points and 450 surfaces - which (according to some wild extrapolation) would take around 2.5 hours on my machine to calculate.

I though of perhaps writing the viewFactorInfo to file to reload - but as its stored in IronPython.Runtime.List format this is proving a bit more difficult even with Giulio’s handy conversion script.

Does anyone have any other suggestions about how to either speed up the calculation process or serialising the output to re-load later?

1 Like

I’m interested too

Hi there,

definitely, this would be super helpful.

+1 interested

Another useful option would be to allow input of a specific mesh from which to calculate the view factor.

This way we could try to mesh in detail where we need it (near shading elements are areas with interesting air movement patterns) and less detail elsewhere.

This is already possible. You can create your custom ground by dividing the top face according to your needs.

Could you explain that a bit more?

The way the component currently works uses the gridSize input to specify overall mesh edge lengths, created within the viewFactor component. I assume this is then used to create a mesh and obtain face centre points from which the view factor is calculated.

I’m wondering if there’s a way of providing the actual mesh, or a list of points from which the view factor could then be determined.

Something like how snappyHexMesh creates an adaptive mesh around components for CFD - where finer resolution is required as opposed to large areas of the domain where there’s no need for such fine mesh.

Is there another method I might have overlooked?

Tristan and Federico,

This is a very good question and I have had a few people ask me about this now. The capability does not currently exist but I have had this on my to-do list for a while with these github issues:

I’ll aim to have this implemented by the next stable release, which is in a couple of weeks. The way that I plan to implement it is through the dumpHBObjects and loadHBObjects components that are currently in WIP. This will allow you to write both HBObjects like zones and surfaces to a file as well as the view factor Info. So you can store them in these external files and load them up later or in other GH definitions where you want to visualize different results (or run different microclimate map studies).

I’ll post back here once it is implemented.

Thanks for the reply Chris.

That sounds brilliant! Will that be an XML/JSON serialised version of the objects? If so I can see lots of potential for processing outside GH in pure Python.

Keep up the good work and I look forward to playing with it when it becomes available.

Hi Tristan,

it’s very simple, easier than you think.

Just create the surface that you want to simulate, with your custom subdivisions, join every trimmed surface in one and create the sides and the bottom of the ground zone, in order to have a single closed brep.

Set it as “ground HBzone” and connect it to viewFactor component setting as grid size an high value (for example 100 meters), in order to have a single point for each face.

Hi Tristan,

Unfortunately, the easily-achievable goal that I am working towards right now will output the HBObjects into a binary file and will use python pickle to do so. I would really like to enable the serialization to something that is text-readable like XML or JSON for all of the uses that you reference. However, this may be difficult for the current (legacy) version of Honeybee that is deeply intertwined with Rhino objects. Needles to say, this is something that we are keeping in mind for Honeybee-Plus and I am positive that we will support serialization to these formats at some point in that version.



Federico’s suggestion of a subdivided polysurface into the _distFromFlrOrSrf input should give you the control that you need for the time being. I realize that it’s not much work for me to add the ability to plug in your own custom mesh to the _distFromFlrOrSrf input. This will just make the component a bit more flexible and I’ll try to implement this when I add the functionality to write the viewFactorInfo to a file: