Skip to content

Instantly share code, notes, and snippets.

@m-clare

m-clare/speckle_systems.md

Last active May 10, 2022 16:19
Show Gist options
  • Save m-clare/9d8b23fe2058b2ab994d32fe174fb861 to your computer and use it in GitHub Desktop.
Save m-clare/9d8b23fe2058b2ab994d32fe174fb861 to your computer and use it in GitHub Desktop.
Download ZIP
Speckle Technical Interview
Raw
speckle_systems.md

Speckle Technical Interview

Task 1

Build & debug ETABS connectors - review functionality and implementation

  • Tested against Speckle for ETABS v2.51
  • Using ETABSv20 (trial version)

Build Info

  • Successful build (no compile errors)
    • did have to reset in Visual Studio to target only x64 rather than Any CPU to surpress set of warnings
  • Compiler warnings (NOTE: significant number of documentation warnings outside of ETABS project / CSI solution - mainly in Core)
    • CS0162 Unreachable code detected in ConverterCSI.cs
      • Logging occurs after return for all the cases in the switch statement (can never be logged)
    • CS0219 The variable $VARIABLE is assigned but its value is never used
      • Convert2DProperty.cs
        • return value of Property2DToSpeckle is null, so all specified properties are not used
      • cPlugin.cs
    • CS0436 The type 'ConnectorBindingsCSI' in C:\...\ConnectorBindingsCSI.ClientOperations.cs' conflicts with the imported type 'ConnectorBindingsCSI' in 'DriverCSharp'... Using the type defined in 'C:\...\ConnectorBindingsCSI.ClientOperations.cs'
      • This overwrite seems reasonable, but would need to look closer at the differences

Usage Info

  • NOTE: ETABSv20 uses the same API as v18 and v19 so code changes should be minimal for v20 support (if any are required...)
  • Test send cases using ETABSv20
    • push all objects - hangs and never times out (infinity loading) - no partial pushing
    • successful push beams (select by category) - commit
    • successful push beams / columns / braces (select by category) - commit
    • successful push All (by group) - commit
      • includes 4 CSIElement2Ds
    • cannot push areas (by category)
    • cannot push other abstract data types (all loads, anything non-physical, by category)
    • cannot push load patterns but generates Report log - zero elements successfully converted
    • Speckle.Geometry appears to be only elements currently supported
  • General question: is it possible to create a test file with a series of commits for testing purposes? Txt file may not currently have enough information for this.
  • No mechanism for batch pushing (i.e. chaining different commits while offline? This seems feasible given the txt file generated)
  • Advanced settings - what is the use of this?

General Notes

  • Dark version for CSIAdd-on is difficult to see loading graphic (in terms of an animation happening) - text box for commit message is also similarly hard to see
  • How is the user warned if certain properties are not a part of a specific software type (i.e. data is "lost" when pushed from speckle to ETABS, since ETABS lacks the ability to attach custom fields or properties)
  • Attempting to retrieve ETABS objects within Grasshopper (any of the above commits) results in a deserialization error 1. A deserialization error has occurred: Cannot deserialize System.String to System.Double: Cannot deserialize System.String to System.Double
  • Web viewer does not appear to have any information of pushed types other than geometry currently (no structural information)
  • Inconsistent naming in source code - several instances of naming against Speckle2ETABS rather than Speckle2CSI (this is also an issue in the docs, which results in several broken links)
  • Attempt to utilize Excel plugin to inspect Speckle stream data failed at authorization stage (Browser or app may not be secure).

Task 2

Structural Object Model - review implementation and how/if change improve it

  • 4 Tier Hierarchy (lower tiers more complex)
  • Holds to Speckle's standard for minimum information for describing objects (avoid explicit derived properties)

1. Information required to render geometry

  • Geometry - per Speckle default Objects kit and geometry classes

2. Minimum information required to understand the model (as a structural analysis model?)

  • Nodes, Elements, Releases, Loads, Material Names, Section Property names

