Use of computers for the design of concrete structures by Jones, Tony

Ref: Concerete magazine, May 2003.

The aim of this article is to consider computer use in the design of concrete structures and how this is changing the design
process. It is often argued that this change is not for the good of design. Problems may arise when trying to produce reinforced
concrete designs from computer output. The article contains a checklist of items of which the engineer should be aware before
relying on the output received. Simple methods for checking the validity of computer output are highlighted and the need for a
body to check proprietary software is discussed.

The current situation:

Today's young engineers often appear unwilling to undertake analyses by hand. Whether an approximate calculation to confirm
the viability of a concept or the final design analysis, the preferred approach is to use a computer. In itself this is not necessarily
a bad thing and computers can be valuable in understanding behaviour. For example, by varying different parameters, the
sensitivity of a solution to a number of variables can be quickly assessed. However, if the reliance is such that the engineer loses
the confidence to carry out simpler methods of analysis, the ability to carry out an independent check of their model is
compromised. In addition, in the search for an exact answer, the nature of reinforced concrete construction is forgotten. The
material is not elastic, stresses are induced through many mechanisms other than load (shrinkage, thermal effects, creep) and
the process of sensible rationalisation and detailing often negates the benefits of any perceived additional accuracy.

There are numerous factors behind this situation, some of which are listed below. It is important to realise that all parts of the
industry have played their part:

* the ready availability of software in the office, in universities, and free from the internet

* lack of education in approximate methods, some universities placing too much emphasis on obtaining the exact answer

* a belief that computer analysis is quicker and the only way to compete in providing a low fee service

* low fees, leaving senior engineers with insufficient time to teach approximate methods

* lack of guidance from industry journals on practical design methods and approximate solutions - too much emphasis on highly
theoretical, and necessarily computer-driven, solutions

* a belief that software calculations must be correct and that hand calculations can only be crude approximations

* increasing complexity of modern codes deterring engineers from hand calculations as they believe they can no longer provide
the complete answer.

Over-reliance on computer output is not only a concrete issue and has been addressed in other publications. The Institution of
Structural Engineers published guidelines on the use of computers last year(1). This report was, in part, a response to concerns
raised by the Standing Committee on Stractural Safety (SCOSS)(2).

Design consultants have acknowledged the problem. For example, Buro Happold has a policy where a hand calculation must be
made before the computer analyses is started and the computer model is accepted only if it corresponds to the hand calculation
within defined limits. Arup has introduced a one-day course, Design without the computer, where the objective is to teach young
engineers how approximate answers can be quickly calculated to check more detailed analyses. Both companies have internal
handbooks giving approximate solutions and schematic element sizes.

Reinforced concrete design:

All these points are equally applicable to other structural materials. However, there are a number of issues specific to reinforced
concrete. It is suggested that the engineer should understand how the proposed computer program deals with each of these
issues before analysis is undertaken.

Shear strength:

Shear design is basically empirical and requires additional rules to define the boundaries under which code values are
applicable. These vary from code to code and can be interpreted differently by software writers. In particular, the method for
designing punching shear reinforcement can be problematic and, in the authors' experience, most engineers end up carrying out
this calculation by hand as computer values are, at best, variable. This is not to say that no capable software is available, but that
the engineer needs to be sure that the package being used takes into account all the parameters required in the code.

Column fixity:

Some slab packages assume pins at column locations; this is normally acceptable for slab flexural design. However, if bending
moments are developed, they will affect both punching shear design and column design. If the column-pinned assumption is
made, a separate frame analysis may be required to calculate column moments.

Boundary conditions:

Owing to the inherent continuity of reinforced concrete construction, elemental design packages often require restraint conditions
to be specified at the boundary edges. The forces generated then need to be transferred to the restraining member. The element
design package will not check the validity of these boundary conditions and the engineer must do so. For example, a beam
framing into a thin wall may be closer to pinned than fixed. Many frame programs overestimate the moments transferred between
flat slabs and boundary columns. Inadequate consideration of these factors could lead to cracking in the wall, under-design of
the beam and, in the case of flat slabs, cracking and additional deflection.

Torsion:

