However, once the breps are converted to thermal zones using the zone2Mass component, reconnecting the splitBldgFloors node on split2Floors and the askMe component will show the thermal zone information which actually not connected to it at all, and strangely the zone index number is not starting from 1 but 95, as if there are already thermal zones in the memory of HB or something like that …
Okay, on a closer look, I don’t think there’s anything wrong going on here. I’m pretty sure these are just issues caused by the way the python variables stored in global namespaces don’t correspond to the way we intuitively think a grasshopper script behaves directionally.
Some background:
The python components Honeybee is using are all connected to one single Python interpreter. The interpreter will “interpret” a python variable name according to the scope of the code written. Basically this means that, for most cases the variables in each component is restricted to that component, and you won’t have confusing things like a variable in component A suddenly be interpreted in component B.
The exception is if you add variables to the interpreter’s global namespace. Which means, certain variables are not limited to the respective component, but actually can live globally across all components.
This happens all the time if you’re coding in the grasshopper canvas, where if you don’t scope your code appropriately, all of a sudden an upstream component will magically know or reflect things happening downstream!
In actuality - everything is working correctly! But we’re confused because the grasshopper UI is a bit deceptive when it comes to python components. The visual linear flow of the grasshopper components is not an accurate representation of the way the single python interpreter is actually executing your script.
Honeybee uses a global dictionary to store HBZones data, and so that’s why this seemingly nonlinear behaviour is coming from.
So to answer your questions:
The askMe component doesn’t at first recognize the HBZone because the output from the splitBldgFloors is simply a brep, not HBZone. However once the HBZones is connected, it askMe component will look up the brep information in a global dictionary, and associate it, correctly, with the HBZones that it is defining upstream.
Again, there’s a global dictionary variable that is being used to count the HBZones number. Once a variable is declared in python, it remains in the global namespace, even if you reset your script. So I think the reason it’s starting at 95, is that it’s just adding +1 to the last HBZone you had from last time. The only way I know of starting your zones from 1 again is to recompute your solution, or restart GH.
I don’t think these issues will cause any problems. However, to be honest I am not very familiar with this part of the Honeybee code so I think @mostapha can confirm if this interpretation is correct, and advise accordingly.
Thank you very much, @SaeranVasanthakumar, for your detailed clarification. I learned a lot from your explanation.
Based on “preliminary” digestion of your explanation, I have two comments:
maybe the askMe component shall display info for its direct input component only, rather than looking up the global dictionary, or it may cause confusion.
maybe the the global dictionary variable to store the cumulative zone index shall only respond to the current GH file been operated, and it shall be refreshed if the upstream workflow leading to zone definition is changed. The overall recompute function will refresh the entire workflow which may cost a lot of time if there are computation-intensive components.
Nevertheless, these are just comments without full understanding of the internal mechanism of GH and the HB.
All reasonable suggestions, however things get complicated when you start have multiple components on the canvas. For example, if we have two mass2Zone components taking two breps, and if the zones were named only for the direct input as you are suggesting, you’d generate two HBZones with the same name, which would cause all sorts of issues when you have to run the energy simulation. So, it’s actually very useful to have a global counter in this case to keep track of everything going on the canvas.
I think a better way to control the zone names is to create a list of numbers corresponding to the zones and feed that manually into the mass2zones component. And leave the default naming scheme for situations where you don’t particularly care about the names.
This is a bug in the workflow. In most of the components we duplicate the objects to avoid this issue but we don’t duplicate the geometries in Zone2Masses component. As a result the input to the component is the same as the output (e.g. they both reference to the same place in the memory). That’s why you get the zone data from the input breps.
Just to clarify for my own understanding, you are saying in other components, the associated HBObjects of the input breps are copied (when you callFromHoneybeeHive) and they have new key(s) associated with them in the global dictionary HBHive. This prevents references to the same place in the memory causing weird global upstream/downstream behaviour from our input breps.
But because in Mass2Zones the input geometries don’t go into callFromHoneybeeHive, the same HBHive keys are associated for the input brep and the output brep and we get this bug of zone data from the askMe component?
Yup! That’s exactly why. Once you call the objects from the hive you get a new copy of the original object. In Mass2Zones we need to duplicate the input breps and use them to create the HBZones.
Brilliant, I should have known you had a solution to this
In that case @Grasshope, I just want to clarify that I’m wrong in the previous post regarding the global conflicts. Those global conflicts won’t exist in the the HB components because the HBZones objects are being duplicated every single time you input your breps, as Mostapha is pointing out. The Mass2Zone case is the only one where this global conflict aka same-memory-bug issue will happen, and sounds like it is an easy fix to make it more consistent with Mostapha’s existing system.
I started a git issue to resolve this user interface bug. Thanks for catching it!
Thanks @SaeranVasanthakumar for doing this deep dive and it would be nice to have this issue resolved at some point. In the meantime, this shouldn’t affect your workflow beyond some oddness of the AskMe component as you noted here @Grasshope.
I just wanted to explain the concept behind the default zone names quickly: before we had the current code that assigns default zone names, it was very common to get several zones with the same name, which causes E+ to fail. The current code is set up such that, by default, you will never have duplicate names no matter how many mass2Zone components are on your canvass. So that’s why it starts counting from 95 in your case. You must have had 95 zones that you previously generated and the code that assigns default zone names is continuing from that point. If you restart your GH definition, it will start counting from 0 again. Alternatively, you can specify a zoneName like “Office” and, if there are multiple zones connected to your Mass2Zone component, it will start counting from 0 for each zone (Office_0, Office_1, Office_2, …). You can see this in this example file:
