Metamorphs Journal: On Developing Structural Analysis 2D Plane Frame Application

Back when we started, we didn't have any frame analysis software. First problem was knowing what was available and where to get it from: it wasn't like could just go down the street and buy from local computer store. Second problem was such software was too expensive.

Our business doesn't work on debt: taking out loans and hoping will get the business to repay the loan is risky: possibly crazy. Since we had time we invested time: a kind of sweat equity. Whilst hoping for a return on the investment of time, there is no requirement financially, as there is no real debt. Sure economists may throw opportunity costs in the mix and say there is debt. That is it would be considered better to buy the tools and put them to use and start to make money from using the tools rather than expend time creating the tools. The answer to that however is that the only tools required are pencil/paper and a calculator. If can do the work starting with blank piece of paper, then possibly also able to start with a blank computer screen, if can program. Sure the tools develop oneself may not be as good as a bought one. Then again the bought ones may lack certain features. If buy software then constrained to what it does and the way it does it, and also have to wait for authors of the software to update the software to new codes of practice. Then there is a problem of whether the software remains in the market. One consultant had advantage in the cold-formed steel market because he had frame analysis software which designed to AS1538 permissible stress version of cold-formed steel code. Problem was, the company ceased to operate and the software was never updated to AS4600. The consultant had advantage because of what others could do, not because of what he could do.

My philosophy has always been we build those tools ourselves which are practical to build and directly related to what we do: the core activity of engineering design. Not going to waste time building massive complex integrated tools. However with the passage of time the tools which become practical to build in-house increases. It is all dependent on heritage, and building foundations for future development.

So we were only dealing with plane frames. My dad could analyse using moment distribution, I could have learnt such, but speed wise better to use Kleinlogel formula available in steel designers manual {I'm assuming current version has same as earlier versions. Also being mechanical my formal studies didn't go in depth into the analysis of rigid frames.}. So all up we didn't really need frame analysis software, but it would have made things easier and faster.

We had the book: Microcomputer Applications in Structural Engineering by W.H Mosley and W.J Spencer. This book contained several programs written in Basic. I had typed them all into the computer, whilst I was still studying. My dad took the plane frame program and translated into Turbo Pascal, and turned from a cumbersome command line program to one with a graphical interface. Whilst I was experimenting with Turbo C and menu systems, my dad experimented with Turbo Pascal. I opted for C as a programming language, as it was apparently to be the future for AutoCAD. My dad opted for Pascal because it was the language being used on the graduate diploma in computer science he studied. I did learn Pascal as, Turbo Pascal was the first compiler we got for the CPM/80 machine. It wasn't until a few years later when got an MS DOS machine that I got Turbo C.

At this point not releasing the program, as it has our business details hard coded into the reports. It is also proving difficult to recompile a MS DOS program in the windows command prompt as having memory problems. Something to do with the command prompt environment I'm guessing. Also the program doesn't run on my Windows 7 computer: though very little does as its 64 bit: its good at collecting dust. A few years back my dad did convert into vba to run in Excel, and about 2 years back I wrapped it into a vba class. But still looking to get it back into a stand alone application, possibly even a COM automation object, or what ever the equivalent for .net is. Unfortunately the benefits of adopting vb.net to take advantage of all the Excel/vba code I have written are not that apparent: as vb.net has some major differences compared to vba. Therefore looking at going back to Pascal, at the moment managed to rip out all the Turbo gadget graphics and create a console application using Borland Delphi. Given its no longer Borland product, considering adopting Lazarus and free Pascal. The problem I have with that approach is having to revise all my Delphi wind loading procedures from AS1170.2:1989 to AS1170.2:2011, or otherwise translate Excel/vba into Pascal. So may look at parallel developments to integrate everything together.

My current Excel/vba workbooks are using Kleinlogel formula in the worksheets and therefore restricted in the frame they can quickly assess. To change the frame more work required in the worksheet, and that makes it cumbersome to change from one frame to another. Having the frame analysis in vba behind the scenes still doesn't really improve the situation. It is currently being used for carport/canopy design in that manner for one carport supplier: that however has limited capabilities and a small amount of my code in it. Another workbook I have set up using more code and dialogue boxes keeps hitting Excel/vba memory limits. Therefore need to get the code out of Excel/vba. Also having worksheet formula creating a 20Mbyte Excel workbook and needing MS Excel to use that workbook, so as to do what a stand alone 250Kbyte program can do, is really inefficient use of computing resources. The industry keeps running around seeking spreadsheets, because they think that is the simple approach: but then they want greater flexibility in design options than is practical to implement by spreadsheet, and which is also kept within the capabilities of any salesperson.

