Rhino 7 & THERM components issue

I’m having an issue with the THERM components in Rhino 7.
When I run a simulation in Rhino 7 I get this error message:

  1. The geometry contains voids or overlapping regions. The edges surrounding these regions will be highlighted in red. You must fix this problem before simulating. Regenerating Boundary Conditions may correct this in some cases.The geometry contains overlapping regions. The edges surrounding these regions will be highlighted in red. You must fix this problem before simulating. ID(s): 12There are materials that lie outside of the Boundary ConditionsModel geometry and Boundary Conditions need to be properly defined before a calculation can be performed.

But, if I run the same simulation in Rhino 6 using the same grasshopper definition, it works just fine.

It looks like there was a same issue with Rhino 6 BETA as it’s discussed here.

When I compare the .thmx files from Rhino 6&7, I see the data differences in Polygon as you can see here.

Please let me know if there’s a way to work around it so that I don’t have to jump between Rhino 6 & 7.


THERM Test 2.gh (512.9 KB)

1 Like

Hi have you happened to find a solution for this in R7?

This is a hacky solution, but have you guys tried reversing the envelope curves before it enters the THERM component in RH7?

1 Like

Currently attempting but no-joy so far.
I’ve been looking around a bit trying to find something open source that could serve as a replacement;
Wanting to pursue GitHub - goma/goma: A Full-Newton Finite Element Program for Free and Moving Boundary Problems with Coupled Fluid/Solid Momentum, Energy, Mass, and Chemical Species Transport at some point when there is time.

oops, that one’s on my list but this one is the current obsession GitHub - KratosMultiphysics/Kratos: Kratos Multiphysics (A.K.A Kratos) is a framework for building parallel multi-disciplinary simulation software. Modularity, extensibility and HPC are the main objectives. Kratos has BSD license and is written in C++ with extensive Python interface.

Ah that sucks. changing the order or the tolerance were the only two easy solutions I could think of. I’m not really familiar with what is considered state-of-the-art outside of THERM/WUFI, but finding a open source equivalent would be great.

I’ve likely made a list of things that are a bit overkill for a THERM replacement…(and a bit over my head) but finding something that can replace THERM, is py based and open source is a favorite rabbit hole of mine. Hopefully I find something in the near future before I attempt ( and fail ) to write something myself!

Hello. Yeah, I had no luck running THERM in Rhino 7. Looking at other discussions about it, I think the Ladybug Tools team is just too busy with other stuff at the moment. I don’t see it coming back anytime soon.

I feel like there are things Berkeley Lab needs to work out for THERM 8 still though it started to have a transient mode that I was personally waiting for a while…

So for now, I’m just running THERM in Rhino 6 using THERM 7.6!


1 Like