As shown in section 3.11, the production of say a thousand unique sets of data for extensively testing an engineering program, requires that the data be engineered, and that software be written to produce the sets of data. Before the sets of data can be produced, a classification of the various types of data is needed.
Building a set of a hundred self-checking models for verifying the correctness of a program for the structural analysis of frameworks, takes several man years. Before commencing on such a task, it is recommended that the software to be verified should be benchmarked. Benchmarking is comparing the results produced by a program with results which have been produced by at least one other program or with published results in text books and papers, see chapter 9.
Structural calculations include those for the structural analysis of a framework and those for the design of structural components: beams, slabs, columns etc. The set of data required for the structural analysis of a framework differs from the set of data required for the production of a set of structural calculations. Most items of data for a structural analysis program; whether integer e.g. for the number of joints, or real e.g.
for applied loads, can vary uniformly over a wide range of values; furthermore within any set of data for a structural analysis, there is little dependency of any item of data on any other. A set of data for a structural design calculation differs to that for the analysis of a structural framework in that there is a high dependency on the items of data among themselves, many items of data being dependent on a code of practice, sometimes given in tables for which there is no sensible alternative to a table, sometimes requiring engineering judgment for example for the degree of quality control applied on site, appraisal of a load sharing factor, whether or not lateral restraints are provided at loading positions etc.
This chapter shows that the items of data required for the structural analysis of a framework have a higher degree of dependency among themselves than would be expected, and that a unified classification of types of data for both the structural analysis of frameworks and the structural design of components, is both worthwhile and achievable.
The phrase engineer the problem which is used in this chapter, means develop a pragmatic system after grasping the problem's salient features, or get to grips with the problem, Americans would say get down to the nitty-gritty, i.e. act in the way that engineers do throughout their life with every problem they come across. Theoreticians will frown at the system developed in this and the next chapter; they will launch into matters such as periodicity and adequacy of coverage, argue about the way that the type of data is classified, and so on. The two facts overriding all others are that:
• the automatic generation of sets of data for testing engineering software must be easy to specify and
• the data must be limited to practical ranges appropriate to each parameter alone and in combination with all other parameters which have a shared dependency.
The reader is asked to go with the flow; if after grasping the principles, the reader disagrees with, for example, the way that the type of data is classified, and considers that there is a simpler way, then he/she should develop their own system.
4.1 Data for structural analysis
It would appear to be straightforward to test a linear elastic structural analysis program for the robustness of its own logic by writing a program to pick random numbers from within preset ranges for: number of joints, number of members etc. and generate hundreds of files of data which an analysis program could run in batch mode. Such an approach would fail for the following reasons:
• some joints would not be connected into the framework
• injudicious joint and member releases would cause mechanisms
• injudicious selection of member properties would cause axial and shear deformation strain energy to swamp the bending strain energy
• injudicious positioning of loading on the members would cause loading applied to members to come off the end of members
• a randomly produced connectivity table would produce rubbish
• for the rare occasions when results would be produced, if they were plotted, it would be rare for them to look sensible e.g. a plot of deflections which looks like a spike could be due to an unsupported joint having a deflection of say 100 km when all the other deflections were less than a metre
• if the modulus of rigidity were very low in comparison to the modulus of elasticity, then the resulting deflection plot would give the impression that all the members were pinned at the joints rather than fixed etc.
For the above reasons, it is necessary to engineer every set of data before it can be run successfully by a model for the structural analysis of a framework. The test data should be realistic.
4.2 Data for structural design
As mentioned at the beginning of this chapter, structural design calculations have a high dependency of items of data on other items of data in the set of data for input to a structural design program, using structural timber for example:
• for a beam of width 50 mm, the minimum depth is typically 50 mm and the maximum depth is typically 300 mm
• for a simply supported beam of span 3.6 m, the minimum depth of the beam is typically 150 mm and the maximum depth is typically 300 mm
• permissible bending and tension stresses pbat parallel to the grain vary from typically 3 N/mm² to 20 N/mm²
• permissible compression stresses parallel to the grain vary from typically 69% of pbat to 84% of pbat
• permissible compression stresses perpendicular to the grain vary from typically 14% of pbat to 32% of pbat
• permissible shear stresses parallel to the grain vary from typically 9% of pbat to 14% of pbat.
Thus beam parameters: width, depth, span, permissible stresses etc. may not vary independently from each other, it follows that each set of data to be used for testing a program for the design of a structural timber component, must be engineered.
It is necessary to formalise the various types of data, and design a system for providing the dependencies between the parameters so that logic may be written for the automatic generation of sets of data which in turn may be used to test the logic of a model. This chapter gives examples of the different types of data required for the production of a set of design calculations or for the production of a set of data for the structural analysis of a framework.
It is not possible to devise sets of engineered data without incorporating logic such as
"A>B" (Boole, 1847) named a Boolean expression after the English mathematician and logician George Boole. Praxis (1990), is shown throughout this document in Courier which has a fixed spacing which enables calculations to be lined up, for example:
The grade tension stresses apply to members assigned to a strength class and having a width of 300 mm. For other widths of members, the grade tension stresses should be multiplied by the width modification factor.
IF d>b
Largest section dimension +h=d mm ELSE
Largest section dimension +h=b mm ENDIF
IF h<=72
Width modification factor +K14=1.17 ELSE
Width modification factor +K14=(300/h)^0.11 ENDIF
There are two occurrences of the IF-ELSE-ENDIF programming structure in the above example of Praxis and four assignments commencing with a plus sign, which is a programming device, in this case to tell the computer that an assignment follows.
Another programming structure is: REPEAT-UNTIL-ENDREPEAT; yet another programming device is a set of four question marks ???? to tell the computer to prompt the engineer for data. Generally such programming structures and devices are described as they are introduced. Lines commencing with keywords such as IF are omitted from the output calculations. Assignments are copied to the output calculations omitting the leading plus, optionally the right side of the assignment is repeated but with numerical values substituted for any symbolic variables (henceforth just variables for brevity), finally the new value assigned is shown followed by any units.
Width modification factor K14=(300/h)^0.11 =(300/350)^0.11 =0.98319
When space permits, all three lines are concatenated onto one line e.g.
K14=(300/h)^0.11=(300/350)^0.11=0.98319
Appendix C includes a calculation for the design of a flanged reinforced concrete beam section in bending with optional shear, bar curtailment, lap length and span/effective-depth checks. The first calculation in appendix C is of average complexity and length (approximately 2000 lines); all of the examples in this section are taken from this calculation. Of course design calculations vary greatly, nevertheless the two typical calculations included in appendix C do give some idea of the variety of items of data in a set of data for component design. Text in the following examples, has been extracted from the calculation for the flanged reinforced concrete beam with simplification to the text where possible. There follows some of the different characteristics that an item of data for either the structural analysis of a framework, or the structural design of a component, may have.
4.3 Regular sets of integer data
Types of bar (see table 3.26 in Code) are as follows:
0. Plain bars
1. Type 1 deformed bars 2. Type 2 deformed bars
Type of bar (0-2) +Type=????
The engineer may respond to the ???? prompt with 0, 1 or 2. Other values will produce a warning and require the engineer to revise the data to be 0, 1 or 2 before proceeding.
The characteristics of this set of data:
the response must be integer first value 0
last value 2 number of values in the set 3
These four characteristics are sufficient to define all values in the set. There is no requirement for the first value to be the minimum value, it is necessary that the software should be written to generate the 3 values required whether the range of integers is increasing or decreasing. Obviously increasing or decreasing for this range is a further characteristic but there is no need to specify it, as the direction of increase is established by the two end values of the range.
The commonest set of integer data is the response to Yes/No using the digits 1 or 0 respectively. The 1 and 0 have become popular on electric on/off switches, they have two advantages over Y & N:
• they are independent of language
• they do not require the user to question whether an upper or lower case response is required.
There are many prompts for a Yes/No answer, there are thirteen in the concrete example in appendix C, for example:
Comp.bars to control defln (1=Yes/0=No) +ans5=????
Another example for a regular set of integer data, may be used to specify the set of data which can be given in response to the prompt:
Characteristic concrete strength +fcu=???? N/mm²
Although BS 8110 (BS 8110) does not restrict designed concrete mixes to a set of strengths, it gives guidance. In no circumstances may the concrete strength be less than 15 N/mm². The grade of concrete for reinforced concrete must not normally be less than 25 N/mm², but strengths down to 15 N/mm² may be used for concretes made with lightweight aggregates.
The characteristics of normal weight concrete strengths are:
the response must be integer name of parameter fcu first value 25 last value 40 number of values in the set 4 type of data 4
which will be used to generate concrete strengths: 25, 30, 35 & 40 N/mm². We can classify the type of data as 4 when we require four values to be specified between the first and last value of the range, with equal intervals between.
4.4 Irregular sets of integer data
An example of a small set of irregular integer data is that for reinforcing bar diameters viz: 6 8 10 12 16 20 25 32 40 & 50 mm. Steel section sizes such as Universal Beams, provide examples of large sets of irregular integer data. There are various strategies for dealing with small sets of irregular data such as that for reinforcing bars:
(a) Specify all the values in the set, give the set a reference number and provide a means of accessing all or part of the set as appropriate to the application.
(b) Provide a table (as in appendix C) and fault data which is not valid.
(c) Engineer the problem.
(a) Is cumbersome; as there are only a few sets of such data in any engineering discipline, it has been found simpler to have just one set containing the bar diameters, if other such sets are needed then they can be added, and values selected by reference to the location in the set of the first and last locations required for the application.
(b) Is already present in the calculation, a different strategy is preferable for checking.
(c) Bar diameters are used for different purposes, 6 8 10 & 12 cover the most popular choices for distribution steel; 12 16 20 & 25 cover the most popular choices for the main bars in slabs; 25 32 & 40 cover the most popular choices for the main bars in beams.
Each of these three sub-sets of data can be handled as for the regular sets of integer data.
Diameters 6 8 10 & 12 need to be defined name of parameter dia first value 6 last value 12 number of values in the set 4 type of data 4
Diameters 12 16 20 & 25 need to be defined name of parameter dia first value 12 last value 25 number of values in the set 4 type of data -4
The selected sizes would be: 12 16.3 20.7 25 for type of data =4; to switch on integer rounding, we say the type of data =-4 which will specify bar diameters: 12 16 20 & 25 as required.
Diameters 25 32 & 40 need to be defined name of parameter dia first value 25 last value 40 number of values in the set 3 type of data -3
The selected sizes would be: 25 32.5 & 40 for type of data =3, to switch on integer rounding, we say the type of data =-3 which will specify bars of diameter: 25 32 & 40 as required. When it is required that all or nearly all bar sizes are appropriate to a parameter, then in the system devised, the values should be saved in a vector za() and the first and last values should refer to the first and last locations in za().
Diameters 6 8 10 12 16 20 25 32 40 & 50 need to be specified.
name of parameter dia first value 3 last value 9 number of values in the set 7 type of data 100
In the forgoing we have defined the type of data =100 as looking up a set of values held in za() and selecting a value from the third in the set i.e. 10, to the ninth i.e. 40, in the set inclusive. The selected sizes would be: 10 12 16 20 25 32 40, assuming that the assignment:
za(1)=VEC(6,8,10,12,16,20,25,40,50) which assigns za(1)=6, za(2)=8 and so on, has been made. It will be clear from the foregoing that for small sets of irregular integer data, with a bit of initiative, it is possible to engineer subsets from irregularly spaced sets and yet still keep the definition of the data simple i.e. specifying just: type of data, first & last value. Although the number of values has been declared in the foregoing, there is no need to declare it, as the number of values may be deduced from the type of data.
The system allows for 26 regularly occurring sets of data to be stored in za() to zz(), with access dependent on the type of data being selected by references 100 to 125.
For a large set of integer values e.g. rectangular hollow section sizes for stainless steel, a different strategy is needed, we need to call a procedure. It is desirable to keep the specification to the same structure as the forgoing so that a complete PARAMETER specification for any model can be contained in just one table.
A procedure named tri needs to be invoked name tri first value 3 last value 72 type of data 1E40
In the above, declaring the type of data =1E40 means that the name given is that of a procedure which is to be invoked, the first and last values being arguments for that procedure i.e. values passed to that procedure. The name tri is apposite to steel section sizes which generally have a section designation formed from: serial depth, breadth and mass/metre for open sections excluding angles; or serial depth, breadth and thickness for angles and closed sections with the exception of circular hollow sections. Section 5.12 describes the procedure tri and how it is included in the parameter table.
4.5 Sets of real values as data
Although sets of real values in look-up tables are common in British Standards, generally sets of real values for input data are rare in calculations, reals as data items tend to be limited only by a range e.g. the prompt:
Moment before redistribution +Mbef=???? kNm
invites the engineer to type a bending moment. Obviously a bending moment of 1E20 kNm would be unrealistic, so the engineer author of the calculation chooses values for the maximum and minimum bending moment and checks any input data for being within range. The choice of maximum and minimum bending moments depends on the section size, this introduces the subject of dependency, as the width and depth of a beam and the maximum permissible percentage of reinforcement fix the maximum permissible bending moment, some engineers' arithmetic is required. Although sets (as
distinct from ranges) of real values are rare, they do occur, e.g. in timber K values (BS 5268), by using the method described in section 4.4 for reinforcing bar diameters, it is possible to engineer a set or subset of values, yet still keep the definition of the data simple i.e. specifying just: type of number, first & last values and number of values in the set.
4.6 Dependency
As an example of dependency of one item of data on another item of data, consider a simply supported beam of length L, subjected to a partial uniformly distributed pudl, which commences at a distance La from the left end of the beam and ends at a distance Lb from the left end.
├────────Lb────────┤
├───La────┤ ┌pudl
┌───┴────┐ Data required for a partial UDL.
══════════╧════════╧═════
▲ ▲
├───────────L───────────┤
Beam span +L=???? m
Partial uniformly distributed load +pudl=???? kN/m Distance to start of UDL +La=???? m
Distance to end of UDL +Lb=???? m
All four items of data are real, thus each can be defined by a start value, end value and the number of equally spaced values in the set, say 3 for this simple explanation but the number of values in a set may take any sensible value e.g. 166.
Variable Start & end values The set of data L 1 10 1 5.5 10 pudl -0.5 -20 -0.5 -10.25 -20 La 0 9.9 0 4.95 9.9 Lb 0.1 10 0.1 5.05 10
To test for robustness of the logic, we must run every value in a set of data against every other value in every set for:
• both sets increasing
• one set increasing, the other decreasing.
Software to automatically generate sets of data containing all such combinations will generate invalid sets of data such as:
L La Lb Reasons for invalidity
1 4.95 10 La & Lb must come within span L 5.5 9.9 5.05 Lb must be greater that La
For this simple example we need to restrict any values of La in each set to be less than say L-0.1, and to restrict any values of Lb to be greater than say La+0.1 and less than or
For this simple example we need to restrict any values of La in each set to be less than say L-0.1, and to restrict any values of Lb to be greater than say La+0.1 and less than or