Determine the number of node typologies on a steel structure

[Rui_Carvalho]

Hi!

I am currently working on a steel structure project and facing a specific challenge that I believe your expertise in Grasshopper scripting could greatly assist me with.

I have a steel structure with various steel profiles, and I am looking to develop a Grasshopper script to determine the number of node typologies within the structure. My primary concern is not the angles but rather identifying nodes based on the number of connected bars (2, 3, 4, or 5) and filtering them by different sections.

Example: Consider a simplified structure with nodes (A, B, C, D, E) and bars connecting them as follows:

• Node A is connected to nodes B, C, and D through bars.
• Node B is connected to nodes A and C through bars.
• Node C is connected to nodes A, B, D, and E through bars.
• Node D is connected to nodes A, C, and E through bars.
• Node E is connected to nodes C and D through bars.

Now, let’s assume there are steel sections assigned (HEA100, HEA 200, IPE 200, IPE330 etc) to each bar connecting these nodes.

Script Objectives:

1. Identify nodes with 2, 3, 4, or 5 connected bars.
2. Filter these nodes based on the assigned steel sections.

I would greatly appreciate your assistance in developing a Grasshopper script that can achieve these objectives. Your expertise in this matter would be invaluable to the success of the project.

Thank you in advance for your time and support.

[fcegnam (Fernando Ceña)]

Hi,

what about something like this? I am assuming that the profiles can be considered as straight lines, so you only need to analyze the intersection points (the nodes). I do not know which initial setup you have, so I hope the profiles can be analyzed as individual lines. If not, I guess there is a workaround .

Then I am placing a sphere as representation of the node and I calculate how many intersecting lines the sphere has to filter the nodes by colors based on the number of connections.

Node typologies.gh (12.6 KB)

[Rui_Carvalho]

Thank you for your response Fernando. I’ve added the geometry and its associated code to the attached file. you code is not able to identify each different node for this structure. I think is because the diferent number of connections.

Node typologies_geometry_2.gh (22.1 KB)

Also, I would like the script to:

1. "Add section names to bars to script. Run the script to identify different connections. For instance, I would like each connection with the same conditions (same number of bars and sections) to be named, for example, DC-03. However, for each variant, even if they are the same, assign names such as:
   DC-03_01 -HEA340 - IPE 300, IPE300, IPE300 (main element - secondaire elements)
   DC-03_02 -HEA340 - IPE 300, IPE300, IPE300 (main element - secondaire elements)
   DC-03_04 -HEA340 - IPE 300, IPE300, IPE300 (main element - secondaire elements)
   DC-04_01 -HEA340 - IPE 300, IPE300, (main element - secondaire elements)

" (List of sections in the file)

2. Identify the different connections in the model and also in a text file to export to Excel. In this table, I need the connection numbers and the list of sections.

3. In some cases, some bars connect other in a midle position without node. How this can be handle? ( for example, column nr 1)

Thank you very much

[fcegnam (Fernando Ceña)]

Hi,

I fixed a little the script to get a result close to what you want, but I have to say that achieving everything you want will require a much more sophisticated script/code .

You will need to play with the graphics to get something to your liking.

1. Now the nodes are organized properly with your geometry, you can see the number of connections.
2. You can display now the names of the profiles on the bars.
3. You have a list of the nodes with the bars that are on each node.

The script is missing these:

1. Identify the nodes that contain the same profiles but different orientations.
2. Locate the nodes that are a result of intersecting bars. I understand that you are defining the bars from some initial nodes, but then you may need to consider that the list of nodes has to be rearranged later again to include the new nodes that are generated as a consequence of the intersections. And later, you would need to split the corresponding profiles at those nodes.

My understanding of what you need is that this is a really complex workflow and you may need to consider developing this in smaller stages, without forgetting the general idea.

Node typologies_2.gh (35.7 KB)

I hope it helps (although I understand that this does not solve everything you need ).

[Rui_Carvalho]

Thank you Fernando.

You’ve helped a lot.

I think that now that I have a list of all the nodes and the sectios per node. Wouldn’t it be simple to quantify the number of nodes, not only by the number of members, but by the different types, taking into account the profiles that converge there?

Example, give a different number for each node with 4 members, as long as the profiles are not the same.

I undestand that compare the position/angle is a litle bit tricky. But maybe its possible comparing the somatory of the vectores of each bar.

[Quan_Li]

Curve CP v0…gh (45.8 KB)

There are several network topology tools in GH, but none of them can solve your topology, simply because you have lines that do not end at the nodes. I made a new one, it can solve this case.

[PeterFotiadis (Pfotiad0)]

@Rui_Carvalho

I think that now that I have a list of all the nodes

This issue of yours is a typical case … where the pro solution is done via code.

1. Imagine that you have a Graph. Then you should find the classic VV, VE and EV Connectivity Trees (V for Vertices [Nodes], E for Edges [ Connections]). You should also find possible islands (Isolated parts of the Graph) using solely VV Conn (and Recursion).

2. Then you create objects (That’s what a Class in C# does) that contain info about all the above … plus the Name of the connection section (HEB, HEA, IPN etc).

3. Then you can perform any query (flat or nested) imaginable. Like “list” all the information available (in any imaginable way) or find all HEB’s with a Length within a given search Interval or find all Nodes with some given valence V that are connected at least with s Sections of Type t … blah, blah.

Shown 3 demo outputs (with focus on Nodes or Connections/Sections) where section Names are randomly assigned (obviously not the case in real-life … but I do hope that you get the gist of the whole thing).

If you want an entry level C# that does the above (say: BIM “like”) notify.

That said R/GH are NOT the apps for BIM adventures (nor they would ever be)

[TuomasLehtonen]

@PeterFotiadis

If you want an entry level C# that does the above (say: BIM “like”) notify.

I’d be interested in one. I am planning on creating my own solution to something very similar using C#, but it would be nice to get an alternative solution. That way I could learn more about it.

[PeterFotiadis (Pfotiad0)]

Get an indicative 4 C# combo.

The 1st gets Lines (as Graph) and does the Conn part (but NOT the possible Graph islands - that’s strictly internal stuff), the 2nd is solely for Vis Conn purposes, the 3d does the Node/Edge Classes (and assigns rnd section names/sizes to the Graph Edges) and the 4th reads the 2 Class derived Lists (as Type objects) unboxes their content (notice the same [to3rd] Classes definitions) and finally does 2 entry level - indicative - LINQ queries.

Note that each time the 3rd re-executes (rollTheBones slider) assigns randomly different sections (it’s just a very simple demo after all). So is paramount a separation between the 3rd and 4th C#.

As a challenge do various LINQ queries (and maybe a 5th C# for visualizing the results).

LineGraph_Conn_And_N_EINFO_Classes_Demo_V1.gh (176.4 KB)

Of course an on-the-fly section assignment capability is a must (i.e. swaping volatile to persistent data per a given C# execution) … but that’s another animal.

[Quan_Li]

Should the VE relations at the node also include line 64?

[PeterFotiadis (Pfotiad0)]

Not only 64 but the Line above as well. UNLESS line 64 has no end at that sphere of yours (the C# assumes that each line has at least a common pt with another - so it doesn’t prepare data by any means - i.e. “splitting” lines VS lines so to speak, checking for dupes etc etc).

See for instance (yellows are Polylines [so: not invited to the party] and then exploded to Lines);

Anyway post (in R5 format) that line combo of yours shown.