HB_RotateHoneybee + North issue

[ayezioro]

Hi,
While trying to deal with this discussion:
#612
I bumped into the following.
Using the HB_Rotate crashes the OS or E+ simulation. The OS report says:
Runtime error (KeyNotFoundException): test_apartment2_z6
Traceback:
line 2527, in setAirMixing, ""
line 3841, in main, ""
line 3915, in script
Without using the HB_Rotate the simulation succeed.
Didn't check the other transformation components but i assume issues with them are expected too.
These are the links for the Rhino and GH files i'm using for this. See the big red arrow in the middle to identify where i'm defining the rotate element.

https://www.dropbox.com/s/wh9amhvbboqyktx/Check_19.03.17_EW_AY.3DM?dl=0
https://www.dropbox.com/s/b36i3xe9mu0rjkd/HB_Group%2BRotate--Issue.gh?dl=0

Sorry for making so much trouble these days.
-A.

[chriswmackey]

@ayezioro ,
Good catch. This is, indeed, a bug and I will fix it shortly.
-Chris

[chriswmackey]

@ayezioro ,
This is linked to a larger issue, which is that adjacencies are currently not preserved by the Honeybee transform components. I think that I can eventually add this in but, for the time being, I would suggest solving adjacency only after you rotate them. This will fix your issue for the present until I get time to implement the preservation of adjacency.

[mostaphaRoudsari]

@ayezioro, @chriswmackey,

This is by design. Since when you move or rotate a zone there is no guarantee that you're copying all the adjacent components with them. There is no easy way to no if you do. As a result solve adjacency should be re-calculated after using any of the transform components. It seems we don't remove all the data the needs to be removed though.

[chriswmackey]

@mostaphaRoudsari ,
If you rotate or scale all of the zones around a single point, then the adjacency could be preserved and I see multiple cases where this might be useful. Particularly when building large energy models that eat up memory, I would rather not solve adjacencies twice, which I would have to do if I want to use a transform component after assigning interior constructions.
I agree that we at least need a warning if adjacency is assigned letting the user know when the adjacency is forgotten. And, of course, we need to forget the zone air mixing along with the adjacency, which is the original issue here.

[ayezioro]

Thanks guys,
I think i "can" live with transforming before solving adjacencies :-)
-A.

[mostaphaRoudsari]

@chriswmackey, We can make keeping the adjacency as an option but then we need to update them with the new names and objects once copied, and here is when it gets tricky. Both methods for zone and surface already take clearBC as an argument. You can check it here. If you can find a solid solution to recalculate adjacency without really recalculating it we can expose it in the interface.

[chriswmackey]

@mostpaharoudsari ,

I have a solution worked out on my machine and it involves changing the input of the transform components to list access and adding the same uuid to all the names. I have it working for the rotate component and I just have to add in some checks and apply it to the other transform components. I'll try to take care of this all shortly.

[chriswmackey]

@ayezioro and @mostaphaRoudsari ,

After giving this a lot of thought, I have realized that it's best to just leave the option of preserving adjacency up to the user and this is what I have done in this commit by adding an extra option onto all of the transform components:
af2380e

So the components now delete the boundary conditions by default but they can preserve them if the keepAdj boolean is set to True. I have confirmed that, assuming you transform all of your zones together, the preserving of adjacency works fine in the simulation.

Next, I'll fix the air mixing issue, which is what this discussion is originally about.

[chriswmackey]

@ayezioro ,
This has now been addressed:
62b073d
By default, the components will now delete all boundary conditions but if you set keepAdj_ to true, all adjacencies, boundary conditions, and air walls will be preserved.

-Chris

[ayezioro]

Thanks Chris,
So the (recommended) workflow will be: Transform your model as you wish (the whole model and not individual zones) and after that solve adjacencies.
But also the other way around will work (solve adjacencies, Transform the mode + keepAdj_).
Is it right?
Thanks again,
-A.

[chriswmackey]

@ayezioro,
Yes, that is correct. This also enables you to use multiple solve adjacency components within one workflow. For example:

Build HBZones for 1 apartment -> Solve Adjacencies for apartment zones -> Move the Apartment Zones to Make Copies for apartments above/below the original zones (keepAdj_) -> Solve Adjacencies for surfaces between apartments (set 'removeAdj' to False).

This way, you can easily build large models by simply transforming original sets of zones.

[ayezioro]

100%. Full flexibility.
This is great!!
-A.