When a structure is not dependent on torsional resistance for equilibrium, most codes say that torsion can be ignored. However,
if torsional stiffness is present in a computer model, the equilibrium found will rely on torsion and the torsional stresses
developed should be designed for. Some packages deal with torsions in the post-processing of results, and some assume that
the torsional resistance of all elements is zero. Others will leave it to the engineer to take into account. Again, the engineer must
understand the assumption implicit in their design and the computer package being used.

Stiffness:

In many packages, stiffness is simply the elastic section properties of the concrete. This is usually adequate for an ultimate limit
state design, but will tell the engineer little about the likely serviceability performance. Stiffness is affected by the elastic modulus
of the concrete, which varies because of creep. A simple short-term/long-term modulus may not be relevant for the case
considered. It should also be noted that for a C40 concrete to BS 8110-2: 1985 Structural use of concrete - Code of practice for
special circumstances(3) gives a range of elastic modulus of 22-34kN/mm^sup 2^. This can be refined if the aggregate type is
known. However, if an accurate prediction of serviceability behaviour is required, relying on default values could be problematic.

Stiffness is also affected by the tensile strength of the concrete that dictates the extent of cracking. In practice, there are large
variations in tensile strength for any given compressive strength, and this tensile strength varies with age. Normally, it is the
strength at the time of cracking that is important. Once the concrete is cracked, tension stiffening comes into effect, and a
number of methods can model this. It is important to understand the limitations of any model. In terms of stiffness, reinforced
concrete is far from an elastic or even elastic-plastic material, and models for accurate prediction of serviceability behaviour need
to be thoroughly checked and the underlying assumptions considered. It is certainly not acceptable to predict the deflection of
members by assuming uncracked elastic properties, particularly with slender members where the cracked stiffness is
significantly reduced.
Redistribution:

Codes generally allow redistribution from the moments calculated using gross concrete properties. Non-linear analysis will
'automatically' allow some redistribution, due to cracking. If further hand redistribution of the moments is undertaken, greater
overall redistribution than that assumed by the code will be implied. In any case, suitability of code rules dealing with detailing
should be carefully considered when non-linear analysis has been used for the ultimate limit state.

Intrinsic movements:

Unlike structural steel, concrete changes in volume through shrinkage and heat of hydration. The amount is often significant
when compared with normal inservice temperature variations. If such movements are restrained, significant stresses can build up
and may cause cracking. This invalidates deflection assumptions, and at worse causes failure of restraining elements, e.g. shear
failure of end columns in long continuous structures. These effects are unlikely to be considered in the computer analysis and the
danger is that over-reliance on the computer output will result in the engineer also ignoring them.

Several of the above issues come together in flat slab design, where there is a trend to use thinner and longer spans. This has,
in part, been encouraged by the reduction in the safety factor for reinforcement and by the use of high-strength concrete. As a
result, flat slab design tends to be controlled by punching shear and the serviceability limit state. There is concern that
inadequate description of stiffness is leading to a situation where some flat slabs will not perform as intended in the long term. As
a minimum, reinforced concrete design packages should include warnings when code span-to-depth ratios are being exceeded.

Hand checks:

The term 'hand check' is perhaps wrong. What is required is a progression from simple analysis that can be easily verified
through to final analysis, with each step being validated by the one before.

Consider the design of an irregular flat slab. Initial sizing and reinforcement quantities may be determined from span-to-depth
ratios and the moment tables in BS 8110: Part 1: 1997 Structural use of concrete - Code of practice for design and
construction(4) or yield-line analysis. This may then progress to a two-dimensional frame of a more typical bay, and finally to a
grillage or finite element analysis, if required. At the extreme, if deflections are critical, the finite element analysis may need to be
non-linear. Each layer builds on the previous, discrepancies can be considered and, if not readily explainable, the models
checked. It should be noted that even for a regular flat slab, there is a tendency to move to a finite element analysis. With current
software this may be quicker than a two-dimensional frame, but any assumption that the answers are any more accurate is not
necessarily correct. With experience, it will soon be found that the hand methods give results that are reliable if not better than
the computer approach.

Other more straightforward checks include:

* checking that the sum of reactions equals the applied load; this check is not only valid for the model but also for individual
elements within it

