Honeybee Triangulation of Window Surface?

[edpmay]

Hi all,

I have a question about a funny effect I am getting on a recent Honeybee project. I have a simple rectangular skylight (flat horizontal) on a funny shaped zone (i’ve stripped away everything else in the model so its easier to see here)

Most everything is working fine except that for some reason the window is being split up into two triangular ‘FenestrationSurface:Detailed’ objects in the IDF file? I am certain that it is going in as one surface, but when I take a look at the IDF its clearly been split into two separate 3-vertex window surfaces:

It all simulates fine but I’m wondering why this is occurring? In order to be able to have clean output results (for when graphing window-by-window radiation values, etc…) it would be preferable not to have windows split into two if it can? I have tried to simplify the window curve, ensure its a true rectangle, ensure its planar, etc… but it keeps wanting to split this one up?

If anyone has any advice on what I can do to model it properly so that it will not triangulate like this I would very much appreciate it.

file attached with stripped back set-up of the offending geometry:
Triangulated Skylight_180814 [Internalized].gh (541.7 KB)

thanks!
-Ed

[devang]

Hi @edpmay,

Thank you for sharing a clean and minimal version of your file. This is much appreciated. In your model,

Red = Walls
Green = Underground Ceiling
Blue = exposed Floors

I believe you need to work on the surface types. Please carefully define walls, floors, roof, exposed ground, etc. You should use Honeybee_HBSrfs component to do that. Also, make sure that all the surfaces make a closed Brep. I will also recommend dividing in floors. (The building looks like a two storey building). Also, try to setup zones as per use. One zone per floor seems like a gross simplification.

If you setup the surface that receives the window as a roof, the child surface (window) will be assigned as a skylight in one piece.

[edpmay]

Hi @devang,

Thanks so much for taking a look at this!

Those are all super suggestions thank you. To your specific points:

1. To your point about using ‘createHBSrfcs’ instead of Masses2Zones: I’ve done as you suggested in the new version of the sample file here. I’ve created individual surfaces, tagged them with their relevant data and combined into an HBZone which is actually how I’m doing it in in the real version of the project (for the example file I’d just simplified it, perhaps a bit too much though).
   

   

2. The skylight object is hosted on the surface named ‘Roofs’ (not very creative I know…) and is coming into the IDF as a ‘roof’ Surface Type properly, as far as I can tell.
   

   

3. Re: the zone, yeah its a funny one - this is actually one zone of a multi-zone ‘church’ / mixed use project - this is the lower double height space with the funny church tower but sticking up… the other 4 zones stack on top of this one and a core to the rear (its an urban infill project). So yes, it actually is double height and its one big open space for the church services.

4. I’ve got a ‘check’ in there to confirm it is a closable Brep which is (seemingly?) is. And the HBZone itself seems to generate properly:
   

   

5. Even with the inputs as I’ve described and you recommended though I’m still getting a triangulation of the skylight surface into 2 separate, three-vertex fenestration objects when it goes into the IDF?
   

   

I’ve attached the reworked GH file which uses ‘createHBSrfcs’ as you recommend as well as the IDF for reference if you have any other thoughts?

thanks so much for taking a look though!
best,
-Ed

Triangulated Skylight_180816 [Internalized].gh (549.6 KB)

in.idf (118.9 KB)

[devang]

Thanks @edpmay,
I checked the new file. Works fine. You were right. The skylight surface was being split into two triangles in the idf. One solution is to align the skylight with the cardinal axis of Rhino like so.

When I did that, it did write as one surface in the idf.

[mostapha]

Interesting! If the surface is planar it should not be triangulated. We should take a closer look.

@edpmay, If you use Honeybee components to load the results it does manage to merging the results for sub-surfaces and output the final value as a single number.

[devang]

Thanks for joining the thread @mostapha. That should address @edpmay’s concern.

[edpmay]

@mostapha @devang

Thats great - thanks for the pointers there. Nice to know that the readEPSrfResult puts them back together properly at least. I was making some of my own CSV reader / slicers and so hadn’t been using that component but good to know it manages this properly.

I’ll try and keep em’ orthogonal where I can. Thanks!
-Ed

[RafaelA]

Are there any updates on this one?

I´d be very helpful to have the option to disable or override the automatic triangulation of windows - mostly in those cases that require precise control of window names (the Airflow Network in my case).

