Challenges with Therm - Calculation of window frames

I’ve only been dealing with Therm and Honeybee for more than a week and would just like to write down some experiences before my question. I hope it helps people:
Even the installation of all the required plugins is not entirely intuitive. But if you do a bit of research in the forum and use the right versions, it should be doable. For me it now works well with: ladybug 0.0.67; honeybee 0.0.64; Therm 7.6.1.0; Rhino 6.35. (Attention: The Read-Therm component 0.0.63 does not work).

Furthermore, I could not achieve comparable U-values for a simple wall from a construction with flixo right from the start. However, this was due to the setting of the radiant energy. Here is the reference to the customRadEnv component, where the view setting can be set to 0.

One challenge is the geometry description. There must be no closed cavities. Here I refer to a discussion in the forum. (THERM - Window section issues - #11 by chris) In addition, it is advisable to define all geometries directly as polylines.

In the meantime, I have a definition for which no error message appears when I create the file for Therm. However, the simulation does not yet work. (Error message: The geometry contains voids or overlapping areas. The edges surrounding these areas are highlighted in red. You must fix this problem before simulation. The geometry contains overlapping areas, which in some cases can be corrected by regenerating the boundary conditions. The edges surrounding these areas are highlighted in red. You must correct this problem before simulation. ID(s): xxx The model geometry and boundary conditions must be correctly defined before a calculation can be performed).

When I open this file in Therm, I am also informed of the gaps. It looks something like this.

However, I can’t trace the gaps (and I can’t see them visually in Therm). When I created the geometry in Rhino, I converged all curves to polylines at Berginn. Then I created the inner cavities based on the existing polylines and declared them as air. When I intersect the line of the air with the adjacent material, I get a resulting intersection line (so it is really on top of each other) Also when I bake the result of the ProbRegion, I get a continuous surface. And the resulting boundaries also result in only one boundary.

Now I was at a bit of a loss as to what else I could define.
I rewrote the definition from millimeters to meters. However, the material definition is then quite unprecise:

But this leads me to the assumption that Therm (or the Honeybee component) rebuilds the lines (even if they are already polylines). But then it is logical that gaps are created when lines that are already adjacent to each other are rebuilt independently of each other.
Now the question: Can I still change tolerances somewhere? Should it not matter whether the definition is in millimeters or meters? Is my geometry too complex for Therm? Can I define that lines are not rebuilt? How can I make progress here?

Hello everyone,
I have now found something else that narrows down the error better. If I use the curve as geometry, it is rebuilt by the component “createThermPolygons”, although it is already a polyline. This makes it clear that a cavity is created. The distance is less than 0.000 mm. I think this is also the reason why no error is displayed when the THMFile is written. Can I set a tolerance (@edpmay) ?
Can I prevent the curve from being rebuilt?

original line:

therm polygon:

not-working_example_window.gh (686.2 KB)

I hope someone can help.
Greetings
Simon

Hello everyone,
I have now simplified the geometry again. I have broken down all the control points into the individual coordinates and rounded them to two and then one decimal place.
rebuild_controlpoints.gh (12.0 KB)

Then I had to add control points manually to some of the lines so that the lines would lie on top of each other again.
Unfortunately, there was still the error of the overlapping surfaces. Then I recreated the individual areas that were noted by Therm: Erase → Create hatching within boundaries → Duplicate boundaries. In my opinion, possible (human) errors should then be minimal.
Now I have another error:

I changed the MeshLevel from 2 to 12 (and something between), however the error persists.

The described coordinates are just at a point where there are no other intersections (or other crazier geometries). [blue circled]

First question: Is it correct that Therm can only work with one decimal place? Or can I still set the level of detail somewhere?

Secondly, how do I deal with the mesh settings? The geometry has already been greatly simplified…

I am a bit at a loss as to whether it is even possible to simulate this window frame (in the installation position) in Therm…

Does anyone have any ideas? (@chris, @TrevorFedyna )

Greetings
Simon

Here the geometry is simplified:
not-working_example_window.gh (614.2 KB)

Hey @slang ,

I don’t think THERM is exclusive to working with one decimal place but THERM’s meshing algorithm is extremely fragile and rounding everything to one decimal place is our attempt to simplify the model such that there’s a higher chance of the meshing operation succeeding.

Because THERM is not open source, there is currently no way for other experts to inspect the meshing algorithm and improve it. So, for as long as THERM continues to remain closed source, your only option is to simplify your geometry to the point that the meshing algorithm accepts it. From your screenshot, it’s clear that there are way too many little details there to get the meshing calculation to succeed. You must remove them and then maybe you’ll get it to the point that it succeeds.