The world of engineering has been becoming progressively more digital; with monstrosities such as ProjectWise entering the common vernacular (verb. to make someone else’s document control your problem). As such, being able to make a computer sit-up and dance (metaphorically, of course) is likely to make your life a much brighter place. So this week, I thought it would fun to share some tips of direction for engineers who find themselves tempted by the dark-side of automation…

Get Yourself A Good Editor

It is a depressing fact that a lot of the programming Engineers are exposed to are scripting languages; and as such they tend to discover that Notepad will open most script files and then stop. This is akin to discovering the ‘+’ button on your calculator, and leaving it at that. Your programming life will be substantially improved if you pick-up an editor that was written after 1985. To help you along, here are three free (and typically portable*) editors I’d personally recommend:

• NotePad++ Probably the easiest, it’s like NotePad, but with all the pretty colours (syntax highlighting) that make life in another language so much easier.
• Sublime Text This is my editor of choice, it’s a little more advanced than NotePad++, and thus a bit more complicated. But with a plug-in system you could drown in, and the ability to write in multiple places at once; I’d say it’s worth the learning curve.
• Visual Studio Express If you find yourself getting hardcore at programming, Microsoft give away a cut-down version of their professional programming software. It should be noted that Visual Studio is pretty much the only Microsoft package I have anything nice to say about…

*Portable Apps are those that anyone (even without administrative rights) can install on a computer. I definitely forbid you from looking at PortableApps.com where you won’t find a range of applications that fill every one of those needs your IT Administrator has been needlessly blocking for years…

Learn By Doing

Just as Blain in Predator ain’t got time to bleed; I expect that most engineers ain’t got time to learn. This is where the wonder of recording comes in. A lot of software that provides automation allows users to ‘record’ what they’ve done straight into code. I see this a lot with Excel; and it is a good place to start. A word of warning, however, reading recorded code is pretty much the best way to learn some incredibly bad habits, and plays all too much into the “it works, it must be right” attitude that will quickly find you sitting in a high tower of code without any abstract foundations.

Choosing A Language

I expect the language that most engineers who have programmed used is VBA (this is the Visual Basic that comes packaged with the likes of Excel). VBA is very much like an old dog, it hasn’t learnt any new tricks in quite some time. This means that moving from VBA to another language can be a bit intimidating; especially when people start throwing words around like Generics and Polymorphism.

I’d say the two cool languages of the moment are JavaScript and C#, the former for web applications (which are a bit of a thing, it seems) and the latter for desktop development. The two friendlies languages I know are Python and Ruby, which are both fairly forgiving. If you want to stick with the world of VB, you can try your hand at VB.NET which is just similar enough to be entirely baffling, and VBScript; which is fairly archaic, but much closer to VBA.

