The structural engineering industry is an odd one. On one hand, we design incredibly complex buildings (and other structures) designed to withstand hurricanes, earthquakes, and other natural disasters. On the other hand, we use inefficient methods, procedures, and tools that were developed decades ago.

​

Why?

​

Much of it comes down to bureaucracy, internal politics, and a general unwillingness within our industry to accept change. Some of this can be attributed to our most important charge: the protection of human life. Should we adopt new and untested design philosophies, using the general population as guinea pigs? Probably not. But that doesn't mean that all change must come slowly.

​

The (not-so) low-hanging fruit.

​

Many methods we use to design buildings, although developed years ago, are built upon the fundamentals of mathematics and mechanics. But the analysis and design tools that were first developed to help engineers implement these methods have not advanced significantly since their inception. Building tools that have robust APIs, can interface with other software, allow user add-ons, have powerful user interfaces, and allow engineers to do their jobs efficiently seems like a reasonable request.

​

The birth of Fenix (and protoGen)

​

We decided that it was time for a change. The goal: to develop an analysis software as a plug-in to Rhino and Grasshopper that also integrates design capabilities. It had to be fast, efficient, and provide many familiar features while implementing new ones. It had to have a relatively open API that would allow users to build on top of it and interface it with third-party software. And it couldn't be a black box. There had to be plenty of program output, especially when it came to designing structural members. The result was Fenix.

​

​