Hello,
I came across this group searching for interoperability solutions with LBNL’s software.
I’m wondering if there’s any interest in compatibility with THERM 7.8.
I see from the post history that Fairyfly works with THERM8 as LBNL opened sourced the API for the this version. I’ve been working on a similar API for the old .thm format
From the perspective of supporting people to get their THERM models to simulate, no, not really. THERM 7 is a completely different animal than THERM 8 and version 7 does not have a good enough mesher to model the construction details that people typically draw in CAD environments (which tend to be a lot more complex than what people draw in the THERM application). Hence, all of the old discussions you see on this forum under honeybee-legacy where people could not get their construction details to simulate in THERM. So I would rather not move backwards in THERM versions here.
But I would like to understand what you mean by this:
When you say “opened sourced the API” are you just referring to the fact that THERM 8 natively uses the .thmz file format, which is just a .zip file with a bunch of THERM XMls in it? Or are you referring to something else?
From what I understand, it was not possible to write a THERM 7 .THM file and this is why they came up with the .THMX format. But perhaps my knowledge here is outdated.
Hi Chris,
Thank you for the response.
I agree that THERM 8 is more capable overall. My interest in THERM 7 is mainly driven by current certification constraints, as NFRC approval for newer version is still a way out (at least based on what I’ve heard).
When you say “opened sourced the API” are you just referring to the fact that THERM 8 natively uses the .thmz file format, which is just a .zip file with a bunch of THERM XMls in it? Or are you referring to something else?
Yes, that is what I was referring to, specifically the LBNL-ETA/LibraryFEMTherm project.
From what I understand, it was not possible to write a THERM 7 .THM file and this is why they came up with the .THMX format. But perhaps my knowledge here is outdated.
I developed a parser/serializer for the binary .thm format to address this issue, as the .thmx doesn’t expose full control over certain aspects of the simulation.
I’ll explore Fairyfly more to see whether it could act as a bridge for generating THERM 7 models for certification workflows. I’d be interested to know if you’ve seen any similar efforts in this area.
THERM8 brings a lot more capabilities and improvements anyway, that make it worth to use with or without Fairyfly.
I understand the challenges of needing to submit models for certification and that it will take some time for the certification organizations to catch up. Even though, for classic steady state modeling, THERM 8 is already far much better and more accurate than THERM 7, the fact that LBNL put the BETA tag on version 8 because of the new hygrothermal and transient modeling capabilities will probably scare off the organizations until they eventually remove it.
If you make a map from Fairyfly objects/schema to a THERM 7 .thm file, I am sure that some people would try using it if their construction details are not very complex and they need to make a THERM 7 model for certification. Also, if you write the code to do this in Python and we determine that decoding and authoring .thm files does not violate LBNL’s end user license agreement, we could also accept your code (and probably a corresponding Grasshopper component) as a contribution to Ladybug Tools if you wanted to contribute it and get more feedback from people on the forum here.
I support your approach of ditching the use of THMX since, as you say, it lacks a number of important features. So I don’t think it’s really worth supporting at this point.
But I am still unclear if decoding and authoring .THM files violates the THERM 7 End User License Agreement, which is fairly strict in its wording. Unlike the new open source C engine and file schema manager package they released, THERM 7 has a strong proprietary license and it’s possible that the Berkley IP office might see decoding the binary format of .THM files as a violation of this part of their license:
You may not reverse engineer, disassemble, decompile, or otherwise attempt to derive the source code of the Software. You may not modify, alter, or create derivative works of the Software in any manner
If you haven’t already asked them, it might be worth it to send an email to Charlie, Robin and Simon at LBNL just to confirm that you’re not too deep into a legal grey area here. If they confirm that authoring .THM files doesn’t create a legal conflict here, then we’re good to go.
Hi Chris,
Thank you for the detailed response.
I am currently speaking with the team at LBNL to see if they would support this.
If they don’t block it outright, I would be interested in exploring how this could be adopted into a Grasshopper component. I’ll update back here when I receive a response.