Tank Weights in API 650 — Dead Load, W​_structural, Misc, and Which Field Feeds Which Check

Why the Weights Tab Trips People Up

In a hand calculation you write down "dead load" once and reuse it. In API 650 that single idea splits into several different weights, each defined on its own basis and used by a different check. The stored product weight that governs shell thickness is not the weight that resists roof uplift; the dead load that stabilises the tank against wind is not the same number the anchorage tab uses for bolt sizing. Enter a weight in the wrong place and the calculation will still run — it will just quietly under- or over-check one of those cases.

TankCode 650 keeps all of this in one place: the Weights tab rolls up every component, then hands the right sub-total to each downstream module. This article explains, field by field, which bucket your input lands in and which checks read it — so you can enter each weight exactly once and trust every tab that depends on it.

The Six Weights Every Tank Design Uses

Everything on the Weights tab is sorted into a small set of named weights. Learn these six and the rest of the app becomes readable:

• W_sShell dead load — shell plate plus everything attached to and carried by the shell (framing, ladders, shell nozzles, insulation).
• W_rRoof dead load — roof plate plus everything the roof carries (roof structure, roof nozzles, platform, handrail, a share of snow).
• D_lsNominal (uncorroded) shell dead load — the same items as W_s but on an uncorroded basis, used for wind overturning.
• D_lrNominal (uncorroded) roof dead load — the roof analogue of D_ls.
• W_fBottom / floor dead load — bottom plate, annular, bottom internals, bottom lining.
• W1/W2/W3Anchorage uplift bases (API 650 Table 5.20a) — corroded and nominal weight groups that resist each uplift load case.

Two other names you will see in reports are W_p (stored product weight, from diameter, liquid height, and design SG) and W_o (total operating weight = corroded steel + product). Those are computed from geometry and SG, not from Weights-tab appurtenance fields, so they are not the focus here.

The one rule that prevents most mistakes: ask "does this item hang on the shell, or does the roof carry it?" Shell-carried items build W_s/D_ls and are represented at the shell centre of gravity. Roof-carried items build W_r/D_lr and are represented higher up, at the roof CG — which gives them a longer lever arm in the overturning check. (Real appurtenances are distributed mass; for the overturning calculation each group is collapsed to an equivalent CG.) Putting a roof item on the shell side understates seismic and wind overturning.

Shell-Side Fields — What Builds W_s and D_ls

These fields describe mass that is attached to, and supported by, the shell. They add to the shell dead load and are represented at the shell centre of gravity in the overturning checks.

Roof-Side Fields — What Builds W_r and D_lr

These fields describe mass the roof carries. This is where W_structural lives — in the app it is the sum of the roof-carried items over and above the bare roof plate (roof structure/rafters, roof nozzles, platform, handrail, misc). Because these are represented at the roof CG, they contribute the most to the overturning lever arm.

What "Misc appurtenances" actually does: this catch-all field is bucketed on the roof side. Use it for permanent roof-carried mass you have not itemised elsewhere. Because it lands in W_r, it increases roof-uplift resistance and overturning resistance and flows into the anchorage uplift bases — it is not a cosmetic line item. Do not use it for shell-carried mass; there are dedicated shell fields for that.

DL1, DL2, and the "Additional Dead Load" Field

On the roof you will see the load-combination symbols DL1 (roof plate dead load, from the plate thickness) and DL2 (additional dead load — a user input). Their sum, DL = DL1 + DL2, is the dead load used in the roof strength combinations (cases T and U in the app's Appendix R block).

DL2 is the field to reach for when you have a permanent, roof-borne load that is not one of the itemised appurtenances — fireproofing, a permanent coating system, a distributed equipment allowance. Within TankCode 650, the value you enter as the roof's additional dead load (DL2) is incorporated into W_r and therefore into the anchorage W1/W3 uplift bases as well. This is a software implementation choice — DL2 is not itself an API 650-named weight variable — but it is consistent with API 650 E.2.2 treating W_r as including "any permanent attachments." Enter it once on the roof and every downstream tab sees it.

Erection Weights, Insulation, and Snow

Some inputs are not part of the supplied tank steel but still matter for one or more checks. TankCode 650 keeps these in an erection/temporary group so they do not silently inflate the supply weight, then applies each where the code intends:

• Shell & roof insulation / cladding — added at erection. Shell insulation joins the shell dead load; roof insulation joins W_r and therefore the roof-uplift and overturning resistance.
• Snow load on roof weight_snow_intensity_kg_m2 — snow is a live load, not dead load, so it is not fully concurrent with the seismic case. API 650 does not prescribe a snow-participation percentage for the seismic effective weight — Annex E's roof term uses dead weights (W_s + W_rss), and the §5.11 / anchorage load table lists snow as its own separate full-value load line, not folded into W_r. TankCode 650 therefore leaves the fraction of snow included in the operating W_r as a user-supplied input with no built-in default: the field weight_snow_seismic_frac is blank (0) until you set the value your design basis requires. Left at 0, snow is excluded from W_r entirely, matching the code's separate-load-line treatment; enter an ASCE 7-derived fraction to include a share. The full snow intensity always drives the roof strength combinations (balanced/unbalanced S_b/S_u) regardless of this factor.
• Erection agitator, heat exchanger, external pipes, misc — temporary or non-supply attachments. They are tracked for the erected-weight scenario and, where relevant, the operating dead-load buckets used by the sliding check.

How Each Downstream Check Reads These Weights

Once the buckets are built, each module reaches for the specific weight the code assigns to it. This is the part worth memorising, because it explains why the same physical mass appears with different values in different tabs.

Roof & Appendix F (roof uplift)

The roof strength cases use DL = DL1 + DL2 plus snow/live and external pressure. The Appendix F frangibility and roof-uplift limits compare internal design pressure against the junction capacity, with the roof dead load D_lr (and shell dead load D_ls) providing the hold-down that raises the allowable uplift pressure. A heavier, correctly-bucketed roof raises the pressure the tank can take before the roof-to-shell joint governs.

Seismic (Annex E)

The seismic overturning check uses the operating (corroded) shell and roof dead loads W_s and W_r, combined with the impulsive and convective product masses, to form the ringwall moment M_rw. That moment drives the anchorage ratio J — the single number that decides whether the tank is self-anchored. Because W_r is represented at the roof CG, weight you route correctly to the roof side generally increases the resisting moment and tends to reduce J — though the net effect also depends on seismic mass participation, the impulsive/convective split, and how uplift is distributed, so it is not strictly one-for-one. The practical point stands: mis-bucketing a roof item as a shell item can make a real difference to the anchor decision.

Anchorage (Table 5.20a — W1, W2, W3)

The anchorage tab does not simply reuse W_s/W_r. API 650 Table 5.20a defines its own uplift weight bases. The W1/W2/W3 categories below are API 650 definitions; the specific list of which itemised fields TankCode maps into each is the software's implementation of "permanent attachments acting on the shell," and is described here so you can audit it:

• W1 (per API 650 Table 5.20a) — corroded weight of the roof plates + corroded shell + corroded permanent attachments acting on the shell, excluding the roof framing/structure. TankCode maps the roof-side appurtenances (roof nozzles, roof lining, external roof structure, platform, handrail, misc, and DL2) into this "attachments acting on the shell" group. Resists the internal-pressure and net-uplift cases.
• W2 (per API 650 Table 5.20a) — W1 plus the roof plates and framing acting on the shell. TankCode maps the rafters / roof structure + vertical ladder into this framing addend.
• W3 (per API 650 Table 5.20a) — the nominal (uncorroded) analogue of W1, used for the hydrotest-pressure and frangibility uplift cases.

The takeaway: the roof-structure and DL2 fields you entered flow into these bases with the correct corroded/nominal treatment automatically. You never re-enter a weight on the anchorage tab. Because the field-to-base mapping is a software interpretation, confirm it against your governing edition of Table 5.20a if a project requires strict traceability — TankCode implements the 2025 (14th edition) Table 5.20a footnote text.

Wind & Sliding (§5.11)

The wind overturning check uses the nominal dead-load moments built on D_ls (shell + framing) and D_lr (roof plate + attached structural). The separate sliding-friction check uses the operating (corroded) totals W_s + W_r + W_f against the wind shear. Two different bases, two different checks — from the same fields you already entered.

Engineering Basis — Nominal vs Corroded, and Where the Bases Come From

For reviewers who need the "why," here is the code basis behind the two design bases the app uses:

• §5.2.1(a) — the default. Dead load includes the corrosion allowance "unless otherwise noted." So W_s, W_r, and W_f are computed on the corroded steel basis. These feed the §5.11.4 sliding check and, because Annex E states no nominal exception, the Annex E seismic effective weights.
• §5.11.2.1 — the explicit override. The wind-overturning dead-load moments M_DL / M_DLR are built on the nominal (uncorroded) weight of shell + framing and roof plate + attached structural. That is why D_ls / D_lr use the nominal buckets while W_s / W_r use the corroded ones — same components, different basis, each per its governing clause.
• E.2.2 — W_r includes permanent attachments. This is why roof structure, roof nozzles, platform, handrail, DL2, and misc all belong to the roof-side bucket and act at the roof CG, rather than being lumped onto the shell.
• Table 5.20a — the anchorage W1/W2/W3 split. The anchorage bases are additive-only groups kept separate from the Appendix F / wind-moment weights, so refining an anchorage assumption never disturbs the other tabs' overturning numbers.

Reference-PDF caution: some vendor calculation PDFs deviate from these clauses (for example, by using a single dead-load basis everywhere, or by bucketing roof framing on the shell side). TankCode 650 implements these API 650 requirements using the weight-mapping methodology described in this article — following the clause text for the defined weights, and applying documented software assumptions (such as the snow-participation fraction and the field-to-W1/W2/W3 mapping) where the code leaves implementation detail open. If a legacy reference disagrees on a defined weight, check the clause before matching it.

Practical Checklist

• Decide shell-carried vs roof-carried for every item before you type it. That single decision sets the CG and lever arm the overturning checks use.
• Use DL2 (additional dead load) for permanent, distributed roof loads (fireproofing, coatings, equipment allowance) — not the shell fields.
• Use Misc appurtenances only for roof-carried mass; it lands in W_r, so it is not a throwaway number.
• Enter snow as an intensity, not as a lump — the app applies the correct fraction to the seismic/overturning case and the full value to the roof strength case.
• Never re-enter a weight on the seismic or anchorage tabs. They read the Weights-tab buckets automatically, with the correct corroded/nominal basis per clause.
• If an anchor decision is marginal, review which items are roof-side vs shell-side before adding steel — re-bucketing a mis-placed roof item can move J on its own.

TankCode 650 shows the full weight roll-up — supply, erection, operating, and hydrotest scenarios plus the W_s/W_r/D_ls/D_lr and W1/W2/W3 load parameters — on the Weights tab, and links each value into the modules that consume it. For the checks that read these weights, see our seismic design guide and anchorage design guide.

Related reading: Continue with Foundation Load Report, Fixed Cone Roof Design, and Design Specific Gravity to keep the full weights-to-checks workflow connected.