filtering out (removing) glazing objects?

Hello,

After generating glazing using the "Honeybee_Glazing based on ratio" component, I'm trying to pare down the number of glazing objects that are created. I found the remGlz component, but am not sure of the structure for the srfIndex and pattern parameters. is there any documentation for the tool?

In this forum I found a similar problem and solution worked on by Orn Erlandsson:

http://tinyurl.com/pkzlpyr ...but in trying to re-create his solution I believe I'm missing some of the connections.

I have determined that the glazing elements I want to remove are the 2nd and 3rd out of 3 on each exterior (wall) surface, and have a culling pattern for all the window objects as they are broken out by the HB Decompose component:

Any suggestions much appreciated!

Replies are closed for this discussion.

Replies to This Discussion

Permalink Reply by Mostapha Sadeghipour Roudsari on September 22, 2015 at 5:45pm

Hi Nick!

My best guess without testing the file is that since the counting starts from 0 so you probably need to input 1 and 2 (instead of 2 and 3).

Mostapha

Permalink Reply by Nick Novelli on September 28, 2015 at 3:04pm

Mostapha, hello again. To follow up with this (didn't want to bug you yesterday, busy;)

I've played around but haven't gotten it working yet. In the image attached, for instance, I plugged in a number to the srf index, and ran through all possible indexes for the surfaces with windows (0-5, and then 6 for good measure) without triggering any action.

It seems like, like you said, it would be straightforward--I might be running into a bug?

Also, this is the script that's up in hydra - I renamed ("Armature..." and re-tagged it (spawning what looks like new scripts on the front page, even though they're copies...I'll enter a feature request to delete old scripts we don't want to share anymore;)

Thanks and all the best in in PA

Nick.

Permalink Reply by Nick Novelli on September 28, 2015 at 3:46pm

http://hydrashare.github.io/hydra/viewer?owner=NENEN&descriptio...

tho this is off-topic, as to the feature request, I realized it was just a matter of maintaining (deleting) the generated files locally...and added a note to that end in the wiki.

Permalink Reply by Anton Szilasi on September 30, 2015 at 1:07pm

Hi Nick,

Please attach your grasshopper file and I'll take a look for you,

Cheers,

Anton

Permalink Reply by Nick Novelli on September 30, 2015 at 4:44pm

Sure thing--it's a big palette, but the component is here:

and here is the link to the script:

https://www.dropbox.com/s/xgqpo64e5871m2i/Xmas%20_5.3.1.gh?dl=0

thanks! I'm interested to know if you find anything. (Maybe simply my own error in how I'm trying to use it, right?)

Best,

Nick.

Permalink Reply by Anton Szilasi on October 1, 2015 at 4:36am

Hi Nick,

When I open your GH file the breps that you are connecting to _HBZones are not Honeybee zones therefore you get no output from perimeters or interiors.

Is this your issue?

Anton

Permalink Reply by Nick Novelli on October 1, 2015 at 5:20am

Hi Anton,

Although in earlier versions of the file the whole building was plugged into the generic component upstream from the perim/interior split, I made sure the correct data is plugged into component now, and I get the correct HBZones coming out from the perimeters node (see rhino screenshot)

It's possible when you DL'd the file it was not yet updated, but I checked, and it should work now:

https://www.dropbox.com/s/xgqpo64e5871m2i/Xmas%20_5.3.1.gh?dl=0.

thanks!

Nick.

Permalink Reply by Anton Szilasi on October 1, 2015 at 9:57am

Nick

By accident I deleted your last reply, bizarrely I am still getting the same issue that is the Breps are not Honeybee zones, clearly there is something different on your system and mine.

I think the best approach would be for me to do remote control over skype since I dont have a lot of time to look at what is different.

If this is really a bug I want to get it solved so please add me on

skype - anton.szilasi. I'm on GMT.

Permalink Reply by Nick Novelli on October 1, 2015 at 2:47pm

So, a bit of headway -

It looks like the two input nodes represent two different ways of defining what is to be done, based on the single line check in the code that triggers execution of main() if either inputs are non-null.

The "pattern_" node expects (as you basically figured out) a T/F pattern that corresponds to the list of surfaces in a zone. since the zones come into the remGlz component (grafted and simplified) in separate branches, the pattern input should match that structure.

I haven't figured out the structure looked for by the srfIndex_ node yet.

This is just a guess, but since the actual "doing stuff" commands in the code are "surface.removeAllChildSrfs()" methods, then I assume: right now it's only possible to remove all the child surfaces at once, rather than culling out individual child surfs (windows).

...This hits my current knowledge limit. I started poking through the honeybee code. It looks like the child surfs are indexed? (Based on seeing "surfaces.childsrfs[]" and something about a "basechildsrf").

So presumably one could set surfaces.childsrfs[n] = null or something like that based on an array fed to a function input. Perhaps I'll take a stab at it at some point (if you don't beat me to it).

But for now I think that answers my question. this all started because I wanted to clean up the geometry I fed into e+. But since I'm not using e+'s geometry-sensitive internal radiation distribution models, I believe the glazing apertures get combined in pre-processing anyway, and don't slow the simulation down.

Thanks for the consult! This was my first time really poking around under the hood; I'm more astounded than I was before at what you fellows have accomplished so far.

RSS