Therm example

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 :slight_smile:

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

@Isak Could you tell us which version of Therm are you using?

Hi @minggangyin,

  • Therm7.6
  • HB 0.064
  • LB 0.067
  • RH6
    /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 :slight_smile: 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.

Hi Chris,

I´m rejoining this old topic since I´m struggling with geometry definition in GH for THERM over and over again. We´re using it to simulate heat flux through complex wall geometries. To do so, we already tried many different ways to automatically generate / manipulate geometries, sometimes it works sometimes not. And still we couldn´t figure out, a systematic way to get it running - at least for most of the geometries.

Attached there is a typical geometry, where we ended up transforming surfaces into meshes before creating THERM polygons - which works more or less - but then still the boundary conditions can´t be set correctly. And when opening it in THERM, we can´t get it running either.

Anybody with some experiences on that or some ideas, how the geometry has to be manipulated and what are the relevant things to take care of?

I would be very thankful for any kind of response / feedback / help!

Best, David
THERMTestPattern.gh (635.0 KB)
THERMTestPattern.thmx (609.7 KB)

The Legacy THERM components are not very reliable, especially when it comes to things like geometries with holes. If I get the chance to write a version of this for the LB plugin, it will not have these limitations, though this is not a high priority given that THERM is still closed source and no one has been interested enough in hiring us to develop a new and improved interface.

It’s probably also worth noting that the THERM meshing algorithm has some serious limitations, which make it incapable of simulating certain detailed geometries. So trying to simplify the polygons as much as possible will likely prove helpful.

1 Like

Dear Chris,

I appreciate your prompt response and the clarification regarding the technical constraints. We will certainly make an effort to minimize the polygon count in our project.

As we are utilizing the legacy version due to its compatibility with our previous simulations, I understand from your answer that creating a THERM connection with the current LB version will not work for the reasons you’ve mentioned. Do I understand so correct or would there be any alternative or a specific version that would allow us to achieve this. Please let us know if you can tell a possibility, and if so which version numbers we could consider.

Best regards,
Mauritz