I am trying to run a radiation map simulation in order to obtain sensor data (i.e. kWh/m2) for building roofs and facades in an urban context. I am trying to run these simulations for multiple buildings/geometries at the same time (e.g. multiple roof geometries or multiple facade geometries).
My issue is regarding a daylight grid error: "1. Solution exception:Index was outside the bounds of the array."
i. I have noticed that when I reference fewer surfaces for Brep, I do not get the error. However, then I am only able to reference a few surfaces at the same time (i.e. 1 to 10, there does not appear to be a surface area maximum/pattern)
Also, regarding a warning: "1. reducing spacing to adhere to maximum sensor count"
i. I have also attempted to change the spacing by connecting a value greater than the default 0.45m for the spacing input for the daylight grid, but this does not seem to resolve the issue.
Should I be able to connect more than 1 to 10 geometries to the daylight grid? I would like to select all of the roof geometries if the software is capable of computing all of that at once.
Why doesn't the spacing change (i.e. visually in Rhino) for the grid spacing setting when the value is changed using the daylight grid?
Also, why don't some surfaces compute a value for the kWh/m2 output? Even when I run smaller batches of geometry in Grasshopper, some surfaces are not capable of producing results even though they are not, for example, in an area where shading would cause the output to be 0 kWh/m2.
I have a SketchUp file that I have imported into Rhino 5.0 and I am using DIVA 4.0 + Grasshopper to setup the simulation. I have replaced the roof geometries (i.e. the existing meshes that were imported in from SketchUp) with the PlanarSrf tool in order to have geometries in Rhino that have fewer lines. I should also mention that I am currently using Parallels to run Rhino on a Macbook.
Many issues here.
1) Meshes will not be subdivided by the Grid component -- only surfaces.
2) The spacing warning is not a problem, per se. There is a limit of ~5000 grid cells per surface, which is mostly there to prevent you from crashing Grasshopper. If you really need more, you can break up a surface into multiple faces -- but for this model I don't know why you would.
3) Many of your surfaces are facing the wrong way. You can check orientation in Rhino with the "Dir" command (and then "F" to flip).
4) The Grid component sometimes does a terrible job with trimmed surfaces, and needs a little hand holding. Specifically, if the Rhino document tolerance is too tight or too loose, you may see the following issues:
Too tight (tolerance = 0.001 inches):
Too loose (tolerance = 10 inches):
Just right (tolerance = 0.1 inches):
(You need to re-input geometry into the Grid component for the tolerance change to take effect.)
5) As it stands, you are not including any geometry in the simulation. If you want shadows to be cast on the analysis surfaces, you need to input the grid surfaces as physical surfaces (with materials attached), and also include the non-grid scene geometry.
This is very helpful, thank you!
I have a few follow-up questions:
1. Is there a way to turn the meshes into surfaces? I noticed the MeshToNURB tool, but is the open polysurface object type compatible for the simulation? Or do the meshes have to be replaced with surfaces using a tool like PlanarSrf or redrawn by hand? Can something be done during the importing phase to ensure the SketchUp file imports surfaces rather than meshes?
4. For the non-grid scene geometry, does that geometry also need to be represented using surfaces for it to be included in the simulation? I assume yes, but I want to double check.
1. Polysurfaces are fine. Don't remember the SketchUp import options, but wouldn't be surprised if there was an option like this.
2. No, meshes work.