Make number of vertex neighbors (eperv) compile-time variable

[raovgarimella]

I am trying to ease the restriction of having only trivalent polyhedral vertices in R3D and seeing what effect that has on performance of the Portage code. Basically, we almost always give R3D polyhedra with non-trivalent vertices and it has to duplicate the vertices in r3d_init_poly. This seems to take a lot of time.

My thought is that if we make the number of edge-connected vertex neighbors a larger compile time variable (R3D_MAX_NBRS) so that the loops are of static length allowing the compiler to unroll the loops, then we won't be spending as much time in r3d_init_poly

I am able to refactor most of the code but am having the darndest time understanding what the duplicating vertices function is doing in r3d_init_poly. Any hints on how to expand this to rewrite this part?

[devonmpowell]

Hi Rao, thanks for your patience with me just now getting back to this issue.
It has been forever since I wrote this bit of code. But basically, it takes a group of four or more edges that meet at one vertex, and creates a "cluster" of trivalent vertices (with identical positions) in order to emulate a single vertex with the required number of edges. All the complicated logic in that function is to figure out how to connect all the length-zero dummy edges between those duplicate vertices, so that the three-connected-planar-graph criterion is still satisfied.
I would say that if you are relaxing the three-edges-per-vertex constraint, then you can ditch this bit of code entirely. You just need to make sure that the edges are ordered correctly around the vertex.
I hope that helps!

[raovgarimella]

Thanks and no worries. I had to pause the work for a while as well. I don't know whether we can get rid of the logic entirely since I don't think I want to put a cap on the maximum number of edges an input vertex might have. I just want to allow for groups of N edges coming together at the vertex (maybe 6 instead of 3). So sadly, the logic to split the vertices and reconnect them still has to be there. We'll figure it out - Rao

…

________________________________ From: devonmpowell ***@***.***> Sent: Friday, March 22, 2024 1:09 PM To: devonmpowell/r3d ***@***.***> Cc: Garimella, Rao ***@***.***>; Author ***@***.***> Subject: [EXTERNAL] Re: [devonmpowell/r3d] Make number of vertex neighbors (eperv) compile-time variable (Issue #36) Hi Rao, thanks for your patience with me just now getting back to this issue. It has been forever since I wrote this bit of code. But basically, it takes a group of four or more edges that meet at one vertex, and creates a "cluster" of trivalent vertices (with identical positions) in order to emulate a single vertex with the required number of edges. All the complicated logic in that function is to figure out how to connect all the length-zero dummy edges between those duplicate vertices, so that the three-connected-planar-graph criterion is still satisfied. I would say that if you are relaxing the three-edges-per-vertex constraint, then you can ditch this bit of code entirely. You just need to make sure that the edges are ordered correctly around the vertex. I hope that helps! — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/devonmpowell/r3d/issues/36*issuecomment-2015743454__;Iw!!Bt8fGhp8LhKGRg!CpTS2lTIEoOyVuN_UmS-diekV7n8KshmTcQ9n6LktxMkUfaa6vvSl-sFNlCtBFF2r9jRdJ0wJFL6P3SU6FFysA$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AEBAZQB7P3O6GDFWASMCZALYZR6VNAVCNFSM6AAAAABEORMI7GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJVG42DGNBVGQ__;!!Bt8fGhp8LhKGRg!CpTS2lTIEoOyVuN_UmS-diekV7n8KshmTcQ9n6LktxMkUfaa6vvSl-sFNlCtBFF2r9jRdJ0wJFL6P3SUHLwLpA$>. You are receiving this because you authored the thread.Message ID: ***@***.***>