Extent of software validation 1

[GD_P]

Hello community,

I have question regarding the validation of structure analysis and design software.
As almost all of us use software for structure design.
Do you validate them and up to what extent?

1) Analysis

2) design as per the applicable code

3) Applicability of points 1 & 2 for:

a) Only for simple members i.e., one beam and one column OR

b) 2D / 3D frames with columns, beams, bracings & no of storeys etc.

4) Other tools such as response spectrum analysis, wind load generation tools, time history analysis etc.

I think the validation shall cover all aspects such as mentioned in 1 to 4,

otherwise if analysis is wrong but design is correct, such validation doesn't make any sense.

We use STAAD Pro and thinking to validate it. I just want to know how other engineers handle this?

Any help would be appreciated.


GD_P

 

[JAE]

Josh - good points. Yes that is the old shear/moment/deflection screen from RISA 2D - this one from about 1989. You had to hit the F2 key to get it...this was the MSDOS version prior to Windows.

The biggest errors in modeling that I've seen are:
1. Incorrectly using boundary conditions (supports) to mimic elements of reality that are not included in the model but affect the model.
Examples: Using rigid supports where the actual stiffness of what's modeled has some flexibility. Using fixity vs. pin vs. springs incorrectly.

2. Incorrectly assuming design results are accurate without carefully going through each member, or group of members, to set unbraced lengths, material properties, etc.
Examples: Not entering unbraced lengths correctly. Not assigning the correct design code vs. the applied loads - i.e. ASD loads with LRFD code provisions.

3. Incorrectly modeling member orientation in space (i.e. is the WF oriented strong axis or weak axis in bending.

4. Not FIRST looking at the deflected shape before diving into the member force and design results. If it don't deflect as you expect, it probably wasn't modeled right in the first place.



Check out Eng-Tips Forum's Policies here:
faq731-376

 

[271828]

I have found very few errors in programs I've used.

However, I have run into numerous examples of program acting in unexpected ways. It takes a pretty detailed verification to find these and determine what parameters need changed, develop a work-around, or decide to abandon the offending feature.

Examples from four reputable programs:

In the late 90s, STAAD's steel member design defaulted to fully braced. All truss webs, moment frame columns, etc. have unconservative designs by default.

In about 2003, RISA ignored element slenderness effects in axial strength calcs, so it computed unconservative phiPn for some common shapes like HSS8x8x3/16, and many W-shapes.

With ETABS steel design, about four years ago, if the member has several unbraced segments, it computed Cb for each segment, then use the lowest Cb for ALL segments.

In SAP2000, if I build a floor bay with frame and shell elements, and define an area load "uniform to frame," one would think that would result in member loads similar to a tributary area approach, but it doesn't. To make it do that, one has to change the orthotropic shell properties also.

In SAP2000, the steel design preferences includes L/### deflection limits. Even when those are set, it will not consider deflection unless you also set "Consider Deflection" to Yes. (Why the @#!* would one not want to do this?)

In most of these examples, the program isn't "wrong," but by default, it will spit out something you would probably not want to use. Bottom Line: It takes some effort to make sure a program is performing as the engineer desires. There's no substitution for breaking out a calc pad, pencil, calculator, and making sure you know what it's doing. If that's too daunting of a task for a particular type of design, the engineer should re-assess whether or not he should be designing that type of element or structure. Some additional technical studying might be in order.

 

[ThomasH]

Hi
This discussion makes me think of an old truth. "Anybody can make a mistake, but to really mess things up you need a computer."

To test software with the ambition to ensure that it always produces the correct results, provided the input is correct. I would say that is a hopeless task. Software quality is the vendors business. We usually can't check the implementation of the mathematics into the source code. And we have to realize, testing can only prove the presence of errors, not the absence.

What we can, and must do, is to ensure that we use the software correctly, know its applicability and check the results.

That said, I would say that no software's are flawless. That is why we must check the results, always.

Some developers have lists of known errors, that can be a good start. In my experience, errors in the results are often due to input errors, user mistakes. But I have seen reputable software (no names) produce results that were erroneous. It was several years ago (mid 90's) and that particular bug disappeared in later versions. We had contact with the vendor but they could not explain what was wrong at the time.

Redarding design codes I haven't worked with that type of software för several years. The previous mentioned software had design codes but that was not the issue at the time. But as I understand it from collegues, errors do occur even if they are fairly rare.

Thomas

 

[Enrique2015]

Any respectable software should include multiple verification examples for analysis and design capabilities, against book examples, theory, journals, design manuals ,etc. If they don't have dot use it!

http://www.structuralapps.com

http://www.Tilmanllc.com