InteraKt

Checking beam columns is a task that all entry-level engineers are familiar with. After obtaining the loading and calculating demands, a beam column must be manually sized and checked for moment and axial interaction. Most tools that do this require users to manually input a size and then check, which can be cumbersome when an engineer is balancing both checking strength and making sure architects are happy with how deep the beam columns are. The goal of InteraKt is to give engineers a tool to parametrically select optimized beam-column shapes based on parameters of their choosing and to visualize the beam-column and interaction.

Intended users

Practicing structural engineers design beam columns every single day. This is a tool meant to assist with early and intermediate phases of the design of steel structures or for students when learning about beam-column interaction. Currently, AISC Manual interaction tables, hand iterations, and spreadsheets are used to do this, all of which evaluate a single trial section at a time and give the user no broader set of solutions. interaKt seeks to give the user a parametric sweep of valid solutions, ranked by a metric of their choosing.

Need you’re trying to provide a solution or support for

Sizing a steel beam-column under combined axial and flexural demands is a very common but inefficient task. The standard workflow includes scanning the AISC Manual’s interaction tables, iterating by hand, or running a one-off spreadsheet. All of these involve evaluating a single trial section at a time and do not offer a holistic view of a solution set/space. Analysis packages like RAM or RISA only check the section after users have already chosen it. InteraKt addresses this gap by evaluating every W-shape in the manual against user demands and returns a ranked set of valid options so the user can make an informed decision.

Inputs

Required axial compression (Pu, kips), required flexural strength (Mux and Muy, k-ft), effective lengths (ft), and LTB modification factor, steel yield strength (36,50, 65).

Underlying logic of the model you’ll implement

For each W-shape in the AISC shape database, interaKt will compute the axial capacity, flexural strength (in both the strong and weak axes), and interaction for the demand-to-capacity ratio. For capacity checks, limit states considered will be flexural buckling and for bending in the strong axis, lateral torsional buckling, and plastic bending. Sections with a DCR at or below 1.0 are flagged as valid, and the valid set will be sorted by weight. The lightest options are returned along with their governing equation and limit state.

For the purposes of efficiency, the large brunt of these computations will be done in the Py3 component in Grasshopper. While this may defeat the purpose of “visual programming” to some degree, the complexity of these calculations warrants this. Decomposing these calculations into dozens of wired native components would replicate what a single script component does cleanly, at the cost of readability and reliability. Additionally, this is still a parametric study, and other components of this project show graphical and geometric output that responds live to the input parameters. The section selector itself is fully parametric: every slider input (axial demand, biaxial moments, effective and unbraced lengths, and yield strength) propagates through the model and updates the results in real time, exactly as a slider-driven Grasshopper definition is intended to. The Python component functions as the computational engine, while Grasshopper provides the parametric interface, the live geometric visualization of the selected cross-section, and the interaction diagram output. In other words, the visual and parametric character of the tool comes from how the user interacts with it and sees its results, not from artificially decomposing well-structured code into a sprawl of native components that would only obscure the underlying logic and make the tool harder to use, document, and maintain. This mirrors standard practice in computational design, where script components handle algorithmic logic, and the canvas handles parametric control and geometry. The two are complementary, not in competition.

Outputs

A ranked table of the five lightest valid sections, each listed with its weight, nominal depth, DCR, and governing limit states. A bar chart can show the lightest valid section at each nominal depth, colored by DCR margin, making the weight and depth trade-off apparent. Interaction diagram plots can also be fabricated.

Timeline

• Week 1: overall architecture and debugging Py3 components
• I need to finalize and define what my tool is going to do. I currently have a rough idea of what I want it to output and visualize, but its not yet finalized
• The Py3 scripts are going to be the backbone of this tool. They are going to provide the sweep and analysis that Grasshopper is going to use to visualize and express as geometry. The coding for the actual AISC code components shouldn’t be too bad, but I am not familiar with how to get the outputs for these components into terms that are digestible for Grasshopper. This will take the most amount of time and I will definitely need to debug these components.
• Additionally, since I am pulling data from an AISC shape database, I need to figure out how to create curves from the database. Perhaps another Py3 component specifically to express the data as curves digestible for Grasshopper.
• Week 2: Work on Grasshopper.
• I need to visualize the swept sections as geometry in the Rhino viewport. The Py3 solver will output the top-ranked W-shapes as parallel lists of section dimensions (depth, flange width, flange thickness, web thickness), and a second Py3 component will translate those dimensions into closed I-shape curves that Grasshopper can render.
• I will use native Grasshopper components for the visualization and interaction layer: Custom Preview to render the sections, a color gradient driven by each section's DCR to show utilization at a glance, and Text Tag 3D components to label each section with its name and governing metric.
• I need to implement the metric toggle so the user can re-rank the design space by weight, DCR, or depth using a native Value List, and confirm that toggling it updates both the ranked output and the rendered geometry live.