Hi everyone! As some of you may have noticed… we have now added structural classes to the default Objects kit! Many thanks to Arup (@daviddekoning, @jenessa.man) for leading this effort, and thanks also to the many members of the Speckle community (including @kelvin, @Rob, @MdeLeur, @pieter, @JdB, @dtnaughton) who provided their feedback and expertise during development. These classes will serve as the foundation for conversion routines used in upcoming structural software connectors (ETABS and Oasys GSA connectors that will be released soon , and SAP2000 and Trimble connectors down the line).
Flexibility is one of Speckle’s main benefits, and we took this as a guiding principle as we developed the structural classes, and–more importantly–the framework for their continued development. To allow teams to move forward with their own work while still contributing to a common structural data format, we borrowed a high-level structure from Figure 7 of the April 2020 buildingSmart Technical Roadmap. With this approach, the broadness of applicability of an object determines whether the object should be considered common and therefore appropriate for standardization. In other words, the “more generic and broadly used” an object is, the more it should be standard. The use of this hierarchy is intended to balance the “amount of consensus that can be reached, the adoption of the [classes], and how many specific use-cases” the classes can support (1). Application of this concept to structural analysis model data produces the hierarchy of standardization depicted below:
The hierarchy of standardization pyramid (or, the Amazing Technicolour Dream Triangle of Interoperability™)
The most basic information in a structural analysis model is geometry. Thus, the highest level of standardization for structural objects is geometry (the red layer). These are the Speckle structural object definitions, so we follow the geometry laid out in the
The next level of standardization represents the minimum information required to communicate the intent of a structural analysis model (the purple layer). This encompasses geometry-based objects (i.e. nodes and elements), loads, releases, restraint conditions, and material names and property names. Working with material or property names, rather than fully-defined material or property objects, lessens the burden on the user and the classes to identify and agree on the common definitions of material or property (as structural software take very different approaches in defining the material models and section profiles and properties they use!). This “layer” forms the basis of the new structural classes, and these items have been added to the
The next level of standardization applies to application-specific definitions (the green layer). These are objects which are native to specific structural software and allow completely lossless transfer to and from the same application (i.e. GSA-specific items like assemblies, application-specific material models). We have added portions of this “layer” to the classes in the
Objects.Structural.GSA namespaces. We expect users of particular software or developers of a particular connector to build and maintain the relevant application-specific definitions.
The final level of standardization (yellow) applies, of course, to the most specific entities - in this case, data specific to a particular project or client. These items are not suited to standardization and should be managed by each individual user on a case-by-case basis using Speckle’s powerful custom property mechanism.
These levels are not static and over time and we will continually review the developments in each layer to see what data and types are mature enough to move up to a high level of standardization.
This hierarchy provides enough common ground to allow different applications to communicate with each other, while still allowing them to move forward and innovate quickly!
Interested in a deeper dive into the (many) various structural data formats used in the AEC industry? Check out this recent blog post by @daviddekoning. These existing schemas were reviewed in writing the new structural classes.
Currently, the structural classes contain all required objects for specifying a basic, generic structural analysis model (including geometry, loading, properties, and materials information), classes for specifying an Oasys GSA structural analysis model, and some preliminary classes for describing general structural analysis results.
Explore the structural classes
- Model description & project info
- Model settings
- Model units
- 1D element
- 2D element
- 3D element
- Load case
- Load combination
- Node load
- Beam load
- Face load
- Gravity load
- 1D property
- 2D property
- 3D property
- Damper property
- Mass property
- Spring property
- Section profile (ex. ISection, Rectangular, Circular)
- 1D result
- 2D result
- 3D result
- Nodal result
- Global result
- Application-specific objects
How will the new structural classes fit in with the other components (ex. BuiltElements) of the Objects kit?
Currently, all geometry-based structural objects (ex.
Node) inherit from
Objects.Geometry class. All non-geometry-based objects inherit from the Speckle
Base class. We plan to add some structural objects which inherit from
Objects.BuiltElements class, but these additions are forthcoming (ex. a Storey object which inherits from the BuiltElements Level object). Conversion methods to/from
Objects.Structural objects and native objects will be added to support the translation of analytical elements (ex. Revit Analytical Stick or Analytical Surface) to structural elements in the near future as well.
As we continue to develop the structural components of the Speckle ecosystem, we hope to see the structural classes evolve to suit, and for this evolution to be informed and driven by the Speckle community. As with contribution to all other parts of Speckle, the golden rule is to discuss first! Before embarking on any development, make a post in the community forum to share the changes or additions you’d like to make. Be sure to tag @jenessa.man and @Reynold_Chan, who will be shepherding the whole set of classes to full maturity. Add a structural tag to the post so that everyone will get notified as well! We’ll discuss what’s proposed as a community and together determine how things will fit within the hierarchy of the object model and Speckle as a whole. Some of the key things we want contributors to think about are:
- Is the proposed addition/change generic and broadly applicable (ie. suitable for standardization, belonging to the purple layer), is it more specific to a particular software (ie. suitable for standardizing in the context of the specific software, belonging to the green layer) or is it specific to a project/client (ie. not suitable for standardization, yellow layer)?
- Is the proposed addition/change applicable to other definitions in the object model? Applicable across application-specific definitions? (If we want to add a property to the GSA-specific definition of a concrete material that is also applicable to the ETABS-specific definition of the analogous concrete material, should we also “promote” this property from the green layer of standardization to the purple layer add it to the base definition of the concrete material?)
Keep an eye out for upcoming Oasys GSA and ETABS connectors! If you’re keen to keep track of the ongoing development of these connectors, visit the GSA work-in-progress repo here and ETABS work-in-progress branch here.
Finally, as always, feedback is very much welcomed, so please go ahead and check out the new classes on GitHub and let us know what you think!
If you haven’t done so already, you can also set tags within your discourse user setting here. This way you can get notified of the structural classes and updates here:
- buildingSMART International. (2020). Technical Roadmap buildingSMART Getting ready for the future [PDF file]. Retrieved from https://buildingsmart-1xbd3ajdayi.netdna-ssl.com/wp-content/uploads/2020/09/20200430_buildingSMART_Technical_Roadmap.pdf