Ultimately, for engineers, I expect most times you’ll be tempted to program you’ll be trying to automate from inside of something (e.g. Excel Macros), and then you’ll be tied in to using a specific language; although breaking out isn’t hard to do. If you find yourself doing something from outside a framework, however, I’d recommend pointing yourself towards Python (or C#, if you’re aiming for higher things).

Some Of The Magic Words

Just as Civil Engineering has it’s Larssen piles, arc welding and PPPs; programming has its own collection of keywords and made-up acronyms. Whilst I’m not proposing to list them all, it might be worth giving a nod to those that are most likely to be that unknown search term that sorts out that frustrating problem…

• COM is how most programs are able to talk to each other, and despite being invented for Windows 95 it still exists today. If you want to start automating a program from the outside, start searching for COM (although it’s more famous these days as a website suffix…)
• API or Application Programming Interface is the technical term for all the special functions programmers wrote with the sole purpose of manipulating one program from another. Most major software has something like this (even Twitter).
• Scripting is an odd one- the simplest difference between a script and a program is that a script is read by a program, and that’s what makes it do something (there are more technical differences). The antithesis of scripted is ‘compiled‘. Crucially scripted programs typically throw errors mid-way through running, whilst compiled programs warn you about them before you start (a bit of a simplification there…).

Learn Where To Get Help

Compared to Programmers, Civil Engineers are as introverted as that guy who stands outside the kitchen at parties. There are tonnes of websites where programmers freely exchange tips, and answer questions. My personal favourite is StackOverflow, which has yet to let me down; and has a massive, friendly, community that includes a lot of top industry programmers.

Another thing that programmers do is share. All you need do is search the vaults of GitHub to find someone who has at least tried to do what you’ve done, and probably done it better. Whilst I’m not claiming to be the best programmer in the world, my GitHub alone has a good few examples of things you can do with LUSAS, Excel, Word and Outlook that’ll leave them doing all your work while you go and make coffee.

So next time you find yourself facing a repetitive task, or sifting through large amounts of data; think- can’t my computer just do this for me. And the answer is most probably yes.

In fact, I’ll got a bit further this week; if you’re interested in automating something, either drop me a comment here, or send me a message on twitter, or Facebook, or whatever– and I’ll happily give you some pointers on how to solve your problem…

The post Programming Civil Engineers appeared first on Being Brunel.

Last week was a busy one- I fractured my elbow, talked about computational design, terminated a 6” model astronaut and undertook some serious cowboy-coding.

Now for the long version: Remember that BSO (it’s been making a regular appearance here); well, I came off it and fractured my elbow, which was why- at the end of an introduction to parametric design at Fosters+Partners from a very forgiving young man- a slightly robust gesture to get my coat on resulted in the severing of an adjacent model astronaut’s legs. Mortifying as it was, I did leave inspired to put together a prototype parametric designer of my own, and the replacement of my social calendar (sorry Mr Gregory) with taking enough pain killers to topple a war elephant left me with the time to actually do it.

The Project Currently Known as Geomatrix

This nifty pet-project is called (until I can come up with a less X-rated sounding name) Geomatrix, and for the next three weeks I’ll be focusing on the individual aspects of the application as I write it (a ‘develop-along’ if you will). This week I’ll be wittering away about Parametric Design, next week we’ll be talking about the Direct Stiffness Method (hur hur hur…) and the week after we’ll be on to Optimisation and Targeting. At the end of which I’ll OpenSource the lot and hope that anyone cares enough to join in.

So at this juncture let me introduce you:

Click Here to Start Geomatrix

After a weekend of prototyping (lit. creating an application from libraries and scripts loosely held together by hope and gaffa tape), this is the beginnings of my contribution to parametric design. “Woah” I hear you cry; “an application that draws triangles very slowly and then falls over itself and dies; truly this Thomas is a Wizard!”. Well, enough of your sarcasm; the magic is in how it draws the triangles.

Parametric/Computational/Generative/ <%= @Adjective %> Design

And that, from what I can see, is the foundation of parametric design. Geomatrix (boy do I regret that name) doesn’t know it is drawing a series of triangles; instead it is following a few simple rules to generate the geometry (in this case, n number of adjacent triangles all L wide and H high). As you drag the sliders and the parameters change, the nature of the geometry changes. In fact, with the current model that represents 378 structures at your finger-tips; albeit thoroughly unimpressive ones.

So why is this interesting, and what’s it got to do with engineering? It’s true that, at present, parametric design is more likely to turn up in a conversation about “hocharchitektur” [coined it] than in the realm of engineering; the ability to develop complex shapes (like a Spirograph on acid) and then rationalise them into something constructable using a set of rules and fluid parameters. From a structural designer’s point of view, however, it represents a way to design and optimise for uncertainty, flexible modularity or even adaptability.

Parameters represents a holistic approach to design; the “let’s try everything and see what works” approach that would probably make some of the more senior engineers I know lay down and cry. But for complex structures there comes a point where judgement alone doesn’t cut it. A good example (from a structural perspective- forget those architects and their fancy first-modal failure shapes) is when you lay a slab across an existing series of pad foundations. At conceptual design you’ll never get the chance to actually go and do the SI you need to find all the damn things, but computationally it’s not very expensive to identify some likely foundation groupings, setup a few rules to generate the probable permutations, and then test each generated ‘site’ for the most adverse effects on the slab. You’ll then end up with a design thickness, optionally varied by probability of suitability.

Implementation and Abstraction

One thing I feel I should mention is that Geomatrix is designed to be an abstract permutative generator and optimiser. In its heart it doesn’t care if it’s generating letters of complaint in iambic pentameter from the twisted thesis of a literary criticism major, or iterating the structural options for building an elevator to the moon (presumably to save the model astronaut I maimed). It just so happens that in this demo the back-end is plugged into a frame analysis library and the front-end attached to a processing.js renderer.

Why is that somewhat random implementation detail important? Because it highlights where I think the real power of parametric design in structural engineering lies. In the world of BIM plugging in Geomatrix to Microstation, LUSAS and a pricing spreadsheet from Excel would result in a web interface where the number of columns supporting a slab could be manipulated in (near-real) time; each column being positioned in accordance with office-layout rules; the drawings kept up-to-date, the reinforcement designed and the build cost reported back.

It’ll be improving all the time, so feel free to check back every now and again. Next Monday we’ll be talking stiffness matrices…

Click Here to Start Geomatrix

The post Parametric Design appeared first on Being Brunel.

The wonderful thing about Finite Elements is that they represent a general solution: As long as you’ve got the elements for it, you can model anything. With great power comes great responsibility, and as such Engineers typically reserve FEA (Finite Element Analysis, for those who aren’t good at guessing acronyms) for complex structures.

So what do you do when you’ve been handed the awesome power of LUSAS finite element software and have some time on your hands? Well, you buckle down to perform some serious geometrically non-linear dynamic impact analysis…

Ladies and Gentlemen, may I present to you my very own: Finite Element Tetris.

As fun as the above model was, in retrospect I felt it was lacking a certain je ne sais quoi. So, in the spirit of engineering, I dropped the stiffness, switched off the damping and turned down the gravity. If you’ve ever wondered what Tetris would have been like if the pieces were made of rubber… wonder no more:

So that’s it for this week; but if you want to keep up with the latest articles; from the stability of the Game of Thrones Wall of Ice to my 5 Top Tips to Annoy Contractors– Why not check out the Facebook and Twitter pages?

The post Finite Element Tetris appeared first on Being Brunel.

Welcome to the third, and thankfully final, part of this series on Track Structure Interaction (TSI for all of you who had the first album). Since the 1950s we’ve been using continuously welded rail in the UK, and with the introduction of the Eurocode we’re finally being made to consider the effect this has on our structures. If you want a reminder take a look back to parts one and two– don’t worry, this post will still be here when you get back.

Loading The Structure

TSI considers only the loading which relies on the interaction between track and structure. Being a two-dimensional, primarily longitudinal, analysis the most prominent of these is traction and breaking. In the UK, at least, the NA breaking load, which inherits from BD 37/01, is always the worst case; however the unrestricted length is arguably unrealistic and there is potential to agree a 300m limit, in keeping with the unadjusted Eurocode loading. You are limited, however, to loading a maximum of two tracks at any one time, and the ballast springs must be updated to reflect this.

You also need to consider vertical loading (LM71 for short spans, SW/0 for long spans), as the bending deflection causes end rotation and shortening. Note that TSI is a global SLS analysis, and therefore doesn’t require partial or dynamic factors. Network Rail do, however, still specify the use of the future (α) factor; however a good case for the reduced (1.1) geotechical value can be argued given the dependence on soil properties.

As well as traffic actions the relative change in temperature between rail and structure leads to a transfer of stress as one restricts the other. The magnitude of this action depends on the fixity of the rail; with different generic ranges given for tracks with and without expansion joints (35^o and 20^o respectively). The effects resulting from thermal actions arguably develop over a long duration, and although not explicitly stated, I believe it would be hard to justify using anything but unloaded ballast stiffnesses for this loadcase.

TSI Loading for Maximum Deformation

The aim of TSI is to check relative movements between structures and the stresses in the rails. As a general guide applying horizontal load to the full length of the structure, and positioning vertical load to effect the largest bending moment will result in the worst case condition; thermal load should always be applied to the complete structure, and loads should not extend into the approach lengths (see the previous article for boundary conditions). Consideration of the distribution effects suggests that, for deflection, a good starting point is to use the lowest foundation stiffness with the highest ballast stiffness; and the reverse is true for rail stress. The complicated analysis, however, means that it is always worth checking all cases.

TSI Loading for Maximum Rail Stress

Doing A TSI Analysis

The non-constant stiffness of the ballast springs used in TSI makes it a second-order analysis. Although the Eurocodes do provide a hand calculation method (based on empirical relationships), the strict qualification requirements mean that most of the bridges suitable for such a check do not actually require the analysis, and in addition it does not consider the additional ballast stiffnesses included by Network Rail. The alternative is to use a finite element model, which the original documentation from the UIC provides some guidance for: notably that the maximum discrete element length should be limited to 2m and that linear superposition is allowable. It should be noted, at this point, that the likes of LUSAS already comes with a TSI module.

TSI Relative Deflection Criteria

The criteria for TSI are two fold. The relative movements of structures due to traffic loading (laterally, vertically and rotationally) must be within the tight limits imposed by the Eurocodes, and the stresses in the rails due to traffic and thermal loading cannot exceed the tensile and compressive restrictions provided, once again, by the Eurocodes. There are, however, a few missing criteria. The limits noted in the Eurocodes are only correct for UIC 60 Rail on straight (radius less than 1500km), ballasted, track on heavy concrete sleepers spaced at 650mm intervals. There is some guidance on concrete fixings in the original research; but curvature has yet to be commented on.

At A Glance

You should never undertake an analysis without a good idea of what the answer should be. To this effect the ‘restraint coefficients’ provided in the Eurocode hand calculation method provide a simplified suggestion: apply a proportion of the total breaking load to the fixed pier, as shown in the above table. From the lateral load and moment, and an estimated ground spring, you can get a ballpark figure for the movement expected in the TSI analysis. The following rules of thumb can also give you a feel for the answer before you start:

• Expansion joints are required for steel bridges longer than 60m
• Concrete bridges longer than 90m will need expansion joints
• These spans can be doubled for centrally fixed bridges
• Medium span consecutive bridges with shorter start/end spans perform well
• Movement of tall bridges will be dominated by the pile design
• Movement in short bridges will be dominated by surface ground properties

If the bridge fails there is not a lot that can be done, structurally, to resolve the issue (remember the first thing I said in this series was: do the TSI first). Typically the uncertainty surrounding geotechnical properties means that more detailed GI may reduce conservatism in values, thus reducing movement. Similarly changes to articulation and span (note the rules of thumb above) can help rescue a failing structure. It is often conservative to apply to rules of linear superposition to a TSI analysis and, for close-cases, it may be worth building a stress history/combined loadcase approach into the model.

And so ends my series on Track/Structure Interaction; it’s been fun, and I’ve learnt a lot putting it all together. Let’s hope next time I have to do some heavy research it’s into something more interesting!

Note that the bare facts of these articles are quoted from Network Rail (typically NR/L3/CIV/020) and research by the UIC (774-3R). The rest is interpretation and notes from a graduate’s experience. As always, your attention is drawn to the disclaimer at the bottom of every page.

The post Even More Track Structure Interaction appeared first on Being Brunel.

About the Author

Ben Curry

• Ben Curry is a structural engineer, specialising primarily in bridges and currently working for Flint and Neill; although I know him better in his previous role, patiently answering my stupid questions to LUSAS Technical Support.
• Find out more: LinkedIn

Over the past few decades traditional engineering analysis techniques have rapidly been replaced by computerised methods. Probably the most widely-used type of stress analysis software is based on the ‘finite element’ technique. These days there are very few design offices which do not have access to at least one of the many finite element programs on the market.

These software packages can be very powerful in the hands of an experienced user. The potential drawback is that, especially in times of austerity, stretched training budgets mean that more and more engineers are being left to teach themselves how to use the software. This is in glaring contrast to other aspects of the industry – I’m sure you would be shocked, for example, if anyone on site was instructed to use a piece of construction equipment without proper training. For all the power of these programs, the results are entirely dependent on the engineer using them – if you put rubbish in, you will get rubbish out!

I first used finite element software as a fresh graduate, and found the whole experience thoroughly baffling. Apart from the book of worked examples provided with the software, I had no training, and the other engineers in my office were in the same situation. It was only by painstakingly working through the examples and making mistakes that I improved my abilities. I have no doubt that during this time some of my design work was based on dodgy analysis results.

Despite spending much of my time confused, I found using the software very interesting, and once I had reached a reasonable level of ability I applied for a job with the software company LUSAS. For the last couple of years I have been working for the LUSAS technical support team, so those of you who use this particular piece of software may well have had a conversation via phone or email with me at some point!

After starting at LUSAS I very quickly realised that I had developed some very bad habits during my period of self-teaching. Some of my ‘assumptions’ about the software had been completely wrong. My experience answering technical support queries quickly showed me that many (probably most) practicing engineers were in a similar situation – without any formal training and relying on the limited information provided in the worked examples or gleaned from colleagues. In particular, I think there is a general lack of understanding of the basic principal of finite element analysis – the way the element ‘mesh’ works. I think a good understanding of the basics of meshing will go some way to helping you become a good finite element user, so I would like to use this opportunity (thanks Tom!) to explain some of the basics of finite element analysis that every engineer should know before using this software. Because of my personal experience, this has been written using LUSAS-specific examples, but the information should be relevant to other programs as well.

I apologise for the departure from Tom’s usual entertaining posts! (Ed:I don’t know- this is one of the best thrillers I’ve ever read, i.e. “How many of these mistakes how you made?”)

So what is Finite Element Analysis?

In all finite element analysis a real structure is idealised to a (finite) number of ‘elements’ – hence the name. Stiffness matrix equations are formed and solved to ensure equilibrium between the elements, the applied loads and the structural supports. The resulting displacement matrix can be used to back-calculate forces, moments and stresses for use in design.

The type and arrangement of the elements used in an analysis will have a large influence on the results achieved. Poor selection of element type or a poor arrangement of elements can provide incorrect and unconservative results. Most finite element users are aware that they will get poor results if the mesh is not fine enough, but it is difficult to quantify exactly how fine a mesh should be. To a large extent this is analysis-specific, but there are a few general considerations which should be applied to every analysis.

Mesh Type

There are many different element types available in LUSAS. Different geometric features (e.g. lines, surface or volumes) will require different element types, but there are many element options for each type of feature. Details of all of them can be found in the ‘Element Reference Manual’ which is accessible through the Help system, but I have provided a summary table at the end of this document.

A basic knowledge of the features of the various element options is very useful when planning an analysis. For example, there are (at time of writing) 7 different types of beam element. Depending on the analysis being undertaken some of these might be more suitable than others. If you are using more than one type of element in an analysis (for example beams and shells) compatibility between the specific beam element and the specific shell element must also be considered.

Some mesh types specify either thick or thin elements. The difference is that thick elements have out-of-plane shear flexibility, meaning that they undergo shear deformations and as a result can output shear forces. Thin elements do not have shear flexibility, and as a result do not output shear forces. This difference means that thick mesh types are applicable to any model, but thin meshes can be more efficient for structures where out-of-plane shear effects are minimal. For example, shear in a steel I-beam is primarily carried by in-plane shear in the web rather than out-of-plane shear in the flanges, so thin shells could be used for modelling such a component.

Another important consideration when selecting a mesh type is the force variation across each element. The ‘3D thick beam’ (BMS3) is probably the most commonly-used beam element and is very efficient because each individual element has a quadratic variation of bending moment across it. This means that the bending moment diagram across each element will form a nice smooth curve, resulting in good results even with relatively few BMS3 elements used:

BMS3 Bending Moment Diagram

Conversely, the ‘3D thick nonlinear beam’ (BTS3) has constant bending moment results across each element. This results in a ‘stepped’ bending moment diagram which can drastically underestimate moment results, especially at sharp changes such as hogging at supports. The diagram below shows how the hogging moment of 123kNm predicted by the BMS3 elements is underestimated by 23% when BTS3 is used.

BTS3 Bending Moment Diagram

It is therefore important to be aware of whether your chosen mesh has quadratic (very good), linear (good) or constant (poor) variation of results across each element. In LUSAS you can check this in the Element Reference Manual under the heading ‘Notes on Use’. For example, the entry for element type BMS3 states “The force variations along the beam are constant axial force, constant torsion, linear shear forces and quadratic moments.” Obviously an element with higher-order force variations is preferable.

All mesh types also have an interpolation order which is either linear or quadratic. This is distinct from the force variations discussed above. Linear order elements only have nodes at the ends (or corners) of each element, whereas quadratic order elements also have ‘midside’ nodes half way along each edge of the element. Quadratic order elements usually have higher-order force variations than the linear equivalent and therefore fewer are required to achieve accurate results. Linear order elements should not generally be mixed with quadratic order elements.

A summary of the structural (as opposed to thermal) mesh types available in LUSAS is presented below:

Mesh Density

As well as an appraisal based on the judgment of the engineer, it is recommended that all analyses are evaluated with a mesh refinement check. This involves changing the mesh density, re-solving and checking whether the results are significantly affected. If increasing the mesh density significantly changes the results, this suggests that the mesh is not fine enough. Once the results start to converge then you can have confidence that the mesh density is sufficient.

In particular, be aware that any elements with ‘constant’ force variations will require very fine meshes to achieve accurate results. Quadratic order elements will generally provide good results with a coarser mesh than the equivalent linear-order element.

Mesh Pattern

Once surfaces and volumes are introduced into an analysis, meshing becomes more complicated. As well as setting the number of mesh divisions, it is now necessary to ensure that the meshing pattern is reasonable. In the simplest terms, the following should be avoided:

• Elongated (high ‘aspect ratio’) elements
• Elements with acute-angled corners

In other words, the ideal element shape is as near to square (or cubic for volumes) as possible. The reason for this is that results are calculated at a number of locations (called ‘Gauss’ points) within the surface or volume elements. Results are extrapolated from the Gauss points to the element ‘nodes’ from where they can be read by the user. In the case of highly elongated or angular elements, the distance between the Gauss points and the nodes can be large relative to the size of the element, and errors can be introduced in the extrapolation process.

Meshing of surfaces and volumes is a complicated topic, but the golden rule is to keep the shape of the surface and volume features as simple as possible to allow a neat grid of elements to be used. Square elements are preferable to triangular elements for surface meshes, and hexahedral meshes are preferable to pentahedral or tetrahedral meshes for volumes.

To finish, here are some examples of poor meshing and preferable alternatives:

Poor Example	Preferable Example
Triangular Elements	Grid with only quadrilateral elements
Right-hand surface has elongated triangular elements with highly acute corners.	Single surface meshed with quadrilateral elements of better aspect ratio and fewer acute corners
Standard 4 divisions per line results in poor mesh	Giving division numbers approximately proportional to line length results in neater mesh
Six-sided surface with irregular mesh	Made regular using ‘combined lines’

The post Building on Finite Elements appeared first on Being Brunel.

The wonderful thing about software for engineering (and engineering software is a wonderful thing…) is that it is typically extensible by design. This means that, with a little time and patience, you can make it do almost everything you want.

LUSAS is no exception; and provides a comprehensive array of functions and methods that let you drive the program remotely- called the LPI (LUSAS Programmable Interface; obviously…).

The LSP (LUSAS Scripting Pack, for those with more time than acronyms) is the result of two years playing with the LPI, in an attempt to enhance the experience.

Download the LSP

As the LSP is formed of over 35 scripts, some of which are highly specific, I’ve gone and picked the five features I use most often for this introduction:

• Match Properties – Get the first element right, and then just match the rest to it
• Make Neighbour Visible – Quickly expand your view from a few surfaces by adding those adjacent
• Report Groups – Generate reports by a common prefix; must have saved me about 100 clicks…
• Copy/Paste Geometry – Lets you copy geometry between models, which is fairly magic.
• Set Colour – As a Linux user I’m used to dark themes, LUSAS should be no exception.

Download the LSP

The post The LUSAS Scripting Pack appeared first on Being Brunel.

I think that LUSAS represents one of the most competent FEA packages out there; even when the Eurocodes start to lead you into the more complicated realms of non-linear/dynamic analysis. There’s something admirable about the way it does what it says on the tin, in an uncompromising way; without the false sense of security created by less sophisticated packages, that can so easily lead you astray.

The problem with any licensed piece of software, however, is that there is always a disparity between how many licences the company is willing to buy, and how many licences the company really needs. Never a day goes past where someone, somewhere, doesn’t make an impassioned plea to ’email-all’ for that 6:00pm licence to check a last-minute client update; or joins the 7:00am “I might need it later so I’ll get a licence now” club.

Challenger essentially provides polling support for the LUSAS licence client, giving you a way to see who is logged in, and to constantly challenge for any licences that come available. It also lets you send the traditional ‘for-the-love-of-god-stop-hogging-all-the-licences’ e-mail to all the current users with a single keypress.

Download Challenger

After downloading, check out the read me. It’s short, sweet, and tells you everything you need to get started with Challenger; which despite being portable, needs a bit of configuration to get going.

I am only just beginning to get around to sharing the array of scripts and programs I’ve authored to make my life more bearable, so watch this space.

The post LUSAS Licence Challenger appeared first on Being Brunel.