Back to Previous

Organising project data

This overview offers ways to deal with the complexities of information systems in large and small practices.

The ability to scale the management of data, to better categorise, find and share data across departments, disciplines and teams is becoming essential in modern design environments.

File names

The technical limitations (what is and is not allowed in a file name) of different operating systems relies on their chosen method of storing data. This does not mean the physical hardware, but rather a filesystem, such as FAT32, NTFS, exFAT, etc.

Each of these systems has different limitations on file names, for instance some may differentiate between upper and lower case letters, others may not. Each operating system will have detailed documentation explaining which characters are permitted.

Aside from the technical limitations on file naming, there are ways to name files to enable easy manipulation of data. It would be advisable to ensure file naming is BS1192 compliant. This would result in the following naming convention – details of which can be found in the relevant standard:

  • ProjectRef-Originator-Volume-Level-DocumentType-Discipline-Number-Revision-Suitability_Description_Date_Author.FileExtension

However, even if the relevant standard is not followed rigorously (as may be the case where interaction with other disciplines is minimal, or name limits are encountered) the file name should contain the following elements:

  • Date-Name-Version-Author.FileExtension

A useful format for dates is reverse size order (YYMMDD) which means folders ordered by name will always be listed in ascending or descending chronological order.

Ideally, a changelog (as described below) should also be provided to allow tracking of changes when the software itself does not have this capability.

Sensible folder structures

It is better to reduce the number of folders in a folder structure to around three or four levels at most. The most pertinent technical reason is because of file name lengths which can cause errors indicating that the file name has exceeded the allowed limit. This is most often related to the folder structure rather than the file itself.

Versioning

In software development, versioning and collaborative working is usually based on a framework called ‘Git’. Files are downloaded locally, modified before being ‘staged’ and then ‘committed’ back to the server they originated from.

The system allows for branching of different versions with different code bases and is completely auditable – with the ability to revert changes within a branch. ‘Commits’ are required to have descriptive names in order to prevent the problems often encountered when a strict naming convention is not enforced, ie a folder full of ‘file_update 1’ file_update 2, ‘file_new version(2)’, etc.

While there are projects currently attempting to implement such a system for structural models, drawings, etc. they are not yet mature enough for everyday use.

Whilst these systems are being developed, engineers should try to maintain a sensible structure for versioning, facilitated by naming structures as described previously to permit easy differentiation between versions.

Changelogs

A changelog is a file (usually plain text) that details the changes in a particular version of a file or program. They are often seen on websites or as a text file / message when installing an update to a program.

Changelogs include details of the latest software alteration, appended to the list of previous amendments allowing alterations to be tracked through versions of a model.

Structural models may be changed significantly between revisions, and it is good practice to note what these changes are, why they have occurred and who has made them.

Even if a single person is working on a particular model, changes can often be forgotten, resulting in potentially inaccurate results. This is especially true for cases where a single person has worked on a model for a significant amount of time.

It may not be practical to note down every single change between versions in exacting detail. If 50 nodes have been moved by a fraction of a distance, there is seldom significant change in the model or the outputs.

However, if a loading condition has changed, a load combination, members or releases removed or added, etc., these should be noted in a changelog to allow easy interrogation of results or comparison between different options within a structural scheme.

Related Resources & Events

The Structural Engineer
<h4>The Hornet's Nest pavilion - learning the challenges of full-scale construction from a digital model</h4>

The Hornet's Nest pavilion - learning the challenges of full-scale construction from a digital model

In 2018, BuroHappold Engineering and Studio X of the Hochschule Anhalt Graduate School of Architecture in Dessau, Germany, collaborated on the design and construction of the Hornet's Nest, a parametrically designed, temporary, timber pavilion assembled without the use of mechanical connections.

Date - 3 March 2020
Author - Alejandro Niklison, Sabine Mueller and Florian Foerster
Price - £9
The Structural Engineer
Digital skills circle

Digital skills for future engineers

Eighteen months ago, I was appointed the 'digital leader’ of the structural skills network within my firm. The insight I’ve gathered feels like it should be shared more widely. I hope you find something here that either gives you a starting point for action, or reinforces the course you have already charted.

Date - 2 January 2020
Author - Dan Clipsom
Price - £9
The Structural Engineer
Centaur galloping

The engineer of the future is a centaur

Digital technology has transformed structural engineering over the past 50 years. Now artificial intelligence, which includes machine learning, promises to do the same for engineering design and practice, especially for situations that are too complex for the current generation of programs.

Date - 2 January 2020
Author - Peter Debney
Price - £9