- Front-End which auto-generates the structural model (the data file for cpframe).
- cpframe
- Back-End which obtains the results from cpframe and then uses to size members, check connections and size footings
My primary focus is on the front-end as there is plenty of structural analysis software out there which already integrates the structural analysis function of cpframe with the back-end functions of member sizing, though little software available for checking connections and sizing footings with in the structural analysis software. The available structural analysis software also typically has facility for auto-generation of the dimension and geometry for common structural forms. Very little of the software however will auto-generate the model with loads applied: and that which is available doesn't cover Australian standards.
With respect to manufactured structural products (MSP's) there are at least 3 issues for structural design software, and these are:
- Rapidly analyse and specify structural requirements and generate cost for at the point-of-sale (PoS) and to be used by sales people and customer.
- Provide adequate documentation for seeking development approval (building permits)
- Aid independent checking and/or testing
The latter issue is important because without adequate consideration it becomes necessary to generate an unnecessary amount of documentation for seeking development approval for each and every project. MSP's are made in large numbers, if the structure was adequate last week, and barring any major changes in codes of practice, then it will be adequate this week and next week. To churn out documentation in the form of a thick report for each and every project becomes silly. The report needs to be kept, as far as possible, to a single page certificate: but we need independent means of checking the validity of such certificate.
Since most software for rapid design of MSP's is restricted to use by the manufacturers and their sales agents, no consulting engineer charged by local councils to do an independent check can rapidly generate a design model for use in general purpose structural software. Checks would involve the following:
- Relevance of the software or structural model to the proposed building structure
- Validity of the input parameters to the model
- Validity of the calculated results
Similar checks are also required by consulting engineers employed to check and certify the software. However whilst such software may require to be certified, such certification doesn't mean the software is relevant to the projects it actually gets used for in its day to day usage. The authors of such software also need to be conducting such checks and tests.
To my mind it has never been a simple matter to just dive straight in and start writing software for a manufacturer. The first stage should be developing tools which assist with the independent testing through the use of general purpose structural analysis software. To start with the engineers typically asked to provide such software usually start out by providing the engineering, so they need tools to provide rapid feedback to their clients. {NB: This not the case of designing a building for an architect and come back in a week, the feedback needs to be in around 30 minutes. In 24 hours the customer could have gone else where got a price for a building and placed an order.}
Unfortunately the manufacturers typically want to start putting software to use immediately, and once they do they will start hitting into projects which are beyond the scope of the software. The engineer will then have to deal with these variations in rapid time frames. So this situation reinforces the need to have an interface to general purpose structural analysis tools, so that the custom variations to the MSP can be easily handled externally to the manufacturers software.
Now given that MicroStran is popular general purpose structural analysis software, and its text based '.arc' files are a common import option with other software, then auto-generation of MicroStran '.arc' would the more productive option to adopt for the design office.
However developing a front-end to auto-generate structural models for MicroStran is not useful with respect to developing the software required by the manufacturer of MSP's, as MicroStran is not available as an analysis engine for integration into other software.
Therefore need to pursue parallel paths:
- Auto-generating models for a structures engine
- Auto-generate a model compatible with general purpose structures software.
Since we have MicroStran and MultiFrame licenses I will be developing auto-generation of models for these two packages along with models for our structures engine (cpframe). In the first instance I will focus on models for use with cpframe, as engineering graduates have the greatest potential for writing model generators and they don't necessarily have access to the commercial software packages.
It is also to be noted that most consulting engineers have little interest in auto-generation of structural models, as they mostly work with architects and have to fit a structure to a building, where as with MSP's the building is fitted to the structure. So most consulting engineers will be increasingly moving towards use of building information models (BIM) as such becomes more affordable and practical. However BIM forces the use of 3D models, and 3D structural models introduce a multitude of problems with respect to realistic modelling of the real structure. There are components in building structures which cannot be modelled correctly in general purpose 3D structural analysis software. If these components are left out, say girts and purlins for example, then no longer have a single 3D structure but a series of isolated plane frames. These 2D plane frames are largely the same, therefore wouldn't waste time modelling all of them, just the most heavily loaded frame and make them all the same. This is important for PoS software, as the computer has to wade through all available components and find the ones which work: where as an experienced designer would start off with a reasonably good guess and would only need a few iterations to find the best solution from the available components. In short at present BIM is too expensive, and the 3D graphical model has little relationship to engineering models across all disciplines, and a lot of extra work is imposed for no benefit. Any case for these engineers auto-generation of the structural model is of little value, as the primary requirement would be to auto-generate design actions applied to the dimensional and geometric model created by the architect. For such situation, idealistically want the structural model, the design actions applied, as the architect designs the building. For example the architect inserts a floor, defines its purpose and the floor structure is automatically generated. The structural engineers task being to tweak the model and advise the architect of changes to make. Ultimately the architect should be able to remove a column and the beam supported would turn red identifying as no longer suitable and in need of re-sizing. That is 80% of the expert advise the architect needs would come from the software the remaining 20% from specialist consultants. It is to be noted that often architects have difficulty finding engineers who are capable of realising the proposed the building, and so the buildings get reduced to the pinned and braced boxes which are in the capabilities of the available engineers. {NB: Whilst an engineer may have studied some theory or be able to pick up and read literature on new theory or rarely used theory, it doesn't mean they are confident or willing to apply such theory in the real world. So in the first instance computer software allows those who can to enable those of lack the confidence to go it alone. Such software however provides a foundation for enabling and empowering everyone, instead of building physical prototypes and testing, they use the software as the test bed.}
So with MSP's we are dealing with standardised structures and the proposed building has to fit the available MSP. The structure therefore takes precedence over the building design, the designer has to fit their building into the envelope provided by the MSP. The designer is typically the owner who has decided that an MSP is suitable for their purposes, and who otherwise wants to avoid the delays caused by architects and engineers. Unfortunately they typically miss the delays which will be caused by expecting a sales person to provide design for the custom features the buyer desires. An engineer being called in at the last minute when everything has been rejected by the local city council. Since the engineer can be any available engineer, such engineer first has to get up to speed with the manufacturers product. Which will turn into a hassle as the manufacturers don't really have product specifications, or spew forth a lot of nonsense about intellectual property (IP). If they had any real IP then they would have patents, and if they have patents, its public knowledge. In the main they have no real product, no product manager, and no product development manager, and an over willingness to sell what ever the customer asks for. Hence their desire for software to do the design to the customers requirements at point of sale: but do the design and engineering for what? That is something they have no idea about, except the unrealistic expectation: anything the customer asks for.
Clearly developing an auto-generator with the flexibility to generate a structural model for anything under the sun is a major undertaking if not impossible. To achieve that would require some form of scripting or modelling language to define a new structural form without going back to source code programming. There would still need to be development of a new interface for the user to incorporate the new MSP, it wouldn't be something done at PoS whilst talking to customer. {NB: MicroStran as a macro language for auto-generation of complex geometry: as I remember spirals and such. I never really used it, its limited, and its a variation of the .arc file, it just removes the need to define all the nodes and connectivity of such.}
So whilst there may be flexibility in the background behind the scenes, in the foreground there is necessary restraint on what the salesperson and customer can do. Otherwise could simply use BIM type software at PoS and feed into the back office for engineering at some other time after PoS. The whole point of MSP's is that such structures are as close as possible to being off-the-shelf buildings with a fixed price and comparable from one supplier to another. Too much variation and its no longer an MSP. A car is pre-engineered, you cannot go into the showroom and ask for it to be supplied with 3 wheels instead of the standard 4: such variation imposes a need for extensive engineering which includes building of prototypes and physically testing that mathematical models are valid and not overly unrealistic. Choosing whether to have a radio in a car or not doesn't typically impose a need for additional engineering. Putting a window in a shed doesn't impose a need for engineering, placing a door in a shed which is wider than the spacing of the frames imposes a need for engineering. Placing a building in a wind loading environment it wasn't originally designed for imposes a need for additional engineering. Most of this structural engineering is little more than calculations to codes of practice. Not all of the engineering however is within the scope of calculation and some physical testing is often required. Hence the importance of defining the product before writing the software.
Software is also a product and it should also be designed before being written. However it is recognised that the manufacturers just want to get on with manufacturing. You don't get the full technical drawings and specifications for a car, but then again the customer is not permitted to make changes to the car which would require such information. The building industry does permit making changes which requires the additional information, and therefore they need to make it available: which is extremely difficult if they haven't produced it.
There is a lot of up front work to do before software the likes of MicroStran or Multiframe can be put to use. Most MSP's are well within the capabilities of Australia's 2 year qualified Engineering Associates to design and assess, and such persons are likely more compatible with the needs of the majority of the manufacturers than professional engineers. So if the structural models for the MSP's can be auto-generated and be compatible with commercial structural analysis software, then the engineering associates can handle custom variations in house, a lot more rapidly than queuing up for assistance from a consulting engineer. If such personnel can be employed along with appropriate software then the need for PoS software would be slightly reduced, because going to the manufacturer would still be faster than going to an architect and then going out to tender.
So would say we are looking at:
- PoS design solutions in no more than 5 minutes during at most a 30 minute interview.
- Behind the scenes solutions in less than 24 hours: same day response.
The latter can be achieved by semi-automating the readily available general purpose structural analysis software. The former requires full automation at PoS, and requires highly specialised custom software.
In the first instance therefore I would recommend semi-automating the readily available software and employing the right people on staff. Such tools would enable all consultants and increase the number available who can deal with custom variations to MSP's, including future extensions, and who can test and certify the more specialised software, and otherwise independently check and certify individual building projects. Diving straight into the specialised software owned by the manufacturer and only available to their sales distributors just creates a lot of hassle for everyone else involved
Internally to an application which auto-generates a structural model it doesn't really matter what structural analysis software is used. That is the difference between generating a model for cpframe or MicroStran is simply a matter of file format: the data required for the files is the same. Therefore a model generator written for cpframe if written appropriately can be easily adapted to a multitude of general purpose frame analysis software by writing an appropriate file export procedure. The principal task of generating a model already completed in the main body of the application.
An MS Excel Template for cpframe.
The simplest, though not very practical, means of generating a model for cpframe is to use MS Excel and perform all the calculations in the worksheet and connect these to a summary sheet which as the appropriate format for writing to a cpframe data file. To such end I have thrown together a template for such purpose called frontEndPFrame01.xls.
 |
| frontEndPFrame01.xls |
As its a template file it doesn't actually do anything. The template merely provides a worksheet which can be adapted to suit various structures by adding extra data rows as required. Buttons are provided to write the contents of the worksheet to a data file compatible with cpframe, and then run a shell to execute cpframe to generate the results file. As the application is procedural, can be reasonably certain that the data file will exist before the next command is executed, therefore these tow buttons can be combined into a single command button: with the data file being automatically generated and passed straight to cpframe. On the other hand cannot be certain the results file is available, before the next command executes, as cpframe may still be in process. Therefore have to have a separate manually executed task for viewing the results. This command merely opens the results file using Windows notepad.
As a test my gable frame spreadsheet can be meshed into the template. This spreadsheet calculates the wind loads on a simple gable frame, the same structural form as set up in the front end template. So just need to link the appropriate cells, such as the wind loads on the frame, into the the template data sheet. Since the spreadsheet already contains Kleinlogel formula for the frame, the results of running cpframe can be checked. Since cpframe can only handle a single load case at a time, conditional formula would be required to switch the load case the file is being generated for. This approach I took in 1996 using Quattro Pro (QPro and the original version of pframe. {Actually back then the program was called either f_wrk.exe or frame.exe, pframe was the name of my QPro workbook which drove the program}.
 |
| QPro pframe.wb1 |
As can be seen from the screen capture of the QPro workbook, it contained buttons for collecting data defining the structure, writing the data file for the plane frame analysis program, running the plane frame analysis program, and then printing out the multitude of worksheets used to design all the various components of the whole building extending beyond the primary frame. To the right of the worksheet is a small table showing the load cases for the old permissible stress design, with a marker showing the current load case for which the plane frame data file is to be created.
 |
| Plane Frame Analysis Launched in front of QPro Workbook |
With the original version of the plane frame application, I had to manually open each data file and run the analysis inside the plane frame application. With cpframe those steps are removed. Still with the original application that is how I manually incremented the heights of the structures until I broke the section desired to be used and then produced standard calculations for maximum height structure possible. {Stepping back of course to what did work. I also happened to know which load case was most likely to be the critical load case therefore I only need to increment height for one load case, and check other load cases when it appeared the maximum height had been reached.}
The QPro application never got fully converted to MS Excel for a variety of reasons: basically all the building blocks are there, just not connected up. Any case using the worksheet to do the calculations is not the most efficient way to do things. Its intuitive and fast initially, but cumbersome at later date when need to add additional members and load cases. It is better to use the wind load functions in schTechLIB directly in vba code using arrays, rather than reference the functions to carry out calculations in worksheet cells. Calculations in the worksheet cells are fine for presenting the calculations but a hindrance to more complex tasks.
Download frontEndPFrame01.xls
For a more flexible approach I will release an alternative template, with the data spread across multiple worksheets, making it easier to shrink and expand the structural models, and provide easily reading existing data files into the Excel workbook. Generating multiple models in the one workbook is not compatible with worksheet calculations. Multiple models is a definite move towards using vba or other programming language.
DISCLAIMER :
Users of the software must accept this disclaimer of warranty :
The software is supplied as is. The author disclaims all warranties, expressed or implied, including without limitation, the warranties of merchantability and of fitness for any purpose. The author assumes no liability for damages, direct or consequential, which may result from the use of the software.
Revisions:
[03/02/2014] Original
[23/04/2016] Changed download links to MiScion Pty Ltd Web Store
