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.
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: https://nrel.github.io/OpenStudio-user-documentation/reference/measure_writing_guide/#energyplus-measures
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.
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.
So I picked up implementing this measure so more people can have the possibility of using the idf BSDF files from WINDOW in ladybug tools. Have tried a variety of approaches but are running into some issues that I hope you might have some ideas for.
First up, the functionality of the EnergyPlus measure should be to import the BSDF file .idf along with “Frame and Divider Name” .idf from WINDOW. From here it should assign all “FenestrationSurface:Detailed” to reference to the two imported files.
There is only one of these functionalities that I find tricky to implement: importing the BSDF file .idf (in the right formatting). This is so because when you use:
source_idf = OpenStudio::IdfFile::load(OpenStudio::Path.new(source_idf_path)).get
workspace.addObjects(source_idf.objects)
-drawn as inspiration from BCL, “inject_idf_ojbects”: measure.xml (2.6 KB) measure.rb (2.9 KB)
they change the formatting of the matrix data, which is no good (most likely because the function starts new lines by “,” instead of “\n”).
Essentially if the BSDF .idf could be “injected” into the .idf file as plane text using the EnergyPlus Measure, I think the problem would be solved but don’t know how to do that – do you have any ideas?
Then I thought (given that “additional strings” are applied before measures) that the approach in the picture below might work:
Glad to see you getting this deep into measures. In fact, I think you are working deep in there that I would recommend you post this question to the unmethours forum (https://unmethours.com/questions/) where the OpenStudio and EnergyPlus gurus reside.
What I can say is that you should be able to do this with a measure and doing it that way will be much cleaner than using additionalStrings. If it really comes to it, you can try to have the measure add the correct line breaks in for you. I am sure that there’s some way of getting this with the right Ruby code. If I get the chance, I’ll have a look myself and try to debug it.
if someone is interested in an additional way to use ComplexFenestrationState within HB, I found another procedure. The approach requires to manipulate a little bit the idf file, but then it can be directly employed in Grasshopper.
from the idf file containing the BSDFs and the other fenestration information, extract the section Construction:ComplexFenestrationState, and connect it as EPconstruction to your window system. Note: delete this section from the original idf file.
connect the rest of the idf to the addittionalString input. Since the file is quite big, I suggest to keep it in the *.idf file and open it through the read file component.
That’s it. Just a note, when writing idf, the runEnergySimulation component turns orange. There isn’t a real error, the component just tells you that is not able to find the construction you set before within the library. However, the construction information are contained in the “additional string”.
@GiuseppeDM
Thank you for the suggestion. I am however looking for a more integrated approach with minimal manual work (can take the output from WINDOW right away).
@chris
So it turns out that the problem with the EnergyPlus measure is the “workspace.addObjects” method which imports “Construction:ComplexFenestrationState” in a way that makes EP crash:
Until the bug is fixed I have made a temporary solution:
Importing the WINDOW BSDF idf using additional strings (the python script takes the files directly from LBNL WINDOW)
Applying a measure that changes the construction name of all windows to the name of “Construction:ComplexFenestrationState”
However there is a problem:
Cannot gets measures to work in Honeybee - do you know why?
Thanks for the clarification @tobiaspedersentsp and sorry that I should have looked more closely at your image before. It’s clear that it’s an issue on the Rhino/GH/Honeybee end, then and not an issue with OpenStudio or the measure.
I have not been able to re-create the issue on my end, though. Can you post an image of a panel connected to the readMe! output of the OpenStudio component so that I can see what line it is failing on? (you should scroll all of the way down in the panel if it’s a large message coming out of it).
For troubleshooting, I could recommend trying the following:
Try changing the workingDir_ to a place on your computer without white spaces and you know you have access to write to.
Try running Rhino as Administrator (its possible that you as a user has the ability to write to that location but Rhino may not have permission by default).
I was able to recreate the issue in my Rhino 5 but not Rhino 6. I also realized that, if I just ran the batch file written into the folder manually (by double-clicking on it), it applied the measure without issues. Checking the error message when I run it from Rhino, I see that it’s referencing a location for Ruby that does not exist:
Ok, I am getting closer, I realized that the os.access(‘C:\openstudio-2.5.0’, os.F_OK) method in my version of Rhino 5 returns False but it returns True in my version of Rhino 6. So I am right that it has to do with your Rhino having access to the OpenStudio directory.
The really crazy thing is that I realized that R_OK, W_OK and X_OK all return True but F_OK returns False (the last one is supposed to tell you whether the directory exists). So, apparently, I can read, write, and execute from a directory that, according to Python, does not exist.
@mostapha , if you have any idea what could be going on here, please share your thoughts.
The best hypothesis that I can come up with right now is that it is a bug in the older version of IronPython that Rhino 5 is using. @tobiaspedersentsp , are you using Rhino 5 and, if so, could you try testing the script in Rhino 6?
Also, what is your operating system? Maybe it’s just an invompatability between older versions of ironPython and newer operating systems like windows 10.
Waiting for my educational upgrade to rhino 6 to go through - will post the workflow here when it is tested. It is comprised of:
A GHpython script that imports the WINDOW bsdf .idf in the right format for “additional strings” (to avoid the workspace.addObjects function that imports Construction:ComplexFenestrationState incorrectly as described above)
A measure that changes the name of the window contructions to that of the Construction:ComplexFenestrationState in the BSDF idf.
@chris - do you know if “additional strings” is applied before the OSmeasures?
So the approach mentioned above turned out to be no good since the OSmeasure can only change the construction of a surface if the new construction is present in the idf. And apparently the OSmeasure runs before additional strings in Honeybee.
Instead, with a bit of inspiration from @GiuseppeDM suggestion, I wrote a single python component that does the job: discourse_example.zip (526.5 KB)
This approach is also faster than applying a measure.
@chris - would it be possible to add an exception to the warnings in the following picture, if the EnergyPlus object is a Construction:ComplexFenestrationState ?
@tobiaspedersentsp ,
Sorry for such a late response here but I know that we talked in Denmark and I’m glad that you were able to solve it. I can turn off the warnings for some of those things but I think I will have to leave some. Would this still be valuable or do you think all of the warnings need to go away to make it worthwhile?
