algorithmic modeling for Rhino
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?
Replies are closed for this discussion.
I'm interested too
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.
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.
this is a great upgrade!
I am working with complex urban geometries and it could help so much the workflow!
That sounds great, Im looking forward to put my hands on it.
Good to see this one getting handled Chris!
It will be of great help as we both know how time consuming this step can be.
definitely, this would be super helpful.
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.
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?
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.