Hi Chris,
Trying to check the recently uploaded example on Therm in Hydra i noticed that the geometry is not internalized.
Can you update this example?
Thanks,
-A.
Abraham,
I updated the example file so that the geometry is internalized:
https://github.com/chriswmackey/hydra_2/commit/e856a0bf1b34b66e461f…
Also, the THERM example files each should come with a Rhino file in the .zip folder.
-Chris
Thanks Chris,
The Rhino files are not included in the zip.
Question: EP materials can be the input for the HB_createThermPolygons? This is what i read, but when running the Therm_Export_Workflow example the HB_writeTHERM is not recognizing thhose EP materials.
I’m using your files as they are and i am updated as for today.
-A.
Abraham,
Thank you for letting me know. It seems that the Rhino files were not exported because I was using a very old version of the Hydra component. I will try to fix this when I get the chance but, in the meantime, both example files should have the geometry internalized.
The “Create Therm Polygons” component is meant to accept either EP or THERM materials and this is what is demonstrated in the example file. Are you saying that you do not see the THERM polygon components like so when you open the file?
As you see, the “M01 100MM BRICK”, “8IN CONCRETE HW” and “1/2IN GYPSUM” are EP materials. If you do not see the Therm Polygon components like to, it’s a problem that is specific to your system and you will have to send me the error message.
Another guess, which may be far off from the issue, is that you might be connecting EP Constructions and not EP Materials?
-Chris
Hi Chris,
This is weird.
First of all, i’m not using constructions.
I was just trying the example file as is. The thing is that i see the EP materials out of the HB_callFromEPConstrLibrary, but they are not recognized by the HB_writeTHERM. I changed the materials using my own EP’s and it is now working.
After your above response i disconnected your materials and connected again and it is working now.
I suppose some times it need some kind of “electric shock” to work 
It is fine now.
Thanks,
-A.
Abraham,
I think I know what is happening. When you connect up an EP Material to the thermPolygon component, a process happens that is similar to connecting a new custom EPmaterial/EPConstruction to the HBSrf component. Specifically, the component writes a THERM version of the EP Material into the THERM library that is stored in memory just like the HBSrf component writes the new custom material/construction into the EP Library in memory.
When you have another HB_HB flying on another GH canvass or you drag/drop a newr HB_HB onto the canvass, it overwrites all of the materials that you have written to this library in the memory of the Rhino document. Accordingly, to ensure that you do not encounter this error, I would either not have multiple GH files open for a given Rhino document or, if you do, hit recompute whenever you get this type of warning to ensure that the GH document re-writes all of the materials/constructions into the library.
Mostapha, if you read this, I think that we really need to find some way around this overwriting of libraries in Honeybee. If this issue has confused Abraham a couple of times, that I am positive that it has confused the great majority of the HB user base. I have started a github issue for it here and please let me know your thoughts:
https://github.com/mostaphaRoudsari/Honeybee/issues/446
-Chris
Hi Chris,
This was EXACTLY like you described. I had many GH open. The timing of your response was impeccable, as something similar happened to me in class time, so i knew how to deal with this.
Next time i know what to do.
Thanks a lot,
-A.
Abraham,
The issue has been fixed by Mostapha:
https://github.com/mostaphaRoudsari/Honeybee/issues/446
Hopefully this should never happen again!
-Chris
Excelent!!
Thank you!!
-A.
Hi Chris,
This is the rookie question and I apologize. I downloaded the example Mostapha shared in the new version announcement. Somehow the air gap material doesn’t exist in the library. I tried going over the available materials and it wasn’t there.
Now this is not bug ofc, as the whole thing works when I change it to anything in the library. But the air gap would be an important material to have in these. I wonder if it is my fault missing this or I need to create one with the components?
Sorry for taking your time about this small matter.
Kind regards,
Theodore.
Hi Theodore,
The air material is very important as almost every construction has some sort of air gap in it and it is often important to use the THERM air material to model the radiant heat transfer of this gap correctly. Thank you for posting about this.
All of the THERM materials are stored in a file called thermMaterial.csv that is in your Ladybug Default folder. The file is supposed to update when I post a new version but this feature was not working if you had a very old version of the library.
Can you verify that the air material shows up in the most recent version of this example file?
http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&for…
If so, all of your future GH files should include the air material in the library.
-Chris
Hi Chris and Mostapha,
Great with the Therm integration. Will use it for material experimentation etc, but fails to get the provided example running - with a non-informative error.
Ladybug is updated, no parallel running of definitions, materials are reconnected/recomputed, doc in meters etc. See screenshots. I suspect its the material lib that makes problems, but there is no information or trial-error testing of the definition that offers solutions.
Thanks for your great work on this.
/Isak
Hi Guys (@chris )
I still have the above issue, with the simulation not running without further information. All files/libs seem to be loaded correctly, and I have tested both with the example files in LB/HB legacy versions and in the newest updates (RH/GH/LB/HB). I am still using Therm 7.6. See attached img.
Any help very appreciated?
Best
Isak!
Screenshot 2020-09-12 at 20.25.21|690x387
Hi @Isak ,
Sorry for the late response. It’s very possible that your geometry is just failing to make it through the THERM meshing process. Unfortunately, the mesher that is built into THERM can fail easily when there are big jumps in the level of detail from small scale to large scale and this can result in THERM throwing an undescriptive error.
So you may have to simplify your geometry. Are you able to open the thermFile in the THERM UI and simulate it? That will let us know if it’s an error on the Honeybee end or the THERM end.
Hi @chris
Thank you for the swift response on this now. I have not tested in Therm UI, but did a test in GH with a simple rectangle geometry, with two simple lines as boundary condition. Same error. Puzzling.
Best, Isak
Hello @chris
Success! By reinstalling Therm v7.7, (including new VS17 and Intel Fortran packages), it both runs in Therm UI and GH 
Not sure what the problem was in the end though.
Thanks for all your great efforts on this!
Best Isak
Huh. The THERM components are really only intended to work with Therm 7.6 so maybe the issue was related to that. Is THERM 7.7 the only copy of THERM that you have on your machine? Or do you also have THERM 7.6?
Well, I now have both v7.6 and v7.7 on my machine (also because I wanted to test the new functionally of overlapping geometries in v7.7). A recheck in GH shows the Therm version HB is linked to is v7.6. When installing v7.7 and reinstalling the other packages, it must have removed the error. Hence, the issue must have been in the packages, not HB or Therm.