Hi @chris,
A couple of doubts from Legacy to [+].
Can’t find how to define air gap for opaque constructions.
I have one such material in the my customized IDF library and it doesn’t load from the SearchMats component.
Also have in the file Blind and Shade materials that are not found in the search. As a matter of fact no window_mats are found at all.
Compared to the Legacy the [+] finds much less materials/constructions from the same list (234 vs 33 for instance in constructions).
Thanks,
-A.
p.s. I asked this in another discussion, but decided to split …
@AbrahamYezioro ,
Sorry that I missed seeing this before. If the window materials are not loading up, then this is definitely a bug. Let me investigate and get back to you.
As for air gaps in opaque constructions, I would really recommend that you model these as Material:NoMass instead of Material:AirGap. If you read the E+ Input/Output reference at the link there, you will see that these two types of materials are the same in EnergyPlus world with only one difference: the Material:NoMass has additional properties for solar/infrared absorptance. So not supporting Material:AirGap saves me from having to make a significant number of checks in the honeybee-energy library, including making sure that such AirGap constructions don’t get specified on either the exterior or interior side of the construction (E+ throws an error in such cases since it has no absorptances to use). Not having to worry about the AirGap material also means that all opaque materials that we support can be translated to Radiance, which I know is going to become really helpful in the future. Lastly, I know that the openstudio standards gem (where all of the default template constructions come from) uses NoMass materials instead of AirGap ones.
So if you would really prefer not to change your library, I would sooner add some code to import Material:AirGap as Material:NoMass (with default absorptances) rather than add a new AirGap type into honeybee-energy. If this sounds useful to you, feel free to open a “wish” issue in honeybee-energy and I’ll put in such importing code when I get the chance.
Hi @chris,
Thanks.
Don’t think there is a need to build an import component.
Once you explained (and i understood) i’ll look forward to implement/change the materials so they accommodate to the new constraints. The old library will remain for the Legacy and the new will update to [+].
A.
I ran your user_library_Constructions.idf on my end and I was able to load all of the glazing, gas, and simple glazing system materials without issue. For example, here are a few from your library:
I am also able to load the window constructions as you see here:
I can see that the blind and shade materials are not loaded, though. Can you confirm that this is the only issue on your end?
Also, I didn’t mean that there would be a component to convert the AirGap material into a NoMass material. I meant that I would put code in the core libraries such that AirGap materials in IDFs were treated exactly like NoMass materials. So you would be able to import those AirGap materials form your library but Honeybee would just interpret them as NoMass. I do something similar with schedules where I currently map (almost) all of the E+ schedules to just two schedule types: ScheduleRuleset and ScheduleFixedInterval. I think I may add an issue just so that, at some future point, we can say that we can import all E+ materials.
Hi @chris,
See this image. I’m comparing the amount of materials/constructions imported from my library that complies with the keywords. There are pretty much different.
For a specific case if you search for is_ew you don’t get any match in [+]. I didn’t look exactly what is missing but just comparing the numbers.
Bottom line, some (many) of the materials/constructions are loaded (or match the search) while others don’t.
As for the AIrGap, i’ll also update my Legacy library to use the NoMass where the Airgap is used. In this way both libraries will be consistent. Agree that will be nice to implement the interpretation. Maybe some other users can bump into this.
It doesn’t make sense that those 100 opaque materials with the legacy plugin are from your user library. Your IDF file only contains 52 opaque materials + the one AirGap material:
I think you may be mistaking the fact that the “search” components in the new plugin are more precise. And this prevents you from getting some of the materials in the default library that don’t precisely follow your character sequence. Giving me specific examples that are failing like the is_ew is much more helpful.
For example, by looking at the is_ew I can see that the reason why they are not showing up is because you used upper-case letters to describe the materials in the constructions (eg. IS_CEMENT MORTAR) but title-case letters to describe the materials themselves (eg. IS_Cement Mortar)
I guess we can get around this if we do something in honeybee-energy like what EnergyPlus does, which is capitalize everything. I was hoping not to do this since I think people kinda like having control of the capitalization but I see that we have to do this if we want to import materials and constructions from IDF in accordance with what’s considered legal in E+.
I have a fix on my end that got around the capitalization issue more elegantly. So, now, the materials are correctly matched to the constructions upon import from IDF but the capitalization will follow whatever is specified in the material name instead of the construction material layer names. This all highlights an important fact of honeybee, which is that honeybee is case sensitive (and includes the choice of using either upper-case or lower-case letters) but EnergyPlus is not (converting everything to uppercase in during the simulation and within the results). So you should bear this in mind that you should follow the capitalization of whatever you see output from the “Search” components when using constructions in your library to build larger objects like ConstructionSets.
After implementing the fix on my end, I have more of your materials/constructions coming through:
And, if I add some more search terms to the construction search, I see that I get almost all 290 of your constructions. I think, at this point, the only constructions that aren’t re-serialized from your library are the Window constructions that contain shades/blinds, which technically aren’t legal in EnergyPlus on their own (they always need a “bare construction” without the shade/blind and a WindowShadingControl object that references both in order to be simulate-able). Still, we probably can support serializing just the shade version to a static WindowConstructionShade if I could write some code to identify where in the construction the shade layer is. I opened an issue for this but it will be a low-priority, since, if you really need to specify a WindowConstructionShade right now, it’s better to use JSON instead of IDF.
Lastly, I’ll note that the honeybee-standards repo includes a few samples like this one that gives you a sense of how these JSON files can get integrated into your standards folder.
The fixes with the library import have been merged. Let me know when you get the chance to use the versioner component and test it on your end.
And, one more thing regarding the JSONs: The full documentation the schemas of the honeybee JSON objects can be found here on the honeybee-schema repo in a search-able format. So that web page is the ultimate reference if you are looking to see all of the properties of a particular JSON object or you want to better understand what each of the properties mean.