Spreadsheets and in worksheet formulae are practical for all the dimension and load calculation's prior to using frame analysis software. Spreadsheets and worksheet formulae also practical for design members and connections after frame analysis. But frame analysis in the worksheet formulae is only practical for simple structures: like beams and very simple frames.

That's where the bottleneck emerges. Very simple structural analysis and design, can be completed quickly from a few parameters input to a spreadsheet. Increase the complexity and the integration is loss. Very little frame analysis software has facility to automatically generate the model: a full model that is. Most frame analysis software can generate dimension and geometry for some common structural forms. But the software doesn't calculate and assign the loads to the structural elements. The commercial frame analysis software can also check/design the members once the analysis is complete: depending on materials. Cold-formed steel is not a material commonly available as a design module with commercial software. Therefore have to check members independently, this posing another delay. Then there is the design of connections which also has to be external to the analysis software. The use of BIM can maybe streamline this process for custom buildings, but BIM is typically does not provide parametric modelling of common structural forms.

Just as Toyota aimed for single minute exchange of dies, to improve manufacturing productivity: design and engineering suppliers need also to be looking at single minute design, assessment and documentation, and for that matter even approval. That is, concept to approval in one minute. Not for all structures and buildings, just those which have common structural forms, and are extremely routine. Unfortunately the nail plated timber roof industry use of software through a spanner in the works. It is therefore necessary to avoid those problems, and that requires software which is not proprietary and locked to manufacturers of structures: at least some version of the software needs to available to the whole supply chain: which includes the certifying authorities. Any case I will ramble on more, about that at a later date.

For now here are some screen shots of the application I am breaking apart and converting over to windows.

Sample Data File viewed in UEStudio

Opening Screen

Main Menu

Open Data File

Analysis

Screen Plot Menu

Geometry

Design Actions

Action-Effect: Bending Moment

Action-Effect: Shear

Action-Effect: Axial Force

Action-Effect: Exaggerated Deflections

Which is typically the way I used the program, as I generated the data file using Quattro Pro, rather than using the user interface. For me the application would have been better if it provided a command line option to read data file and produce results file without need to use user interface. When moved from Quattro Pro to MS Excel, lost some of the benefits of the original QPro application, though gained other benefits and moved in other direction. So part of current task is resurrecting the QPro application and finally converting over to Excel/vba.

Any case the plane frame application did allow creating and editing data files, even had facility to print the screen plots to the printer: though locked to a specific printer. The data input screens are as follows.

Main Input Menu

Main Menu to define structure

Node Data

Member Connectivity

Supports

Materials

Sections

If I recollect, there is an error in the unit description for the section properties. Not a problem if know what is required in the data file. But a good reason not to release the program.

Main Menu for Loads

Joint Loads

Member Loads

Gravity Loads

Job Details

Control Data

Whilst the control data is the last menu item, it needs to be input first. That is a cumbersome aspect of the program. Part of the conversion from the original Basic source. The original program asked questions on the DOS command line, if got an input wrong then couldn't back track, had to cancel and start again. Part of the requirement being to set up the application environment.

Our Pascal version of the program however has dynamically allocated variables, and makes use of record structures and pointers. I think it also makes use of sparse matrices as well. It therefore should not be necessary to input the control data, as it should be able to work it out. Such data should thus also not be required in the data file. So rewriting the file input routines is another part of the current exercise, otherwise creating a new file format, possibly using XML, and a file translator for the older files.

So at the moment looks like parallel developments in Pascal, vb.net and Excel/vba, with possible experimenting with Java. When reach the point of having either a DLL or COM automation library, then should all converge and move over to a single programming environment. Each programming language has its own unique library of built-in functions which become an obstacle when move over to an another language and such functions are not available. It represents more programming before can move forward. Basically each programming language has a different heritage, and therefore different foundations on which to build.

So attempting to bring a collection of tools, developed on as needs basis, together as an integrated whole. Which they were a lot closer to being at the very beginning when we started, but for various reasons they diverged.

Sample Output: