Reliability-Based Limit States Design for Onshore Pipelines
Bibliographic record
Abstract
The traditional approach to pipelines design is to select a wall thickness that maintains the hoop stress below the yield strength multiplied by a safety factor. The main design condition implied by this approach is yielding (and by extension burst) of the defect-free pipe. Failure statistics show that this failure mode is virtually impossible as the majority of failures occur due to equipment impact and various types of defects such as corrosion and cracks. Recent investigations show that these failure causes are much more sensitive to wall thickness than to steel grade. As a consequence, current design methods produce variable levels of safety for different pipelines — small-diameter, low-pressure pipelines for example have been shown to have higher failure risks due to mechanical damage than large-diameter, high-pressure pipelines. In addition, the current design approach has been shown to have limited ability to deal with new design parameters, such high steel grades, and unique loading conditions such as frost heave and thaw settlement. The paper shows how these limitations can be addressed by adopting a reliability-based limit states design approach. In this approach, a pipeline is designed to maintain a specified reliability level with respect to its actual expected failure mechanisms (known as limit states). Implementation involves identifying all relevant limit states, selecting target reliability levels that take into account the severity of the failure consequences, and developing a set of design conditions that meet the target reliability levels. The advantages of this approach include lower overall cost for the same safety level, more consistent safety across the range of design parameters, and a built-in ability to address new design situations. Obstacles to its application for onshore pipelines include lack of familiarity with reliability-based approaches and their benefits and lack of consensus on how to define reliability targets. The paper gives an overview of the reliability-based design approach and demonstrates its application using an example involving design for mechanical damage.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.002 | 0.003 |
| Meta-epidemiology (narrow) | 0.001 | 0.000 |
| Meta-epidemiology (broad) | 0.000 | 0.001 |
| Bibliometrics | 0.001 | 0.000 |
| Science and technology studies | 0.000 | 0.001 |
| Scholarly communication | 0.001 | 0.001 |
| Open science | 0.001 | 0.001 |
| Research integrity | 0.001 | 0.001 |
| Insufficient payload (model declined to judge) | 0.003 | 0.001 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".