Hi @devang
Hope you’re well.
When using honeybee-3DM to generate test points, I was wondering if you knew a way to preserve the order of breps in Rhino layers so that the test points follow a consistent data structure?
Basically I’m stuck on Grasshopper because generating large number of test points saturates, although the data tree structure is consistent, while when using honeybee-3DM I don’t have GH limitations but I can’t have consistent data structure.
Best,
Olivier
Hi @OlivierDambron, Can you name the breps/sensor-grids and re-structure them back when reading the results? I don’t know if we export the name for each Brep but that’s something that I imagine is straightforward to implement.
Hey @OlivierDambron,
If you can share a small sample file and a note on expected behaviour, I can look into this.
Sort breps by centroids x, y and z should preserve your order.
Hi @mostapha , @devang and @Mathiassn
Thanks for sharing your thoughts.
For the purpose of testing, please find here a small sample file. The logic will serve to process urban areas nearly 50 times larger. I’ll try to clarify as much as possible:
Intention:
The data structure I’m trying to preserve on Grasshopper is the following:
[ Properties [ Buildings [ TestSurfaces/SensorGrid ] ] ]
Each property can hold 1 or more buildings.
Each building can have 1 or more test surface
I’m trying to compute Direct Sun Hours on the facades of buildings and to be able to query results for a given Property by looking for a path.
Options 1 :
I’ve managed to do write and run a medium size simulation on Grasshopper.
I’ve decided to flatten all test points to generate only 1 sensor grid, read the results and match their data tree structure back. This saves overhead time (which can be really huge) linked to the decomposition of all grids into subgrids, and facilitates the settings for optimal sensor count (nb of sensors / nb of CPU).
The problems comes with large scale simulations, Gh becomes the bottleneck with a lot of waiting time between clicks to generate test points. The definition becomes hard to handle.
Option 2 :
Using Honeybee-3DM could help bypass Grasshopper limitations.
@devang, following @mostapha’s strategy and @Mathiassn’s logic, would it be possible for honeybee3DM to generate only 1 sensor grid for all test surfaces within a single layer?
And generate a list (csv or else) of number of points generated per surface?
That way I can restructure the results accordingly in grasshopper.
I attach here a sample file.
Sample_Urban_DataStructure.gh (1.2 MB)
Thanks so much to all,
Olivier
Hi @OlivierDambron,
I am going to only focus on the honeybee-3dm part here.
You need grids per layer. If a layer has 5 surfaces, there will be 5 grids, but you want those 5 grids separated from other layers. So it would be
Layer1 = grid1, grid2, …
Layer2 = grid1, grid2,…
The information on the grids can be csv files or something else.
Is my understanding correct?
hi @devang
I’m trying to avoid having multiple grids because of the overhead time it takes to decompose and recompose.
If I can :
I will be able to reconstruct my results following the logical data structure.
Thaks for sharing. I will work on this.
Hey @OlivierDambron,
I created support for what you want to do here on a separate branch on my fork of honeybee-3dm. Please follow the following steps to get a local version of honeybee-3dm with modified behaviour.
pip install -e . This will install a local copy of honeybee-3dm from step-1. Let’s call this honeybee-3dm-olivierHoneybee-3dm-olivier has following changes;
Let me know if you face any issues.
hi @devang
I wasn’t able to install it properly
I’ve tried manually and via Github Desktop as well. Don’t know what is missing.
Sorry about that.
Can you please copy the link from the olivier branch on my fork and clone it locally using github desktop or any git interface?
pip install -e .
I did exactly that and ran onto the same issue.
it seems that the clone works for honeybee-3dm not the olivier branch.
@devang
I’ve run a test and it seems to generate as many csv as number of items(surfaces) inside the “grid” layer.
One sensor grid per layer, seems great. I guess it is within the HBjson.
Sorry for not having been clearer, what I was trying to get is :
a single CSV that is a list of lengths of the list of points generated per surface.
This is what honeybee-3dm-olivier returns so far. I’ve annotated what I’m looking for
Essentially,
for each items in layer “grid”,
count number of points generated,
append length to csv.
Perhaps you see an easy way to implement this, otherwise I can always try to write a python script that counts the length of all csvs into 1 csv.
Hey @OlivierDambron,
Glad you were able to build it. It’s good to have your feedback.
It should be in the generared hbjson. You can use this
or any other json viewer to check the number of grids in hbjson and their identifiers.
I will update honeybee-3dm-olivier.
hey @OlivierDambron, I updated olivier branch of my fork. If you keep grid objects on separate layers, you’ll get one sensorgrid per layer in hbjson (This was already implemented in the last iteration), and one csv file with three columns; Layer name, Object name, length of sensors in the object.
hi @devang
Thanks,
I’m encoutering an error, it seems that “data” is assigned prior to being declared:
It should not happen. Can you share your file and the config file?
