Chapter 1 : Design Codes for Engineers or Computers?

1
Introduction

Design Codes for Engineers or Computers?

Chapter TEDDS for Word Users Guide

The Structural Engineer, 3rd December 2002, Volume 80, number 23/24, page 21. We occasionally see and hear comments suggesting that structural design codes are not written in ways that allow practical/experienced engineers to go about their business in an economic fashion. (Let's not stir up this debate). We have even experienced assertions that we (the computer industry) have infiltrated the system and have influenced the codes so that it is impossible to design anything without the aid of software. I can honestly say that we have not worked out how to do that yet! The serious questions this article hopes to tackle are: Are codes like BS8110 actually biased towards computer based solutions? Are the requirements of computer solutions and traditional hand design methods mutually exclusive? What motivates Engineers to use software in the first place?

Why BS8110?

In the following sections aspects of BS8110 are discussed in order to illustrate that the challenges, which appear daunting if you stick to hand calcs, can be equally daunting and perhaps even illogical when you try to computerise the solution. It is worth noting at the outset that there is nothing code or material specific about these issues - similar points could be made about any structural design code.

Chapter 1 : Design Codes for Engineers or Computers?

Analysis and Design of Flat Slabs

Cl 3.7.2.2

This seems to be something of a hot topic at the moment. Section 3.7 of BS8110 describes procedures for the analysis and design of flat slabs.

This says In the absence of a more rigorous treatment, flat slabs consisting of a series of rectangular panels may be divided into a series of frames and analysed in accordance with . The remainder of this section of the code gives no further guidance on the more rigorous methods.

Chapter 1 : Design Codes for Engineers or Computers?

Where a structure can be categorised as a series of rectangular panels the equivalent frame method makes good sense and can easily be applied. But what about the relatively simple layout shown in figures 1 and 2?

Figure 1: A typical floor plan in CSC's concrete building design software - Orion

Chapter 1 : Design Codes for Engineers or Computers?

Figure 2: A 3D view in Orion

In practice some degree of irregularity can be accounted for in the equivalent frame method by making conservative adjustments to the spans and panel widths. However, when engineers approach us on the subject of flat slab construction, they will often show us plans with irregular column layouts and acknowledge that they have tried to apply strip methods and simply could not do it such that they have any confidence in the levels of conservatism (or otherwise) that they have introduced. The option of a more rigorous treatment might include yield line analysis, but in terms of today's analysis software, it probably means 2D finite elements (plates or shells) utilised in 3D models. Software advances mean that FE models can be created and analysed more and more easily. However, there are regular questions and difficulties which relate to the fact that the code does not give general guidance applicable to general 3D analysis models. It focuses on providing a simplified method for an idealised situation.

Chapter 1 : Design Codes for Engineers or Computers?

Cl 3.7.2.1

Suggests that ideally pattern loading should be considered in order to obtain the critical design forces at each section. However, in practice very few of us could look at the example above and describe a logic for patterning of loads on this 2D surface. If we cannot describe the logic in a programmable fashion, then the software cannot do it. This clause also gives the option of designing for the case of maximum load on all spans, but advises that clause 3.5.2.3 must then be satisfied.

Cl 3.5.2.3

Apart from placing more limits on the applicability of this solution, this clause indicates that 20% of support (hogging) moments need to be effectively re-distributed to the spans. In the idealised frame analysis, the redistribution would be applied before the design moments are distributed to strips in accordance with table 3.18. Using table 3.18 in conjunction with table 3.12, and noting the requirements of cl 3.7.3.1, you can estimate an approximate expected ratio of approximately 2 between peak design moments for hogging and sagging. This may surprise some engineers who routinely use FE analysis for flat slabs. The code recognises the way in which the hogging moments rise rapidly and concentrate at supports, but it limits this concentration to a zone of half the column strip width. (On an 8m by 8m panel this is a 2m wide zone.) When compared to strip methods, a finite element analysis (see below) will tend to show similar sagging moments but will expose much more intense local peaks across the supports.

Chapter 1 : Design Codes for Engineers or Computers?

Typical FE Analysis Results

Figure 3: A sectional view after FE analysis in Orion

For this example figure 3 shows a strip indicating peak hogging moments of approximately 3.5 times the peak sagging moments. These are the sorts of results an FE analysis produces, in this case for the all spans fully loaded condition. (Note that with finer meshing the hogging peaks will intensify further) It is very logical that these intense but local peaks should be averaged out into wider design strips, but how should an engineer go about applying the same judgements as have become embedded in the code guidance for the equivalent frame method to the results of an FE analysis?

Chapter 1 : Design Codes for Engineers or Computers?

In addition there is the requirement to satisfy clause 3.5.2.3. (the requirement for moment re-distribution) This makes sense in the context of an idealised equivalent frame analysis, but makes very little sense in the context of an FE analysis. Looking again at figure 3, clearly it would be nonsense to take 20% of the peak hogging moments (in this case 20% of 331 = 66kNm) and add that to the peak sagging moments (which in this case would mean an increase from 92 to 158kNm - a 72% increase). A suggestion at this point would be to recognise the relative levels of hogging and sagging that apply in the equivalent frame method - table 3.12 suggests that the hogging and sagging moments after re-distribution are very similar - this suggests that the sagging moments have been increased by around 30% from their pre-redistribution levels. Could the requirement to re-distribute moments be re-expressed as a requirement to adjust moments? For example: Sagging moments must be increased by some factor? (possibly 20 to 30%?) And more debatably - hogging moments may then be reduced by a different factor (possibly 10 to 20%). Bear in mind that cantilever moments should not be reduced. Perhaps hogging moments should not be reduced, in which case a smaller increase in the sagging moment might be appropriate?

Deflections

Deflection seems to be a regular topic of discussion/concern for engineers looking at flat slabs. FE software will allow you to adjust material properties to account for load duration, and section properties to account for cracked sections - but it is worth remembering the material we are dealing with here - concrete. Do you know what Young's Modulus actually is for the concrete that is going to be in your slab? BS8110 suggests that the short-term modulus for a C40 concrete might be somewhere between 22 and 34 kN/mm2. This is a big range and ultimately the deflections that you get from analysis are proportional to the Young's modulus you provide as input. While there is this degree of uncertainty

Chapter 1 : Design Codes for Engineers or Computers?

relating to the correct input, perhaps we should be cautious about setting too much store in deflections predicted by an apparently sophisticated analysis that might also be regarded as a more sophisticated guess. An interesting aside to the above can be found in results reported for the Cardington In-Situ Concrete Frame Building. The results appeared to indicate that adding reinforcement to a slab has little if any reliable effect in terms of reducing deflection. Results also indicated that propping methods and striking times can be of much greater significance.

Analysis and Design of 3 Dimensionally Framed Buildings

Similar issues to those discussed for Flat Slabs can be repeated in many areas addressed by structural design codes. In the case of BS8110, there are similar issues related to the analysis and design of general buildings. Section 2 describes broad objectives for the analysis and makes cross reference to sections 3 and 4, but as for flat slabs, guidance in these sections is really all written with sub-frames and other 2D idealisations in mind. Again, in a direct parallel with the flat slab discussion above, when structures are irregular it often becomes impractical to break the problem down into 2D sub-frames and then re-integrate the analysis results for member design. Ignoring discussion of whether it is essential, or sometimes just a matter of personal preference, it is certainly true that engineers increasingly want to tackle concrete analysis and design in a 3D modelling environment. The question is - do we (and if so how do we) need to emulate things that we all traditionally expect to do in 2D in the new 3D environments, for example: 1. Pattern Loading & Moment Re-distribution - Bear in mind that there will be convoluted load paths. Within a 3D model, loads are probably applied to areas/slabs and then decomposed to members. There will be systems of beams loading beams, loading other beams, and so on. Patterning the loads to produce worst effects in any given continuous beam line means switching remote slab and beam loads on and off. Do we actually need to create the

Chapter 1 : Design Codes for Engineers or Computers?

complex patterns necessary to find worst case forces on every section of every member? In large models this is an almost inconceivably large number of combinations. Is there some degree of pointlessness in methods that suggest you should first go to a lot of trouble to identify envelopes that cover for every worst case scenario, and then adjust those envelopes so that the extremes are reduced by up to 30%? Along the same lines as suggested for flat slabs, could there be a very reasonable alternative based on adjustments to the results achieved for the All areas fully loaded condition? Such a method would certainly have to err on the side of caution but should a small margin of increased over-design count against it? It would certainly make the whole process faster, once reinforcing is rationalised it may make very little difference to material costs, and ultimately reinforcement material costs are only a very small part of the whole picture - saving time also saves money. 2. Sway (un-braced) / Non Sway (braced) - Currently there is a very clinical classification based on an assumption that frames either do or do not contribute to lateral stability - if they do not it is because other walls, bracing, or buttressing are designed to resist all lateral loading in that direction. In practice there will be some degree of sharing of lateral load between frames and walls and a 3D analysis will expose this by sharing the loads according to stiffness. To enforce the case where particular elements carry all the lateral load it is necessary to adjust stiffnesses or even maintain different analysis models for vertical and lateral loads. Since the members forming a structure have no idea what loading is being applied does it ever make sense to be considering different models for different types of load? 3. Further to the above, it is perhaps not explicit, but clearly the intention of sway/non-sway classification and subsequent adjustment to design forces is to account for P-Delta effects. It would be entirely possible to create models where there are quite slender elements that get categorised as walls but where a second order analysis shows P-Delta effects are not negligible. In all probability good engineering judgement would stop you from building such

Chapter 1 : Design Codes for Engineers or Computers?

a structure, but could/should the code adopt a more logical deflection based classification along the lines of BS5950? If it did it would have to be quite specific on guidance for material and section properties to be used in the analysis model.

Other Codes and other Guidance

There may or may not be excellent guidance on some or all of the above in other texts. Exhaustive searches have not been made, although a search of the libraries of the Institution of Structural Engineers and the Institution of Civil Engineers revealed nothing of great assistance on the subject of FE analysis in Flat Slab systems. In due course the Eurocode may clarify some points, but it does seem to retain requirements for patterning loads and a line of thought that still assumes rectilinear, regular buildings.

Conclusions

Design codes do not have to be written for computers, they must to be written for engineers, some of whom want to use computers. Most engineers have now had 3D analysis tools at their disposal for some time, but the codes are not yet written in a way that provides realistic guidance on the 3D model(s) they might build, or the loads or patterns of loads that should apply. Design codes such as BS8110 are not biased towards computer based solutions. Analysis, design, and engineering judgement remain intertwined in idealised methods. There is nothing wrong with these methods except that they have been around for longer than calculators far less computers. Computer based solutions and traditional hand design methods are not mutually exclusive but the codes need to recognise that the traditional idealised methods are one way to solve the problem - there are other ways, are they better ways?

Chapter 1 : Design Codes for Engineers or Computers?

Clearly this article raises the question of whether codes need to be developed to take greater account of modern analytical and modelling methods. In parallel with this there is a strong argument for retaining and perhaps even simplifying the idealised methods so that engineers can continue to cross check results with some ball park figures or a few quick hand calculations. Finally, what motivates Engineers to use software in the first place? The bottom line is productivity and profitability; Engineers are in business and consciously or subconsciously will probably (and quite rightly) make some sort of financial justification for every piece of hardware or software they buy. Software should be used to do things in faster ways, or better ways, or to do extra things that you would not otherwise have time to do. On occasion software might be used as a learning aid, but it should not become a crutch, it should not be used as a substitute for engineering ability and knowledge.