3. Information required for lossless transfer between two instances of the same software

  • Materials, sections properties, All candidate properties for including in the standard should be here first

4. Information required for specific / custom workflows

  • Discussion around this level and the previous one seem to be focused on where conversion from one structural software to another should exist in terms of methods and support

General Questions

  • Where does connectivity exist in this hierarchy? Based on the initial notes, I think it would be in Tier 2, but connectivity exists in different contexts
    • Connectivity for addressing which elements are connected to which nodes, and which areas are connected to which beams (and how they are connected)
    • Connectivity for addressing how properties are attached to structural elements. In a graph database you'd say a beam -HAS A- section -HAS A- material. One of the challenges with some of the structural software is that specific properties can be attached to different element types. In CSI products, you can attach section modifiers to areas or lines (beams) OR you can attach them to materials. Doing so for both does not lead to overriding the properties, and instead ends up multiplying them (you'll get a significantly more flexible section if you do so!)
  • In terms of Tier 3 - this is where automated testing really needs to come in. CSI products write to a specific output file that is human readable. You'd need to verify that diffing these files results in no differences (Similar in other structural softwares.
  • Current tier/hierarchy doesn't touch on other elements of structural analysis -- largely a global building/bridge approach, like high fidelity modeling where you might look at a specific part that's zoomed in as part of a structure
  • Other potential issues with results in terms of dynamic analyses and the level of detail/information that could/should be serialized by Speckle (can be many GB of data for time histories)
  • I'm guessing that mesh storage would be in either Tier 2 or Tier 3, but I'd lean towards it being in Tier 2, as some software programs have significantly better meshing capabilities than others and it should be an elevated common class if possible (anything to get around the terrible automesher in CSI products...).

Task 3

Design a feasible workflow with Speckle between architects, structural, BIM, and contractors

image image

Task 4

If you were to develop a brand new Speckle connector, what would it be?

As a structural engineer, I have a lot of experience with a variety of analysis software (including SOFiSTiK, LUSAS, and RISA, which are currently not available), but the current pantheon of Speckle connectors has over 50% tools that are used or could be used by structural engineers. Within AEC groups, I see the biggest gap in terms of current connectors on the construction/contractor side (likely only served by Excel and Power BI). As a result I'd recommend a connector with a broader impacts, either Procore integration or integration into a sustainability based connector like EC3.

Procore Connector

Benefits
  • 1 million users nearly a decade ago (2015)
  • 2 million+ users today
  • widely used for tracking RFIs and documents on projects
  • Standard API (REST) with Authentication
  • Estimation integration is low hanging fruit due to takeoff quantities easily enabled by Speckle
Risks
  • Speckle is most active for supporting workflows in preconstruction currently
  • Construction data doesn't necessarily "fit" the current Object model, significant work might need to be done here to figure out the best way to serve users
    • would need further research of the existing app types and how Speckle might fit into the app ecosystem
    • Construction firms are notoriously secretive about their data, would be important to show how Speckle can allow for privacy.
  • Scope of this type of integration could creep significantly. Speckle isn't a platform for organizing documentation and contracts.
  • Unclear if developers have access to all of Procore's base products (license may be $$)

EC3 Connector (or Sustainability Related Plugin)

Benefits
  • Standard API (REST) with Token Based Simple Authentication
  • Significant community and industry interest in reducing friction for creating LCAs on projects
  • Completely free and open access
  • Very interested development team
  • Tagging materials on Speckle objects pretty easy for takeoffs
Risks
  • EC3 only covers first stages (A1-A3) of Life Cycle Assessment (however, in talking with the developers, the long term goal is to provide complete LCAs similar to OpenLCA)
  • Environmental Product Declarations (EPDs) have poor documentation (in general, this isn't unique to EC3) and get back to the issue of Speckle not being a platform for organizing documentation (yet?)
  • Does require registration with EC3 (not completely open source)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment