Testing a list of options using Honeybee / E+

Hi all,

I'm trying to test a bunch of different geometry options (different window to wall ratios, etc) in Honeybee and E+ for daylight factor, energy performance, etcetera.

However when I want to input a list of options - say 0.2, 0.4 and 0.6 WWR - See attachment - for the South Facade I only get one result, as the glazingCreator component only creates one surface, and the runDaylightAnalysis component combines all the inputs into one geometry for testing.

There a few ways around it:

Do an optimisation study using Galapagos
Make a list of input options and iterate with Anemone, or Hoopsnake

But they all don't exactly do what I want and can be quite a bit of hassle. Is there an easier way to do it?

Attachments:

Screenshot_WWR_options.png, 230 KB

Replies are closed for this discussion.

Replies to This Discussion

Permalink Reply by Claudio on August 13, 2014 at 6:09am

Hi reiner I'm not sure of the way you've build your definition. But make sure that the component creating the window receives only one value for south facade WWR. Now if you want to test different WWR on the same geometries then you can try a slider connected to Galapagos that will change the south facade WWR.

Maybe you can post an image or upload your definition

Permalink Reply by Claudio on August 13, 2014 at 6:25am

Btw I cannot get your attachment as I on my phone. I'll take a look. Once I get to the office

Permalink Reply by Reinier Zeldenrust on August 13, 2014 at 8:18am

Hi Claudio, thanks for the answer. It works fine when I only connect one value, but I'd like to test multiple values at the same time, batch style. Galapagos works fine but that doesn't provide me with a nice list of all the options at the end which is what I'm after.

Permalink Reply by Chris Mackey on August 13, 2014 at 7:26pm

Hi Reiner,

It sounds like the issue that yo mention is easy to address. The glazing creator is setup, by default, to take a list of glazing ratios and apply them to walls based on their cardinal direction. For example, plugging in a a list of 4 values will assign different glazing ratios based on N,S,E,W. 8 values will assign different values based on N,NE,S,SE,S,SW,W,NW.

To use a list to get different ratios for the same wall, you can just graft this list of ratios in GH. If you send me your GH file, I can show you exactly how to do this.

-Chris

Permalink Reply by Mostapha Sadeghipour Roudsari on August 13, 2014 at 7:27pm

Hi Reinier,

If you want to find the optimized option then you have to create them one by one and not all at the same time. Try something similar to this:

Permalink Reply by Chris Mackey on August 13, 2014 at 7:55pm

Yes. I should note that the instructions that I gave above are not for finding an "optimized" result. Just if you want to get a few zone options out of the glazing creator.

For optimizing, you would have to animate a slider run all ratios in the parameter space or use Galapoagos as Mostapha has shown.

Permalink Reply by Reinier Zeldenrust on August 15, 2014 at 2:31pm

Thanks for your replies so far.

Mostapha, I have played with Galapagos and that does work the way I want it. However, while that finds an optimum, I want to create a series of options for the architect to evaluate, with different pros & cons. I'm making a parellel coordinate chart like so: http://bl.ocks.org/jasondavies/1341281 so I need to fill it with a few hundred / thousand simulation.

I have grafted the output from the component (per your tip, Chris) and that actually work; if I configure the data tree correctly, I can let Honeybee run 3 simulations for each option. However, if I feed the DaylightAnalysis component with 3 filenames it doesn't separate them the way I want to. Will fiddle with it some more.

Chris, the slider also works, but I want to vary multiple sliders for my database.

Still, appreciate the discussion - at least I'm not missing a glaringly obvious solution.

Permalink Reply by Mostapha Sadeghipour Roudsari on August 15, 2014 at 4:50pm

Hi Reinier,

Check Honeybee example file for grid-based analysis. There is a component at down left that does what you are looking for. I made it based on David Rutten's example. You can connect one or multiple sliders to the component and it will iterate between all possible combinations.

If you have TT-Toolbox plugin installed there is a Brute-Force component that also does this. Good luck with your studies and let me know if you have any other question.

Cheers,

-Mostapha

Permalink Reply by Örn Erlendsson on October 16, 2014 at 10:05am

Hi Mostapha,

I am dealing with a similar issue as Reinier. I am using the component that you are talking about, however when I run my simulations the results from the first option gets lost. I noticed that the result file only disappears after I toggle off the 'runRAD' and 'WriteRad' inputs in the 'Run daylight simulation' component. Of course I can just copy the results before I do this, but that can be quite inconvenient.

Is there perhaps a simpler way of doing this. (Using brute force doesn't quite do it for me either, i.e. same issue) Or is there even a newer version of this component somewhere?

Also, why is this 'runItAll' component not available in the HB or LB components set?

I've included a quick GH example file.

Attachments:

DaylightFactor.gh, 387 KB

Permalink Reply by Chris Mackey on October 17, 2014 at 3:49pm

Hi Orn,

It seems like you are getting the issue because the component is overwriting the results if you set "RunRAD" to False but "WriteRAD" is still set to True. One thing that might help with this if you have both "WriteRAD" and "RunRAD" connected to the same boolean toggle, which will ensure that you do not overwrite your results again until you are ready to run the next daylight simulation. Another thing that might help is if you set the "overwriteResults" input of the daylighting component to False. This will ensure that any daylight simulation that you have run is never overwritten. I have done this in the attached file and let me know if this solves your issue.

The simplest way that I have found is to write the name of a parameter that you are testing into the RAD file name of the simulation and this should ensure that each file has its own name and does not over-write previous results (it looks like you are doing this with the glazing ratio, though, so maybe I do not understand).

I think that the "RunItAll" component is not included because it is not as relevant to the specialties of LB+HB and it seems that Brute Force does the job of this component a bit more nicely.

Permalink Reply by Mostapha Sadeghipour Roudsari on October 18, 2014 at 9:59pm

Hi Orn,

Chris said it all. The only thing that I can add is that my approach is to add a -1 to the start of the lists and run the analysis only and only if the input is not -1. You can see that in example file.

Chris, what do you think about adding the component to extra tab at some point? I should re-write it in Python if we want to do so. I think it should be possible to take care of the current issues that Orn mentioned in the newer version.

Hope it helps,

Mostapha

Permalink Reply by Chris Mackey on October 19, 2014 at 12:13am

I just realized that I forgot to attach the GH file. Here it is.

Mostapha, in response to the RunItAll component, I think that it could be a good idea to include it in the extra tab. I can see some tutorial videos in the future where we want to run a bunch of sliders but not have everyone download TTToolbox in order to get Brute Force.

I didn't realize that it was written in C#. If we can still get the same functionality with Python, lets go ahead and translate it!

Attachments: