Notional Load Method

[damstructural]

Does anyone have design experience using the Notional Load Method (aka Notional Force Method) for column design? How is this being implemented in other codes outside the US? The main question is what have they done with the K-factor? Has it been completely eliminated?

I learned about the Notional Load Method from a professor in grad school who was a pioneer of the method, but he got into political turf battles trying to get it into the US codes. Things are starting to change, as this method is in several foreign (non-US) codes, and may be added as an Appendix in an upcoming AISC as an optional method.

I've personally validated the method with the current code, with buckling theory, and test results. I think the theory is great, and I see lots of great advantages, but I'm completely ignorant of how it is being implemented in other codes.

The method is tested and described in this presentation from Cornell Univ.

http://ceeserver.cee.cornell.edu/tp26/TWResearchGroup/tpadd/Sarawit/july03.ppt

Conclusion, "The Notional load approach agrees better with the finite element results than the effective length approach does. Notional Load Approach 2c is recommended."

For more background, this topic is also discussed in the last half of thread507-96579. That thread was getting long so I started this one.

 

[J1D]

Can anyone give a follow-up of this thread?

The Notional Load (or Force) Method was mentioned and discussed a bit in the Thread507-96579(couldn't open it now). Afer this thread, I read a paper wrote by S.L. Chan, et al about a computer procedure using the method. It seems to me that the method is to replace the traditional ways for P-Delta and P-delta effects, simpler and superior. But what I'm most interested in and do not quite understand is "The member individual buckling strength does not need to be checked against the design codes. The concept of effective length is abandoned when using this approach which compares well with experiments..." I don't how come we can check individual member strenth without K values

 

[damstructural]

Check Structural Engineer Magazine Nov 2004 pg 24 (not to be confused with "Structures" magazine by ASCE) for a very nice article by Gregory Deierlein, PhD, PE. They are now calling this method "The Direct Analysis Method." This method will be introduced (to US codes) in the 2005 AISC Spec for Structural Steel Buildings. Its about time.

This short summary article is based on a July 2003 paper for the AISC Structural Stability Research Council Ad Hoc Committee on Frame Stability and AISC Task Committe3 10 on Stability. ASCE also published a paper supporting this method in 1997. Code development is an interesting process to watch. If it weren't for politics, this method would have been in the code 30+ years ago.

I'll be doing some research work on this method for tapered web members this Spring 05 with a professor who pioneered this method about 30 years ago. He gave up trying to convince AISC code writers who were convinced K-factors were the way to go. He's watched his idea spread around the world in almost every other code, and now its finally coming home to roost in the US. I feel lucky to be tiny part of this process.

To answer your specific question, buckling strength is still a function of design codes. The main theorectical difference in this method is that there must be a lateral load (almost always the case anyway) and you use the actual length and connectivity of the column-beams (no more K-factors). The key to this theory is having sufficient lateral load to induce a moment in the column. The strength of the column can be calculated based on the combination of axial and flexural stresses. You will love the simplicity of this method, especially with FEA analyses.

 

[J1D]

Damstructural,

The method seems to change something fundamental in structural design. But I cannot justify the rational of this approach to myself. Can you give a bit more explanation?

K value is indeed most uncertain stuff to me since long ago. I still remember the university assignment to calculate K value of a member in a steel frame through the calculation of G values. Up to now, we still have this headache. For a typical structural design the sequence is: structural modelling, load application, analysis and design. In most cases the design is a kind of verification of the pre-selected members. In other words, Code Check is usually the design work. The trouble is: to have the Code Check by a computer program or by hand calculation, you need to give the K value of each member. SAP2000 calculates K in code check if no K value is specified. I don’t know whether SAP2000 just lets the computer do the G value calculation and determine K. From this clue I can feel the possibility to get rid of determination of K.

As you mention, also given in the article, a member strength is assumed reached when the sectional stress equals (from axial force, resultant bending moments about two axes, which allows for the P-Delta and P-delta effects) material yield stress.

My question to the method are: 1) how to consider the effect of length and effective length of a member. Or no need to consider these since the stress from analysis includes these? Or axial buckling, flexural buckling do no longer exist because of the application of the Notional Loads? 2) If the lateral load on a structural is quite significant already, should the Notional Load be applied?

Please advise, thanks

 

[damstructural]

You should be careful letting SAP2000 assign K-factors for you. Try this little experiment: Analyze a small frame with moment connections and at least one hinged connection. For the hinged connection, try releasing the moment in the beam, and then rerun it with the moment released in the column. I was getting very different K-factors when I did this. I reported it as a bug, they agreed, and it may be fixed by now. Point is: hand calc your K-factors. Also, there have been errors in the AISC nomographs based on G values.

As for the application of the method, I'm still learning how it will be written up in the code. For sure I know that you use the actually length of the member (no more "effective length"). The amount of "notional load" or "fictitious load" required is debatable. It looks like the AISC is recommending an additional 2% of the axial load be applied laterally, in addition to the usual lateral loads. I'm not sure how this compares to other codes around the world.

The notional load was conceived for the case where there was no lateral load to begin with. If there is already significant lateral load on the column, then you may not need another (2%-10%)*Pu. On the other hand, adding in some extra moment load in the column is not a bad idea given the uncertainty of lateral loads, esp EQ.

What I do know for sure is that if we can kiss the K-factor goodbye, our designs will improve in efficiency, and we'll have more confidence in the answers. Its so perfect for computer analyses, which is probably what's driving this change at this time. I predict that in 5 years, you will put the K-factor charts next to the rivet design manual in a box in the library.

 

[damstructural]

Typo in my post (paragraph 3): I meant to write 2% - 10% of the APPLIED AXIAL LOAD. Not Pu. The amount of "notional load" to add in as a lateral force is based on a percentage of the amount of axial load.

 

[Denial]

I believe that the key point to understanding this "Notional Load" approach to beam-column design is that the analysis from which you extract the P and M values must be a rigorous second order (ie large displacement) analysis. The K-factors and G-values were only ever a crude way of bridging the gap betweeen first order and second order analyses, and are close to impossible to utilise unless the frame being analysed is nicely rectangular.

 

[J1D]

DamStructural,

Following your reminder, I tried SAP2000 (ver. 8.3.5.) with a goal post with fixed column bases. There still is a K-value difference. With a hinge at one end of the beam the K-value of column is 1.903, while K = 1.000 when the hinge is at top of a column. However, the code check ratios (all the members) for the two cases are the exactly same. K value of the beams is 1.000 in any case.

Another finding is when the members were split into two pieces, SAP2000 gave out different code check ratios. The reason is that one of the unbraced length ratios kept the same (1.00), which caused different Cr and Mr. When I changed that ratio to be 2.00, the results matched those without spit.