I am trying to elaborate a Ladybug-based pipeline of an assessment of solar radiation while working with a city-scale models in a hilly context. I have tested several tools for this task (ArcGIS, GRASS GIS), and reviewed a bunch of papers, where MATLAB or PostGIS routines are implemented. But Ladybug and Rhino look much more visually appealing and flexible if one needs some local adjustments. Finally, I came up with an idea of using various scales of shading context objects and calculated geometry. Here are the components of this pipeline in my case (exact parameters may be changed):
a large low resolution terrain (mesh) needed for a shading (70 km * 70 km) with a hole for a detailed terrain, 811 000 faces
a high resolution terrain (mesh) for a detailed context (1300 * 1100 m), 195 000 faces
3d buildings (1300 * 1100 m) as a shading context
3d buildings within 3) (400 * 300 m), 2m cell, meshed with LB Incident radiation, 56 000 faces
Pictures are attached.
I have tried LB Incident radiation (yes, I know the difference between LB and HB radiation results) for one year with 2 m cell size and it works pretty fast! I am planning to process main built-up areas with such a method and export results somehow back to PostGIS.
However, I have a few questions:
Dense meshes for calculations: what is the number of faces that can be processed without freezing if I have no access to Pollination yet? It seemed to me that a calculation totally dies with a number of faces higher than 500 000 or 1 000 000 and nothing happens for hours (I have been waiting for a calculation around 8 hours with 90% of 32 gb RAM).
What is the most consuming part of a calculation? Maybe some kind of Sky view factor or a Sky mask? I didnât noticed a big difference in a time between yearly radiation and monthly values. In ArcGIS âSVFâ is a most consuming process.
How the complexity of shading objects is affecting calculations? It seemed to me that even large shading meshes work fairly fast
LB Sky Mask - can I use it instead of using Terrain shading mask by Gismo in order to get a shading context of mountains? In Gismo I have no access for the initial geometry of terrain.
Processing separate faces instead closed Breps - is it ok? For example, I would like to get results only for facades within a certain orientation (aspect). It should reduce a calculation time dramatically.
1/2/3. LB uses Rhinoâs ray-mesh intersection methods. If you double click the LB incident radiation component it will open up the python so you can see whatâs happening behind the scenes. My understanding is each point generated will then be tested for mesh ray intersection with all the context geometry, with each ray being associated with the number of rays in your sky dome. I guess that Rhino does the intersection calculation based on each mesh face of context geometry, so thatâs how context complexity factors in.
Hopefully that gives a bit of an idea of how the simulation scales based on context geometry and the number of faces youâre trying to calculate for. Afraid I donât have numbers to share, but you can do some simple tests to see how it scales. Essentially this calculation is a sky view factor equivalent.
HB is supposed to scale significantly better for large amounts of geometry. It also lets you set up sensor grids in a way to extract results much more easily pick, choose, and combine results.
Iâve seen some really impressive large scale sky view factor analysis using GIS, but Iâm not a GIS user. I think my colleague has used python apiâs for GIS and the ladybug tools code to combine SVF with LB sky dome to do the kind of analysis youâre looking for, potentially an extra route to consider if you havenât already come across that.
Not sure on, Iâm not familiar with Gismo
Absolutely ok - you just need to make sure surface orientation is correct. If you start from closed breps and then explode them it should maintain the correct surface normal (ie facing out).
Thanks a lot for such a detailed answer!
I thought LB Radiation deals with shading context similar to HB Shadow calculation, that has two options: PixelCounting (works faster) and PolygonClipping. I will try to clarify this point for myself.
HB does nice things with HB Face Attribute and thatâs seems useful for selecting appropriate objects in the urban context before a calculation starts. In addition it could be a good starting point for preliminary energy studies.
Linking GIS with LB or HB sounds interesting! If there is any public available information, it will be much appreciated! Grasshopper and LB provide much more flexibility when it comes to 3D, but maybe I have missed something.
The HB shadow calc methods are part of the energy side of HB (using energy plus).
For radiation analysis Iâd recommend to look at the HB radiance methods, which uses Radiance and is then another can of worms to understand
In terms of doing some GIS / LBT python approach, I had a quick look at some GIS methods I think potentially that would only work in plan and not provide the facade analysis youâre looking for.
Charlie,
Thanks for clarifying! I have definitely to go through the entire process of HB-E as well (switching from Archicad Ecodesigner).
Just in case:
here is an example of the PostGIS-based approach, when facades are evaluated in 3d: mediaTUM - Media and Publication Server This approach is reproduced in other research papers.
Besides ArcGIS (it is very expensive and less flexible while working in 3D), PostGIS is used to perform a ray-casting method similar to LB in 3D. There are some cases where calculation lasts for days using servers, which doesnât seem to be optimal ( A Scalable Approach for Spatio-Temporal Assessment of Photovoltaic Electricity Potentials ) But I havenât come across a method based on LBT for the city scale or taking into account a large shading context at least. So thatâs my current research question.
I found when I was doing large scale SVF calculations I found chunking the meshes and farming them off to hops instances sped things up significantly and utilised more of the available CPU power.
Also, if your RAM is at capacity it will crawl. I never ran out of RAM for SVF calcs, but I have for direct sun analysis where 32gb wasnât enough for some of the studies.
Could explain a bit how do you chunk meshes with graphical examples? Do you proceed with the same concept of a study mesh in the center and a shading context as a buffer (as it is shown above)?
Thanks for the hops, I will check this out.
I have tested various conditions and had a look at the code. If I densify shading objects, there is almost no effect on calculation time - maybe Rhino MeshRay method, used in LB, works very fast with mesh intersections.
As it seems to me, the sky matrix resolution is the another key component which impacts calculations, not a resolution of shading objects.
Everything could be clear except the resulting resolution of a sky matrix and where it is obstructed. The Sky Mask component doesnât seem to be the one is used in the calculation itself. I have compared resolutions of sky domes (Tregenza, Reinhart, Sky Mask). It is interesting that Tregenza should consist of 145 patches, but in reality Incident radiation component uses its high resolution version (1314 faces, there is a description in the code), but it calculates ~4 faster than the Reinhart Sky matrix (588 faces).
The resulting sky matrix coming from the Incident radiation shows 290 values for each point. The Sky Mask gives a dome 1296 faces by default.
So I am not sure about how to derive an exact sky mask used in calculation and visually check it. This can be critical while estimating a large hilly context.
Hi @eshirinyan, I think itâs a really good point. Iâve struggled with the sky matrix and mask logic before. The int_mtx output from LB Incident Radiation is the key for what you need.
This is a very rough attempt at a visualisation using vectors. Unfortunately not a sky mask - if you work out how to make one please do share. I think this would be valuable functionality (ie sky mask from an int_matrix). Sky Mask Radiation Visualisation.gh (43.7 KB)
Iâve added a sky mask in there to see what can be achieved with the current components, the issue is the patches from the sky mask donât align with the sky dome
Sky Mask component is not linked directly to the calculation itself, as we have discussed above
If Tregenza Sky dome is set, patch vectors are a bit misaligned with the resulting dome. And we can see that the matrix with 145 patches (x2 for full sphere ?) is not sufficient for complex urban scene. But I donât get it why LB uses a highres version of Tregenza - just for viz purposes?
If Reinhart Sky dome is set, we get all the vectors aligned with patches.
Finally I have tried to get the real sky mask using Mesh Ray intersection.
in 1.6.0 there is an output from Sky dome as âvis_setâ (I have been used 1.5.0) but I didnât find anything interesting.
It was quite useful to me to enhance my understanding of some Grasshopper basics, thanks to your definition.
Thanks for sharing @eshirinyan, very useful to know that the Reinhart sky dome mesh faces / patches aligns with the vectors - I really like the middle image youâve produced, itâs a nice visualisation of the Sky Mask at that point.
Before starting a chunking process I have been tried a large size model ( about 30x30 km for a study mesh). So LB Incident Radiation will process it as one mesh, if meshes are supplied in a list without grafting
.
There was a trick to avoid bad polygons or very small polygons comparing to a scene size - I have calculated Minimum oriented bounding box for each building and converted it to a mesh in Rhino. Thus I get only one calculating point per a roof. Then I have added walls triangles as well. So the resulting faces count was about 1 300 000 faces. With Tregenza sky (145 patches) it took 1000 sec. With Reinhart (577 patch) it will freeze, I suppose.
