Back in November 2009 we ran the first Arup HackDay. During HackDay people from around Arup gathered to create new tools and mash data over a 24 hour period. One of the tools created at HackDay by Andrew Tsakmakis was re-purposed to create the Secret Lives of Projects.

I’ve long been interested in project-based organisations and how new knowledge can be transferred from one project to another. The Secret Lives of Projects is a visualisation of the content created during an Arup project. It is a thought piece around the question “What is the shape of a project?” and an attempt to visualise some of the patterns of content creation as we work on projects.

The original tool was developed to index data with several features for quick searches. We did some more work after HackDay and pointed it towards a project directory. We then extracted meta-data from email archives and files. People in the email archive were identified and their business units and locations matched. We then linked billing data.

In the excerpt from communication network (below) the nodes reflect a pattern of communication through the project as people email each other. Nodes with yellow or blue dots grow as they bill time and so a picture emerges of who is speaking with whom and who are the key players working on the project. If this tool ran in real-time on your desktop could you tell if people were in the loop or not?

We worked with Greg More from OOM Creative to build an application using Adobe AIR and Flex. The video shows some of the visualisations from the AIR application.

The DesignLink Software Development toolKit (SDK) is now open via a collaboration agreement. DesignLink is designed to assist in the development of software to solve interoperability problems between various programs used in the built environment (AEC) design process.

Here is a link to an earlier post and DesignLink’s ArupForge page lists some of the software packages and processes we’ve already tackled. Its open now to extend and contribute.

Following are two videos of DesignLink in action. The first shows the use of Octave/Matlab to drive the generation of EnergyPlus and Radiance files from a GenerativeComponents model. Then Paul Jeffries from Arup AGU shows his Rhino3D to GSA tool called Salamander.

Contact us for further information.

For the past two years I’ve been part of an Australian Government funded research team exploring the theme of Delivering Digital Architecture in Australia, investigating issues such as architect/engineer communication, data interoperability and lessons from parallel industries.

Early in the research we gathered information about data interoperability experiences from our staff and collated it into an Interoperability Database. This revealed some basic approaches to interoperability problems:

Use an import/export tool written by a software vendor.
Write your own tool to do the data transformation Depending on the particular tool, these approaches can be characterised as either a Scalpel or a Swiss army knife.

Scalpel A tool that links two particular pieces of software (e.g. GSA to Revit)

Pros:
• Specifically designed for the task, often giving the best results.
• Can be optimised to deal with cross-discipline or “geometry + analysis data” transfer.

Cons:
• Can limit the choice of design tools.
• Causes problems as the number of design tools increases.
• Some user written tools prove difficult to share with others.

Swiss Army knife A more general purpose approach, using an exchange file format such as IFC.

Pros:
• Generally industry funded, based on well designed and documented formats.
• Often provided by software vendors as a feature in their products.

Cons:
• Might not meet project data requirements, and may not be easily extendable.
• Currently best suited to “documentation/co-ordination” data rather than “design/analysis” data. As part of our research we are proposing a third possibility, which solves some of these problems but, as with any solution, also has its downsides.

The DesignLink Software Development Kit (SDK) – a meta tool for building tools.

The DesignLink SDK combines a data exchange format with the routines needed to read/write that data to various applications or file formats.

The DesignLink SDK can be used to build tools to solve interoperability problems as well as custom tools to use in the design process. It’s this ability to use the SDK as a platform for building custom design tools that sets it apart from other data exchange toolkits. Since these custom tools share some common DNA, it will be easier for programmers to share useful code. They also benefit from being built on a platform that includes:

• inbuilt testing routines
• easy methods for people to contribute ideas or code, without needing a degree in software development
• a community of programmers and users to review and improve the code

The types of tools that can be built with the SDK include programs to enable designers to connect parametric geometry models to engineering analysis models, allowing them to explore more design options; and custom written programs that perform design processes such as member size optimisation and design code checking.

We recently showcased DesignLink at SmartGeometry 2009 and I’m currently in the process of testing DesignLink on project and planning the next steps, which might involve Collaborative Licensing to further develop the SDK.

The use of custom tools can improve efficiency, especially when handling large structures with thousands of elements. One of the most useful tools I have recently developed is a strength based optimisation program that links with Arup’s in-house structural analysis software Oasys GSA through its API (COM interface).

The COM interface uses Visual Basic (VB) scripting and allows remote access to most of GSA’s functions, enabling the user to drive GSA externally through programs such as Excel. This means the user can automate calculation intensive processes and handle large amounts of data in an efficient manner.

While working on a multi-billion dollar project in Singapore, I was faced with the challenge of analysing and designing several large steel structures with highly complex geometric form and 5000 plus elements in each structural model. I initially developed this tool merely to deal with the sheer number of elements that were required to be analysed, designed and sized.

Later, I saw the potential for expanding its use by incorporating an optimisation routine. This was achieved by running a computer automated numerical algorithm to determine the least steel-weight of the structure while still satisfying the relevant design codes.

The optimisation algorithm will not attempt to modify the geometric form. Instead, through an iterative process, the sizes of the structural elements are continuously substituted (from a user selected pool of sections sizes), analysed, designed and resized based on the results of the analysis, until the structure with the least steel-weight is found.

It is also possible to calibrate the algorithm for different optimisation criteria. For example, an alternative criterion to the least steel-weight solution could be shallowest depth solution, least cost solution or fastest procurement solution, or a combination.

I have used this optimisation tool on two other projects. In these cases it was used for rapid design and member sizing of various scheme options and allowed the design team to quickly assess the most economical design options.

Not only was this an effective and highly efficient method of managing the data from large structural models, it also offered the opportunity to fine tune the steel weight of the structures, resulting in potential cost savings.