Assigning - Construction:ComplexFenestrationState to window




I’m very interested if anybody have any advice on how to format the LBNL WINDOW .idf output (from a complex fenestration system) so that it can be assigned to a surface in Honeybee through Grasshopper. The idf. output from LBNL is the EnergyPlus object Construction:ComplexFenestrationState.

Trying to load the .idf file into Grasshopper the file format is different than the one from Honeybee components:

Also the additionalStrings_ input doesn’t overwrite previous definition, so I recon it can’t be assigned there.

One workaround is to get Honeybee to initially create an .idf and then manually copy paste the fenestration object and change the appropiate names/references. However it would very nice if there is a faster way, since I need to do different iterations.

So to summaries the problem in a nutshell - I would like to be able to assign the attached .idf Construction to a surface in Honeybee.

GlzSys_Triple_PXN_MS_Bsdf.idf (1013.5 KB)


@tobiaspedersentsp ,

Good question. The Honeybee Import WINDOW IDF Report component can import the vast majority of exports from LBNL WINDOW - all of the way up to the spectral data if you so desire. However, complexFenestrationStates and EnergyPlus BSDF formats are not currently implemented. Given this, your best route towards automation is probably to write an EnergyPlus Measure that automatically replaces the construction in the IDF with the complex one that you need for your simulation.

I know that writing a measure requires a little knowledge of scripting and at least rudimentary knowledge of the Ruby Programming Language (or a willingness to search stackoverflow for questions about syntax). Still, an operation like this is really only a few lines of code and the vast majority of it can be written by editing the EnergyPlus measure example given in the measure writers guide:

This hydra example file shows you how to assign the measure on the OpenStudio component once you have written it:

I hope that helps and let us know if you end up writing the measure.



Thank you very much - I will give it a go and get back to you !


Hi Chris

I ended up implementing a solution outside of Grasshopper. Wrote a python script that samples the BSDF .idf output from LBNL WINDOW with the .idf output from Grasshopper containing all other definitions.
All these sampled .idf files is a nice use case for the renRunIdf component, however I have experienced som troubles with that component I want to let you know about. If this is more appropriate in a separate post let me know.

Running the .idf files using the reRunIdf component not all files gets simulated when running a list of 672 idf files in parallel. Simultaneously the component never “finish” running and just continuous to “block” grasshopper.
Trying an alternative approach of animating a slider through the list of idfs (not in parallel) the command prompt running E+ freezes sometimes and doesn’t continue the simulations, forcing one to close the command prompt window (then the next simulation starts).

Investigating which files where not calculated correctly the first time and rerunning them ones more or sometimes twice, solves the problem, so I don’t think there is an issue with the .idf files.

Let me know if you want me to send you some of the Idfs to test for yourself. If yes, let met me know at what directory you intend to place them and I will prepare the list of idf names for you.


@tobiaspedersentsp ,

I am 99% sure that the issues are not with that component but rather with E+ running the IDFs. Are you using E+ 8.9? I know that there some issues in E+ 8.9 that cause the autosize calculation to hang like that.

In other words, you would have this issue whether you run it with the Rerun IDF component or ran the with EPLaunch. I’d recommend using E+ 8.8 for the time being if you need all of the IDFs to run correctly.