Need a book? Engineering books recommendations...
Return to index: [Subject] [Thread] [Date] [Author]
RE: Possible Enercalc Load Combination Problem
[Subject Prev][Subject Next][Thread Prev][Thread Next]- To: <seaint(--nospam--at)seaint.org>
- Subject: RE: Possible Enercalc Load Combination Problem
- From: "Conrad Harrison" <sch.tectonic(--nospam--at)bigpond.com>
- Date: Tue, 29 Jun 2010 16:40:48 +0930
I'm curious as to what attracts people to software like EnerCalc in the first place. You have pencil, and paper and say slide rule, along with various drawing instruments. You notice that a large proportion of what you write and draw is highly repetitive. Multiple copies of drawings are required for production and tracers and copy drafters produce these copies. With no other copying technology available, not sure how calculations were copied in triplicate: carbon paper maybe. Or maybe there was less need for such waste. Any case along comes new fangled device in the form of a photocopier: less trouble and better quality prints than any previous copying process. So take pen and good quality paper and in your best hand writing produce a master template for all that repetitive writing and drawing. Then take copies each time need to replicate and fill in the blanks. New recruits have guidelines as to the correct procedure as they follow the template and fill in the blanks. The calculations are repetitive enough that move over to tabulating the results and input parameters, and produce an appendix with one sample of worked calculations. Most of the numerical calculations are carried out on a scratch pad aside from the main body of the report in any case. Then the electronic calculator comes along and the scratch pad calculations to work out the numbers and fill in the blanks is discarded. Then programmable calculators arrive and getting the final numerical results and making the design decision becomes even faster: documentation is however now a bottle neck. Largely because documenting decisions has become an end in itself. For not only is the generic form of the calculations highly repetitive but so are the input parameters. Then desktop computers arrive, but when it comes to programming: 80% of the effort is required for the user interface: getting numbers in and out of the program: the calculations are easy. Then arrives the electronic spreadsheet. Now instead of pushing numbers onto the stack of your HP/RPN calculator, can type the values into a spreadsheet, and the elements of the stack can now be readily labeled. The problem of programming input and output is taken care of by the spreadsheet. So within the time it takes to push the numbers through a calculator now have a simple program: that can be used over and over again: whilst fill in the numbers on that photocopied master. With all the time saved by the photocopier those highly repetitive calculations, can be transformed into pre-engineered prescriptive solutions for specific applications. In general only need to know maximums and minimums: the basic limitations of the structural components and whether fit-for-function for the current application. The loads are standardized the sections are standardized, and the applications are largely established: that is we are not at the frontiers of science and technology. With the time saved by standardization and the calculation of limits, time can be spent transforming that spreadsheet calculator into a more readable report that can be printed out and displace the master template. No more transcribing substitution of numbers into formula and calculated results. Just input the parameters into the spreadsheet, and printout. Further more the results of one spreadsheet calculation can be linked into the parameters of another spreadsheet calculation: so can build a model of an entire project. Change one parameter everything dependent also changes. Calculations can be copied in blocks, assembled together or if have one large model to suit the typical project, delete that not required for the simpler project: so deliberately delete that which choose to ignore rather than forget. The calculation can be rearranged, or if simple just use goal seek to change a single parameter to achieve the desired result. You do the calculations to suit the task at hand. If need a table of values or graph, then easy to do. You are not constrained by the limitations of the commercial software produced for a specific purpose. For example if want to produce span tables for a given application (say series of carports), then with most commercial software would have to carry out multiple iterations manually, and manually assemble results into a table. With a spreadsheet can produce the table directly, and plot a curve to check has the correct trend. Also if have the calculations in Excel/VBA can also provide client with something better than just span tables: can eliminate the error in reading span tables by providing a custom application program: which produces a specification drawing which they can use to check the input parameters. Further more why are we churning out all this paper for calculations which serve no real purpose? It is in the main just paper shuffling, the structures have been built a thousand times or more previously. The calculations are not telling us anything new. If the designer can push numbers through Enercalc and get results in say a few minutes, then why print out any calculation reports? The certifying authority only needs to know the input parameters, the controlling characteristics for the proposal so that they can assess its compliance with the code. They can push these parameters through the software in a few minutes also and get the results: and reach a decision. No detailed calculation reports with pretty pictures required: just a simple summary would suffice. The detail of the calculations needs to suit the importance of the structure and the importance of the component to the structure. Most commercial software doesn't really accommodate for this, and pages and pages of unwarranted detail are printed out: which people have to copy, transport, check and store. If print to pdf, still got to copy, check, transmit and store. The software defines the structural model, if it is relevant to the proposed building, then just need to store the input parameters, and have a summary report that: all was ok! How did we get to a point where by calculations in the majority of cases are done to produce a document simply to satisfy a regulator and no other purpose? Here in SA most hot rolled steel design is mostly done using design capacity tables, not by direct calculation to the code. When permissible stress code was displaced by the limit state steel code, the main complaint was that now they would have to do the calculations: they wanted to return to permissible stress to continue using the available safe load tables. Once limit state design capacity tables were introduced the opposition to limit state basically disappeared. But there are no design capacity tables for cold-formed steel, the calculations have to be done to the code: the only exception is load capacity tables for cee and zed/zee section girts and purlins. More general assessment however has to be done to the code and few people do so. There is little available software to Australian codes, if there is any there is little variety: choice of one. So typically have little choice but to write own computer applications or complete calculations manually. Though the more common approach is to declare impossible cannot do that in coldformed steel, and try to get the client to accept hot rolled steel or what ever material they can easily design: timber from span tables. Timing may be a problem, with quick answers wanted. That aside, why would someone who's job involves determining the calculations to suit a specific task, choose to become dependent on software from someone else? For example as far as I understand the AISC/ASI design capacity tables were produced using a customized version of LimSteel. The two main frame analysis programs used have LimSteel integrated and available as stand alone. Whilst it achieves consistency, who is checking that LimSteel is valid? No real forum in Australia debating error in capacity tables, span tables or software, or codes. Regulatory notices criticizing software for manufactured timber trusses, and specifying requirements for. But no debate. There is also that issue of everyone saying how do you check the software? Well the simplest and fastest way is to build an Excel calculator, not concerned about the presentation just the number crunching. Check that Excel can get the numbers right, and check that the calculator gets the numbers right, and the slide rule, the log tables and the counting board. On the other hand building and testing a prototype more reliable than mathematical model. Just depends on how critical getting it right is: what ever right is? When doing a value-analysis how does software like EnerCalc and similar become a preferred option? Writing a graphical user interface for frame analysis or finite element analysis is not something would want to do: but if have a special purpose then maybe it is. In which case open source code, or GPL licensed preprocessor and post processor software would be a benefit. As far as I understand EnerCalc, is not open source, nor open architecture, therefore stuck with what it does. And from what I gather it does relatively routine calculations. If it supported COM automation, and could be linked into Excel, and therefore greater control over the sequence of calculations, and the input parameters and output presentation, then potentially useful. Don't want to be limited by what design capacity tables permit, nor limited to what software like EnerCalc and similar permit. Nor limited to how fast can do the job with the software: bottle necks with respect to what goes into the software and what need to do with what comes out. With COM automation can automate the input and output to the specialist application. Put another way those using Excel and similar may be, depending on the nature of the project, completing their work significantly faster than those using off-the-shelf engineering software. Secondly there are builders and manufacturers who have products which are largely standardized and don't want to be using off-the-shelf software for the few parametric variations permitted: nor employ people to drive such software. Writing custom software to better suit their needs is another market for engineering services, if have suitable computing skills as well. So if you are the engineer using off-the-shelf engineering software then your toolbox is some what limiting: like having your hands tied behind your back. But that may be just what is needed to best serve your market. Regards Conrad Harrison B.Tech (mfg & mech), MIIE, gradTIEAust mailto:sch.tectonic(--nospam--at)bigpond.com Adelaide South Australia ******* ****** ******* ******** ******* ******* ******* *** * Read list FAQ at: http://www.seaint.org/list_FAQ.asp * * This email was sent to you via Structural Engineers * Association of Southern California (SEAOSC) server. To * subscribe (no fee) or UnSubscribe, please go to: * * http://www.seaint.org/sealist1.asp * * Questions to seaint-ad(--nospam--at)seaint.org. Remember, any email you * send to the list is public domain and may be re-posted * without your permission. Make sure you visit our web * site at: http://www.seaint.org ******* ****** ****** ****** ******* ****** ****** ********
- Follow-Ups:
- RE: Possible Enercalc Load Combination Problem
- From: Richard Calvert
- RE: Possible Enercalc Load Combination Problem
- Prev by Subject: Re: Possible Enercalc Load Combination Problem
- Next by Subject: RE: Possible Enercalc Load Combination Problem
- Previous by thread: Re: Possible Enercalc Load Combination Problem
- Next by thread: RE: Possible Enercalc Load Combination Problem
- About this archive
- Messages sorted by: [Subject][Thread][Author][Date]