Assumed Haunch Depth

2 posts / 0 new
Last post
a rigeb
Assumed Haunch Depth

Hello,

So if you go into "Loading Details" under details report there is a section for slab haunch loading. In that section there is an assumed haunch depth column which shows a depth and a corresponding load at 10th points along the girder. It appears to me that PGSuper is using this assumed haunch depth to determine the reaction/deflection due to the haunch. At the end of the analysis, under the "Haunch Details", PGSuper has a "required slab offset" along with a "CL haunch Depth" which are different values from the assumed haunch depth. My question is, shouldn't the process be iterative such that deflections/reactions are then recomputed with the actual haunch depth?

As a follow up to this, is there a way to tell PGSuper to not include a haunch DL and instead the user inputs one as a user load? I know you can tell it to not check Haunch geometry under the project criteria, however even if that is toggled, PGSuper still applies a haunch based off the top flange shape effect.

Thanks very much!

Rick Brice
Assumed Haunch Depth

The slab haunch load and the slab haunch geometry are definitely a chicken-egg problem.

There are different ways to assume the slab haunch for purposes of estimating dead load. WSDOT assumes there is no camber in the beam. TxDOT uses an assumed camber.

The required haunch ("A" dimension, slab offset) is computed based on deflections and roadway geometry. This needs to be iterated by the user if you are just running reports.

The automated designer will do the iterations, if enabled.

PGSuper doesn't permit automatically defined loads to be replaced with user loads. One technique is that you can get the haunch load from the details report, apply equal and opposite loads to negate its effects, and they add your own user load.

Log in or register to post comments