| Introduction to Design Theory |
| Design Objectives |
| Searching for the Best Design |
| ASD vs LRFD |
| Example Problems |
|
References |
| Report Errors or Make Suggestions |
| Make Donation |
Section DC.1
Introduction to Design Theory
Last Revised: 11/04/2014
This concept of design is not particular to structural steel, however since this course is often a first exposure to detailed design, this section outlines the principles and concepts associated with the design process.
It is of great value for engineers to understand the intricacies of the design process and its impact on final product and those that use it to a depth not permitted in this application. There are several references that are of great value to helping understand the design process and its impact, however the author's favorite is a thought provoking text entitled To Engineer is Human, by Henry Petroski.
The Nature of Design
Design can be described as the process of conceptually creating something that does not yet exist. To accomplish this, designers make use of their knowledge of material behavior and/or of processes coupled with their ability to analyze (i.e. predict) the future behavior of their design to meet some specified need. The success of the design is highly dependent on the thoroughness of the designer's knowledge and a clear understanding of the expected behavior of the final product.
The nature of design is such that there is normally more than one feasible design (a design that will "do the job"). A design is defined by a set of design variables that can be used in analyzing the design. A design is considered to be feasible if it satisfies the performance criteria (or constraints) defined for the problem. Out of the available feasible designs, some are "better" than others. Generally the goal of the designer is to find optimum design. The optimum design is generally considered to be the one design that best satisfies the criteria for the project. Typically there is some kind of objective function that can be computed from the variables that define a design. The value of the objective function is used to compare feasible designs in order to determine the "best" or "optimum" design.
Another significant feature of design is that it is an iterative process. When the design process starts, there are a lot of unknowns. Consequently, the designer must make assumptions about various components of the design. As the design progresses, many of the assumptions can be replaced by known facts when decisions are made about previously unknown components. As the assumptions are refined and replaced, the design is reanalyzed repeatedly.
For example, when designing a floor system, the engineer must know the dead loads in order to proceed with the analysis. Unfortunately, at the start of the design process the designer does not know what the system consists and, therefore, cannot accurately compute the loads on the system. To begin the process, the engineer makes assumptions about the loads based on probable loads. Using the assumed loads, the design proceeds and components are selected. As components are selected, the load assumptions can be re-evaluated and the analysis performed again. This process iterates until the final calculations use refined loads based on the chosen components.
Design Optimization
Since the objective of design is to find the optimum design, the design problem can be characterized as an optimization problem stated as:
Minimize or Maximize fobj(dv1,dv2,dv3, ... ,dvn)
subject to:
- fconstraint_1(dv1,dv2,dv3, ... ,dvn) compared to allowable value
- fconstraint_2(dv1,dv2,dv3, ... ,dvn) compared to allowable value
- fconstraint_3(dv1,dv2,dv3, ... ,dvn) compared to allowable value
- .....
- fconstraint_m(dv1,dv2,dv3, ... ,dvn) compared to allowable value
Where
- fobj = the objective function
- dvi = the ith design variable
- n = number of design variables
- fconstraint_i =the ith constraint function
- m = number of constraint functions
A feasible design is one where all the constraint functions are satisfied. The optimum design is a feasible solution that represents the design with the best objective function value.
For example, let us say that planet "A" gets a message from planet "B" that "B"ites need a magic potion that "A"ites have a soon as possible. If the potion does not arrive in time then all the "B"ites will all die. With several planets with strong gravity fields along the way, there are several paths by which a rocket could reach planet "B" once it is fired from planet "A". The "A"ites must determine the direction and initial velocity for the rocket that will get there the quickest.
In this problem, the objective function is the time that it takes for the rocket to reach planet "B". The only constraint is that the rocket has to hit planet "B". The two design variables are the initial direction and initial velocity.
Let's see how that problem breaks down mathematically.
The objective function, in this case, would be the function that computes the time it takes for a rocket to reach planet "B".
fobj = TimeInTransit(Velocity, Angle)
The actual computation must take into account the gravitational effect of the other planets in the solar system and is somewhat complicated.
The constraint function, on the other hand, is fairly simplistic. It monitors the progress of the rocket and becomes true if the rocket arrives at planet "B".
fconstraint_1 = HitPlanet(Velocity, Angle) must equal "True"
The design variables are the independent variables needed to compute values for both the objective function and the constraint function. In this case the design variables are:
Velocity = the initial velocity of the rocket leaving planet "A"
Angle = the initial direction of the rocket as it leaves planet "A"
Figure DC.1.1
Acceptable Trajectories
To evaluate the alternatives, a computer program was written to analyze the performance of the rocket. The design variables are entered into the program and the computer computes the trajectory of the rocket to determine if the design variables result in a feasible design (i.e. does the rocket hit planet "B"). If the design is feasible, then the objective (time in transit) is computed and saved to compare against other designs.
The analysis returned three feasible solutions to the rocket problem. Many other combinations (not shown) were tried, but rejected because they were not feasible solutions (i.e. they did not hit the planet). Figure DC.1.1 shows the resulting trajectories. The Table DC.2.1 summarizes the results.
|
Table DC.1.1 |
|||||||||||||||||||
|
|||||||||||||||||||
The preferred alternative is solution #2 because it has the best objective function result.
The preceding example was very simplistic. Most engineering solutions, particularly in steel design, are much more complicated having a multitude of design variables and constraints. The objective function can also get complicated if there are competing objectives, such as least cost AND least weight.
When we get to designing steel elements, you will get a better feel for this process.
Design vs. Analysis
Design and analysis are two separate activities and it is useful to know the difference between the two.
Analysis is the evaluation of a defined problem. There is no selection of new alternatives or components. Analysis simply computes performance and returns performance results. For example, if you have a beam of given size with a load on it, the analysis may return reactions, shear & moment values/diagrams, and comparison with allowable performance relative to specified constraints (such as strength, deflection, clearance, etc.) Another way to say this is that analysis takes a set of design values, performs calculations, and returns requested data for use by the design process.
The process of design uses the results of analysis to make decisions about the problem description. Based on the results of the analysis, the design process changes the problem description (design variables) based on analysis results and then requests additional analysis. The design process repeats until the best solution is found.
You will find that most problems that involve design will require multiple analyses. In structural design, this means that being proficient using spreadsheets, MathCad, or other computer based computational tool becomes extremely useful. Computers are particularly useful in handling repetitive tasks.
The Function of Design Codes and Specifications
Considering the rocket problem, note that the solution is only hypothetical until the rocket is launched. No one knows for sure if it will really work. Was there a mistake made in the analysis routine? Was some constraint not considered? Is there a constraint that has never been encountered before? You never know until the design is implemented. In some sense every design is a theory that is unproven until it is actually implemented. To minimize the possibility of failures, we constantly learn from the profession's experience. Failures are particularly useful if they reveal constraints not previously known.
Unfortunately, too many failures are just a repeat of mistakes by someone else on another project. Mistakes in computation and oversights in design considerations can be minimized by peer review. Both in-house review and review by building code enforcement authorities are necessary. Identifying relevant constraints is the function of the design codes and specifications.
The design codes and specifications are the means that society and the profession use to help prevent reoccurrence of the failures of the past. As new constraints are revealed or weaknesses are detected in existing constraints, the codes and specifications are updated to correct the problem. All designs are required to comply with the specification so as to take advantage of the past experiences. Consequently all structural design specifications are updated every few years to capture the best knowledge available.
One state fire marshal was once heard to comment that when a designer or design team chooses to ignore a code provision they are making the deaths of many people or the loss of much property to be in vain. He pointed out that no provision makes it into the design code without the loss of many lives or substantial loss of property. Every code provision potentially adds cost to the development of a project, so there is great pressure to include only those provisions that are really necessary.