[mostapha]

Hi @RafaelA, It looks like the EnergyPlus 8.7+ is handling non-rectangular windows (https://github.com/NREL/EnergyPlus/pull/5920#event-839294132) as long as they don’t have more than 4 vertices (https://github.com/NREL/EnergyPlus/issues/6534). This is something that we are already considering for the new libraries not to triangulate the windows if they have 4 vertices or less.

cc: @chris

[edpmay]

Hi All,

I just wanted to revisit this discussion as I’m running into a new and different issue which is even less ideal than before. I have a very simple bldg with some skylights, and as usual its triangulating them in the IDF which is not great, but manageable as outlined in the thread above. But this time it seems to be actually mixing up the triangles so I can’t even put them back together again properly.

I’ve stripped away everything except the problem in the attached example files. Simple skylights on a roof plane (rectangular, nothing fancy at all)

In the IDF, its triangulates as expected, but then it actually allocates 3 of the triangles to one skylight, and only 1 to the other???:

If I pull the IDF vertices from each srfc back in to gh and rebuild the outline you can clearly see its mixed up the pieces:

Does anyone have any idea how I can fix this / overcome this issues? This is, for obvious reasons, not great and is causing problems for my model results. Any workarounds for this that anyone has found? I’d love to know if so.

Internalized sample GH and IDF result file attached for reference.

I appreciate any help or advice!
best,
-Ed

Skylight_Triangualtion_Example.gh (562.5 KB)
in.idf (98.6 KB)

[mostapha]

This looks like a bug. There is a is_rectangle method that does this translation. If you uncomment that check you will get the original rectangles. Let me know if you couldn’t find the solution and I will try to take a look. Cheers.

[edpmay]

Hi @mostapha,

Sorry - I should have posted an update to this. I was able to get it to work properly by hosting each skylight in a separate roof surface. For whatever reason when I do it that way it properly sorts the elements fo the skylights. So I just split the roof into two srfcs:

thanks!

• @edpmay

[edpmay]

@mostapha

To follow up a little more. I looked into the isRectangular() method as you pointed out and it looks to me that its just a matter of the tolerance being used during the evaluation? On any surface thats rotated off world axis it seems that it has a very, very slight discrepancy and so is resolving to False when checked for rectangular:

I added in just some prints to see whats happening, note that for this example window the diagonal check resolves to False since Diagonal 1 is: 1.43794697507 and Diagonal 2 is: 1.43794733329… that seems like a tolerance thing to me though not an actually non-rectangular surface, would you agree?

The corner vector angle checks resolve to 90.0000133771 degrees and 90.0000161866 degrees respectively. It seems to be that again thats a tolerance issue, not an issue of a non-rectangular shape.

I suppose the real issue is that for this check we’re comparing floating point numbers here, right? Is there a rule that you follow already for that sort of thing in the code used here? I notice that the Rhino Units Absolute Tolerance is used in a couple spots already? Would you use that here somehow as well to limit the tolerance of the check?

It seems to me that if the tolerance on this test was adjusted, then the isRectangular check would stop mistakenly forcing so many triangulations of windows for off-axis surfaces such as skylights?

seem right to you?
best,
-Ed

[edpmay]

Following up (again… sorry for multiple posts in a row here). I tried editing the Honeybee_Honeybee core defs to take into account the Rhino Model tolerance (as appears to be done elsewhere in the core defs). This seems to handle the issue well in my case at least.

If we just change the isRectangle checks around line 6440 to something like:

tolerance_len = sc.doc.ModelAbsoluteTolerance
tolerance_deg = sc.doc.ModelAngleToleranceDegrees

check1 = abs(ptList[0].DistanceTo(ptList[2]) - ptList[1].DistanceTo(ptList[3]) )
check2 = abs(90 - math.degrees(rc.Geometry.Vector3d.VectorAngle(vector1, vector2)))
check3 = abs(90 - math.degrees(rc.Geometry.Vector3d.VectorAngle(vector3, vector4)))

if check1 > tolerance_len or check2 > tolerance_deg or check2 > tolerance_deg:
    return False
else:
    return True

then that seems to work well.

And if I make an intentional non-rectangular surface, it seems to find that correctly:

When I replace the old checks with these new ones, in my case here the triangulation resolves and I get good rectangular windows in the IDF now:

best,
@edpmay