* checking that the support and mid-span design moments in a continuous beam add up to wl^sup 2^/8; use of standard end
restraints will also allow a loose check on the magnitude of redistribution assumed

* checking the load increase (and face shear) in a column at any given floor is approximately equal to the load on the floor area
notionally supported by the column

* checking the moments at flat slab interior columns comply with where m and m' are the moment capacities in hogging and
sagging at the column location and P is the column reaction

* checking selected members with the charts in BS 8110-3: 1985 Structural use of concrete - Design charts for singly reinforced
beams, doubly reinforced beams and rectangular columns(5); although the tables still incorporate a 1.15 safety factor on the
steel, they should still highlight any gross errors
* checking that span-to-depth ratios are in accordance with the code, unless a deflection analyses acknowledging the non-linear
behaviour has been carried out.

These checks may be considered by some as overly simplistic. However, it is the authors' opinion that such simple checks can
locate most gross errors introduced by using computers. The checks can be valuable in understanding the accuracy of design.
For example, there are at least three ways you can design a stocky column to BS 8110 - equation 39, the charts in Part 3, and by
considering plane sections. For the same column, a range of 24-32mm bars is dependent on the method. In this particular case,
the simplest method (equation 39) was actually found to be more accurate than the Part 3 charts. Discrepancies were easy to
explain and added to the understanding of those involved.

There must be a wealth of similar or better approximate checks/design methods known to CONCRETE readers, and it is hoped
that this note will prompt suggestions. If enough contributions are made, these may be combined into a paper on simplified
methods. It would also be interesting to hear whether, and how, universities teach approximate methods. It is clear from
examples of coursework and exam papers provided by University College, London, that some universities require the use of
simple methods in developing a design. As so little design is analysis, students should understand that the computer is where the
design is refined not necessarily begun.

Validation:

The final issue to be considered is the validation of software. Some practices validate their own software formally, others relying
on a network of users to highlight problems. What is clear is that there is little or no exchange of validation information across the
industry. This is costly and could be perceived as wasteful. Possible solutions are:

IMAGE PHOTOGRAPH 1Figure I: Final analysis of the base to an offshore concrete gravity structure. Initial design was carried
out by hand using standard tables and assumptions of uniform bearing pressure. During the design process, soil structure
interaction and actual applied load distribution were taken into account. The initial design was then checked against this final
analysis.

* An independent organisation to verify software. This would need careful planning in terms of liabilities if a validated program is
shown to have an error.

* The development of a set of validation models for checking software

. These would need to be secret to avoid 'tuning' of the software and always run the risk of being obsolete, as new developments
require validation. It would, however, be possible to define the extent of validation clearly.

* The setting up of a voluntary network of users within the industry so that problems can be circulated and discussed.

All these have their difficulties, and further discussion is welcomed. A further plea is for software houses to produce detailed
documentation on the technical assumptions made.

Conclusions:

Computer packages greatly increase the speed of the design of concrete structures. However, there is concern that there is an
over-reliance on the output and insufficient education on approximate methods of checking/designing. There is a need for users
to understand the assumptions behind the software they are using, and an even greater need for engineers to learn simplified or
approximate methods. Similarly, software validation needs to be co-ordinated. Comment on all these aspects is welcomed, to
enable better guidance to be produced and perhaps show how the industry can move forward with software validation.

References:

1 .THE INSTITUTION OF STRUCTURAL ENGINEERS. Guidelines for the use of computers for engineering calculations, 2002.
2 .STANDING COMMITTEE ON STRUCTURAL SAFETY. Structural safety 1997-99: Review recommendations: 12th Report of
SCOSS, The Institution of Structural Engineers, London. 2001.

3. BRITISH STANDARDS INSTITUTION. BS 8110-2: 1985 Structural use of concrete - Code of practice for special
circumstances.

4. BRITISH STANDARDS INSTITUTION. BS 8110-1: 1997 Structural use of concrete - Code of practice for design and
construction.

5. BRITISH STANDARDS INSTITUTION. BS 8110-3: 1985 Structural use of concrete - Design charts for singly reinforced
beams, doubly reinforced beams and rectangular columns.