Fire Engineering and Git

As a geek, Git is a fantastic program. Almost everything I write is in plain text, outside of the office (where I’m forced to use Microsoft Word). I wrote my doctoral thesis within LaTeX and Git allowed me to keep a fantastic record of the changes to my thesis as I went through my work, as well as providing a backup. Outside of work, I write occasionally for Micro Mart and of course I write these blog posts and others. I even journal and write a diary in plain text.

However, when I’m in the office, I’m expected to use Word, which is fine (but I hate Word with a passion - it’s a pain to do some of the advanced functions without taking my hands away from the keyboard and that slows me down). Whilst we use Word for writing our reports, we make use of the free Fire Dynamics Simulator (FDS) for modelling fires. And therein lies the beauty of FDS and Git.

Git

Git works well with plain text files, such as coding. That’s what it’s designed for. Browse Github and you’ll find various computer programs and project in a range of different languages, all of them written within a coding editor of some kind. Because it works with plain text files, it can be used to track changes within any plain text file and that’s where FDS comes in.

FDS stores it’s data in a single plain text file. You create the geometry of the fire compartment using obstructions and specifying the co-ordinates of the actual walls etc. This is obviously quite time consuming and tiresome (which is why there are third party solutions for building models, such as Pyrosim). Even though Pyrosim runs the models and builds them - at the heart of it all is that single FDS text file that sets out the model parameters - Pyrosim is just a glossy finish to it really.

So I’ve taken to using Git to store and track all the changes to my models. This works really well as you can see in the image below. Bitbucket even highlights some of the sections fairly well, which is quite impressive considering the syntax probably isn’t in the database! (I’ve blanked out the project name as it identifies the project and I don’t want that public).

I’ve taken to using Bitbucket, which lets me create a private repository where I can store my FDS files. Tracking is important from a quality management role - it’s important to show the external auditor that the data is being checked and that the models are being run properly. From a research point of view, the tracking allows all the changes to the model to be understood by a third party that may be reviewing or trying to replicate the results. Similar results can be gathered using Github. In fact, I host a Github repository for helpful FDS files and the like here. You’ll find a library file there (basically an FDS file that Pyrosim creates with a number of properties/materials/constants in, but no obstructions), with a number of properties specified, taken from literature.

The benefit of hosting this on Github is that the full history of the changes to the library can be viewed. From a research point of view, this is a fantastic help and means that all the changes can be checked off.

Another perk of storing these files in Git is that other users can then decide to either fork the data and use it themselves and make changes and they can also then merge the data with your own to help create an organised database of information.

Conclusion

Whilst a slightly technical method of storing FDS files, the perks more than makes up for the little effort required to learn Git. However, even this doesn’t have to hard - Github offer an easy to use Git client and Sparkleshare is a setup and forget solution. However, it’s worth learning the extra benefits of Git as it will allow you make the changes you need and add additional information (such as informative commit messages).

I should point out, that this applies to the FDS files and not the Pyrosim files - as these are a binary file, you don’t get the same benefits to storing these in Git as you do with the FDS files.