Skip to Main Content
AutoPIPE Ideas Portal

Welcome to the AutoPIPE Ideas Portal. We value your feedback, and our team regularly reviews your ideas and considers them for future improvements to our products and services.

You have 3 options for providing feedback:

  1. VOTE for an existing idea. The popularity of an idea helps us understand its importance to the community.

  2. COMMENT on an existing idea. We want to hear your unique point of view.

  3. ADD a new idea. You can always submit a new idea if no existing one describes your suggestion.

When you add, vote or comment on an idea you will also be subscribed to that idea and receive status updates. Please note we may merge or rename ideas for better clarity for the community. Thank you for your support and feedback.

Status Needs review
Categories Reporting
Created by Guest
Created on Apr 26, 2024

Add design margins to piping loads being sent to structural

When it comes to exporting pipe support loads from AutoPIPE to STAAD, PipeLINK is an effective tool. While PipeLINK has most of the necessary functionality, there is a lack in the ability to add a Design Margin to the pipe support loads sent from AutoPIPE to STAAD. The ability to apply a Design Margin to pipe support loads is vital for the following reasons:

  • Allows for a Design Margin to be applied to the initial set of pipe support loads transmitted to STAAD in early phases of a project, and that Design Margin covers minor increases in pipe support loads resulting from design development later in the project. This reduces the amount of rework of the structural design as the project develops.

  • A Design Margin accounts for unknowns and minor errors between pipe stress models and the real world (i.e., provides an extra safety factor).

There are 2 ways of applying a Design Margin that are necessary: a universal Design Margin and an individual Design Margin.

A universal Design Margin is applied to all components of pipe support loads with a specific nominal diameter/pipe size (first preference) or Pipe ID (second preference). For example, the pipe stress engineer may need to add a universal Design Margin of 10% to all pipe support loads for 2” NPS piping (i.e., apply to X, Y, and Z loads at all nodes that are 2” NPS).

An individual Design Margin is applied to a specific load component (X, Y, or Z) for a specific load case at a specific node. For example, the piping stress engineers may need to add an individual Design Margin of 20% to the seismic load cases in the Y-direction at node A05.

There are a few different ways of inputting Design Margin that would be useful:

  • a percentage (e.g., 20%) that is added to the load calculated by AutoPIPE

  • a specified value (e.g., 400 lbf) that is added to the load calculated by AutoPIPE

  • a minimum value (e.g., 5000 lbf)

It is important to note that the Design Margin should not apply to any values shown in AutoPIPE (or AutoPIPE output reports). The Design Margin should only be applied when exporting pipe support loads with PipeLINK.

Attached is an example workflow with example dialog boxes to help illustrate the concepts described above. Below are pros and cons of putting the design margin in AutoPIPE and STAAD.

AutoPIPE

  • Pros

    • Allows the piping stress engineer to provide design margins as they see fit

    • Creates a seamless workflow by only requiring the use of AutoPIPE by the piping stress engineer

  • Cons

    • Structural could manually apply design margins in STAAD thinking design margins still needed to be added (can be prevented with communication)

STAAD

  • Pros

    • None

  • Cons

    • The piping stress engineer would not be able to apply the loads they deem necessary

    • A structural engineer would need to take margin loads from the piping stress engineer, potentially leading to errors in inputting the margin loads

    • Would add to the workflow of a structural engineer when it is the piping stress engineer's responsibility to apply design margins

This idea has been discussed previously with Mike Dattilio over a Teams call.

  • Guest
    Reply
    |
    May 1, 2024

    Adding the Design Margin capability to PipeLink would provide flexibility that allows PipeLink to be used by different major EPC companies. Some of the major users follow a design process where design margin is added to pipe support loads by Structural Engineers, while other major users follow a design process where design margin is added to pipe support loads by Pipe Stress Engineers.

    Our company prefers the latter due to the Pipe Stress Engineer's familiarity with the behavior of the piping system and their understanding of potential pipe support loads not directly calculated in the AutoPIPE analysis. One important example of such a situation is encountered when considering pipe support loads on a directional anchor. In the pipe stress analysis, thermal growth can potentially be balanced at a directional anchor and result in an unreasonably low axial thermal load being determined by AutoPIPE at the directional anchor. To ensure an adequately sized structure is designed to support the piping system axially, some major users follow a design process where the pipe stress engineers would calculate (by hand) an appropriate axial load to submit to the Structural Engineer. Having the Design Margin capability in PipeLink would support this design process.

    1 reply
  • Admin
    Phil Senior
    Reply
    |
    Apr 30, 2024

    In the original design for the load transfer to STAAD made the decision on how the loads should be combined and factored and that it should lie with the Structural Engineer. STAAD has the capability to factor the loads applied to meet the design code requirements. As piping engineers we wouldn't all know what factors to apply or what loads should combine, so the decision to not do this and only transfer the unchanged loads was a deliberate one. I discussed this Idea with my team and we don't believe this has changed and we feel the factors can be and should be applied in STAAD only. Further this would avoid the possibility of double counting the factors.

    At this stage I do not see us changing this approach unless others feel it to be useful and a better workflow