I’m curious if anyone can share any suggestions for the following…
We have hundreds of IDF’s we would like to add custom sim output parameters to and run. I noticed when importing IDF’s into honeybee with the “HB Load gbxml OSM IDF”, only the geometry is imported (the schedules, hvac, etc are lost). I can run the IDF with the “HB Run IDF” component, but that doesn’t allow me to add output parameters.
Is there a way to take a large of number of IDFs, add custom output parameters to them, and then simulate? Can this be done with honeybee? I’m really hoping we don’t have to open each IDF individually to add the output parameters.
You are correct that detailed HVAC is just too complex to be imported from IDF to Honeybee. However, we are almost finished with some methods that will be able to import Ideal Air Systems from IDF and we actually already have code in place to import schedules. We are just waiting for the next stable release of OpenStudio, which has the capability to import schedules from IDF in the format that both OpenStudio and Honeybee use. A full list of what can be imported from different formates can be seen here in the pollination docs.
In any case, it sounds like this isn’t really going to address your question here.
Are you essentially just asking for an add_str_ input on the HB Run IDF component, which will allow you to add additional IDF text to each of the IDFs that you simulate with it? If so, that it pretty straightforward to implement and I can probably do it quickly tonight if you confirm this is what you’re looking for.
This has been a great to have @chris! and have finally had a good case where we can put it to use…
1) I do believe I found an error in the way it handles multiple runs though…
If I graft all of the inputs, it runs them sequentially, not simultaneously…
If I flatten all of the inputs, it fails to run because it adds the full list of “add_string_” inputs to each IDF
2) Another thing we found, take it or leave it… add a results_location input
we have a folder of 7 idfs (first img) and want to run with various epws and add unique strings to create 133 parametric runs. To achieve this, I had to build a sequence (second img) to move each of these to a newly created subfolder (third img) or else they would all write to the same location and overwrite each other. It would be nice to be able to feed a parallel folder to write the results to for each IDF input.
3) Again take it or leave it, but last thought we had utilizing this component…
It would be useful to have a “find and replace”… Similar to add string, but have the ability to search the IDF input for specific strings and be able to replace it via the add_string_ input.
very basic example:
OutputControl:Table:Style,
CommaandHtml, !- Column Separator
InchPound; !- Unit Conversion
I’m sure there are other ways of achieving what we’re doing here, but just wanted to share some thoughts we had as we were attempting to use the latest version of this component. Regardless, really appreciate the add_string feature and your willingness to take feedback on the tools, thanks again!
These are all good suggestions but my initial thought is that they are really advanced to the point that I feel they might be better supported with a custom Python component (perhaps using the “Run IDF” component as a starting point) rather than making changes to the official “Run IDF” component. I just sense that trying to support these advanced features with the existing component could complicate some of the simpler use cases. I can at least tell you how I would handle each of these cases if I were in your position:
I think it’s a more common case that you want to use the same additional strings for multiple IDF files so that’s why the component is set up the way that it is. To be able to run this case in parallel with multiple different additional string inputs, you can change the add_str_ input to use “Data Tree” access. Then, you can convert this Grasshopper Data Tree into a python “list of lists” using this data_tree_to_list method. Then, you can make sure that each sub-list gets coordinated with each IDF. Alternatively, if you’ll only have one additional string per IDF, you can just keep the current list access and make sure that each IDF uses a different additional string from the list.
This is unfortunately just the way that EnergyPlus is hard-wired. E+ will always write out the result files with the same names, thereby causing the files to overwrite one another if they are in the same folder. So, to address a case like this, I would do what you are doing now, which is write a script that puts each IDF into a sub-folder before simulation.
This one is almost be done entirely with native Grasshopper components. You just need to use the “Read File” and “Replace Text” components. Then, you can just add a custom component that writes the new text back into a file.
