I am running an annual irradiance simulation in HB 1.4 and the mesh mapping of results is different depending on how I group the sensor grid geometry. I think this is a bug, but I’m not certain since I just started using V 1.4.
When feeding multiple geometries into one Sensor Grid, the result is as expected:
The cumulative annual results are the same in both runs, so I believe the simulation is running correctly. It’s just the way that the results are mapped to the mesh that is incorrect. Does anyone have any advice or insights?
Hm. Are you sure that you just aren’t witnessing Radiance’s stochastic behavior here? Does this issue persist when you use better Radiance parameters? Also, does the order of the grids coming out of the “GetGridsViews” component align with the grids going into the “AssignGridsViews” component?
@chris Thank you for your reply. I’m fairly certain that this is a mapping issue and not the inherent variability of stochastic simulations. I’ve run these simulations many times using the two different methods and each time I come up with the same results (within 0.004%). I looked at the grids, as you suggested, but the input grids and the output grids are in the same order.
I also tried using higher-quality Radiance parameters but that also had no effect on the results.
I’m attaching the gh file. I’d appreciate it if you could let me know if I’ve done something wrong or if the mapping is a bug. annual irradiance grid mapping bug.gh (92.7 KB)
So each gird’s results are overwriting the others.
I’ll say that we wrestled a lot with implementing something to prevent this case (eg. adding unique IDs to the end of the grid IDs) but several people convinced me that it was more important to respect the _name_ of the grid when you input one. So just disconnect your _name_ and use the default auto-generated IDs. Or plug in a list of 8 different names for the _name_ input.
@chris The screenshot you show (with all grids named “all”) is the set of grids that actually returns the correct mesh mapping. The girds are incorrectly mapped when I break them up into West, South, and East groupings (see screenshot below).
Following your advice, though, I disconnected the “West”, “South”, and “East” names, which automatically generated unique names for all grids. This resulted in the correct mapping. So I guess we can use one name for all grids or one name for each grid, but we can’t use different names for groups of grids.
Automatically adding unique IDs to the end of each grid ID would have solved this glitch. Thanks so much for your help!
So they are both at risk of certain results overwriting the other. I guess you just got lucky when you named all 8 grids with the same name.
But long story short is that the grid names need to be unique if they are to be matched back correctly. Maybe I’ll raise an error before the recipe runs whenever I sense that the full identifiers of grids are duplicated. @mostapha , would you be in favor of this approach (I would essentially work the check into the handler)? I remember you mentioning, that there were some edge cases where you might want to use the same grid ID but I’m guessing that they don’t really come up in the current honeybee-radiance recipes, right?
I am kind of having the same issue. I solved using the grid component. However, I have this question. I have a list of zones on the ground floor and a second list of zones on the first floor. I want to combine these two lists in 1 list with 0 (0;0, 0;1, 0;2…0;8 zones on the ground floor) and 1 (1;0, 1;1, 1;2…1;4 zones on the first floor). But if I merge them then, the items with the same number they are added to each other.
How is this working? Thanks!
Welcome to the world of Data Trees and one of the hardest Grasshopper mechanics to understand. To get what you want, you’ll have to use the native Grasshopper “Replace Paths” component to change one of the two data trees to have branch numbers different from the other. For example, you can change the paths of that lower data tree from
