Skip to content

Distributed surface loads

*Dsload, <option>
<surface name>, <load label>, <Load magnitude>

This option defines a distributed surface load acting on the surface with the name <surface name> with a defined load magnitude.

  • <option>: Specify how the load should be applied. The load can either be applied:

    • instantaneously (without any temporal delay) using <option> = instant

    • linearly increasing with step time (0% of the prescribed magnitude are applied at the beginning of the step and 100% at the end of the step time) using <option> = ramp

    • using a user defined amplitude defined prior to the step definition using <option> = Amplitude = <amplitude name>

    • user-defined load using <option> = user. The user has to supply the user_load.o file (see user loads). The definition of a <Load magnitude> is not required in this case.

  • <surface name>: Surface name to which the load should be applied.

  • <Load label>: Load label defining the type of load and the direction of action of the external distributed load. Currently available are:

    Load type
    Uniform pressure
    Tangential traction
    Traction in global direction
    Water weight
    Springs
    Compliant base boundary condition
    Drainage condition (seepage)
    Inflow/Outflow

Uniform pressure

Distributed load acting perpendicular to the surface face.

*Dsload, <option>
<surface name>, P, <Magnitude>

Positive values for Pi act along the outward face normal (mechanical sign convention, tension is positive).

Tangential traction

Distributed load acting tangential to the surface face.

*Dsload, <option>
<surface name>, T, <Magnitude>

Note

This is only valid for 2D simulations, since the tangential direction is only unique in 2D.

Traction in global direction

Distributed load acting in global coordinate direction <Global direction {X,Y,Z}> on the surface face.

*Dsload, <option>
<surface name>, <Global direction {X,Y,Z}>, <Magnitude>

Water weight

Distributed load acting perpendicular to the surface face compensating(positive) pore-water pressure by its deadweight (e.g. to simulate the flooding of slopes):

*Dsload, <option>
<surface name>, SWP

The magnitude of the load is calculated such that the (only positive) more water pressure acting on the surface is compensated.

Springs

Distributed surface load which corresponds to a support of the surface <surface name> (or, for beam elements, the edge set running along the beam) by a plurality of spring elements acting between the model and a fixed, immovable ground ("Winkler-type" elastic foundation).

Four families of ground springs are available, chosen via <spring type>:

<spring type> Direction of action Compatible elements
spring-ground-n normal to the element edge 2D solid elements only (triangular/rectangular, incl. axisymmetric)
spring-ground-t tangential to the element edge 2D solid elements only (triangular/rectangular, incl. axisymmetric)
spring-ground-(x,y,z) fixed global coordinate direction beam elements and 3D solid elements only (tetrahedral/hexahedral)
spring-ground-(x,y,z)-tabular fixed global coordinate direction, nonlinear \(F\)-\(u\) law beam elements and 3D solid elements only (tetrahedral/hexahedral)

No N/T equivalent for beams/3D, no X/Y/Z equivalent for 2D solids

There is no spring-ground-n/-T for beam or 3D solid elements, and no spring-ground-x/-Y/-Z for 2D solid elements. Assigning a spring to a surface of an incompatible element type aborts with an error at assembly. More springs will be available in the future.

All four families additionally support the relative displacement (installation) formulation described below, and — like every Dsload — the <option> mechanism described at the top of this page (instant, ramp, Amplitude=..., user; the last requires the user_load.o file, see user loads), except where noted for tabular springs.

Linear springs

*Dsload, <option>
<surface name>, spring-ground-n, <k> [, <formulation>]
<surface name>, spring-ground-t, <k> [, <formulation>]
<surface name>, spring-ground-x, <k> [, <formulation>]
<surface name>, spring-ground-y, <k> [, <formulation>]
<surface name>, spring-ground-z, <k> [, <formulation>]

The nodal spring force is obtained by numerical integration of \(f = k(\boldsymbol{u}-\boldsymbol{u}_{ref})\) over the element edge/face/beam-length, projected onto the spring's direction of action (see below). <k> is the constant spring stiffness; <formulation> is the optional 'relative'/total keyword described below (default total, omit for the previous, backwards-compatible behaviour).

Upcoming release

The optional 'relative'/total will be available with the upcoming release

Units of <k> depend on the element type

<k> is not a discrete spring stiffness — it is a stiffness density that gets integrated over the element, so its unit depends on what is being integrated over:

Springs on... integrated over unit of <k>
2D solid edges (N, T) an edge length (unit out-of-plane thickness) force/length³, e.g. kN/m³
3D solid faces (X, Y, Z) a face area force/length³, e.g. kN/m³
beam elements (X, Y, Z) the beam length force/length², e.g. kN/m²

The 2D and 3D cases match the classical subgrade-reaction modulus \(k_s\); beam springs are one length dimension "shorter" since they are only integrated along a line, not over an area. Getting this wrong by a factor of the tributary length/area is the most common spring-modelling error - verify a single-element patch test against \(f = k\cdot A \cdot u\) (solid faces) or \(f=k\cdot L \cdot u\) (beams) before trusting the value in a full model. See the Benchmark section for worked examples.

Normal and tangential springs

spring-ground-n acts perpendicular (in normal direction) to the surface; spring-ground-t acts tangential to the surface. Both are only available on 2D solid element edges (triangular/rectangular, including axisymmetric elements, where the usual \(2\pi r\) integration factor is applied automatically).

Where do springs attach

Springs that are defined as distributed surface loads (DSloads) attach at the integration points of the element edges/faces forming the surface to which they are assigned to. The resulting nodal forces are obtained by means of numerical integration.


Figure 1: Examples of springs assigned to surfaces using the DSload keyword.

Reference configuration only

The direction of action of N/T springs is evaluated once from the reference (undeformed) configuration and does not rotate with the deformation, even in an NLGEOM step — there is currently no follower-direction (large-rotation) formulation for 2D ground springs.

Global direction springs

spring-ground-x, spring-ground-y and spring-ground-z act along the corresponding fixed global coordinate axis, regardless of the orientation of the beam or 3D element face the spring is assigned to — e.g. an inclined raker beam supported by spring-ground-y is always resisted vertically, not perpendicular to its own axis. Only available on beam elements and 3D (tetrahedral/hexahedral) solid element faces.

Follower area (NLGEOM), 3D solid faces only

For springs on 3D solid faces, an NLGEOM step activates a geometric (follower-area) stiffness contribution accounting for the change of the tributary face area with deformation — the direction of action itself remains fixed in space, since it is a global-direction spring by definition; only the area it is integrated over follows the deformation. Beam elements do not currently support a follower-length update under NLGEOM (the beam's reference-configuration length is used regardless of the NLGEOM step setting).

Nonlinear (tabular) springs

Appending -tabular to a global-direction spring label replaces the constant stiffness <k> by a nonlinear force-displacement law read from a plain-text data file:

*Dsload, <option>
<surface name>, spring-ground-x-tabular, <filename> [, <formulation>]
<surface name>, spring-ground-y-tabular, <filename> [, <formulation>]
<surface name>, spring-ground-z-tabular, <filename> [, <formulation>]

<filename> points to a two-column text file of \((u,F)\) pairs, sorted by ascending \(u\), defining a piecewise-linear force-displacement curve — see Figure 2 below.

At every Newton iteration, the current (relative) displacement is looked up in the table; both the interpolated force and the local secant slope of the active table segment are used directly as the spring force and its consistent tangent stiffness, respectively. No additional linearisation step is required, and full quadratic Newton convergence is retained even through table segments of very different local stiffness (e.g. a near-flat, fully mobilised plateau).


Figure 2: Tabular (nonlinear) spring assigned to a beam by means of a SPRING-GROUND-*-tabular load, reading a force-displacement curve from a text file. Note: the label shown in this figure, spring-n-Fu, reflects an earlier, pre-release naming convention; the current keyword for the case depicted (a beam supported by a nonlinear tabular spring) is spring-ground-y-tabular (or -X/-Z, depending on the direction of action), as described in this section.

Units of the table's force column depend on the element type - same rule as <k> above

The force column of the table is not a discrete force; like <k> for linear springs, it is a force density that is integrated over the element:

  • beam elements: force per unit beam length, e.g. kN/m
  • 3D solid faces: force per unit face area (a traction), e.g. kN/m²

The example table in Figure 2 (F in kN) is illustrative; for a beam it should be read as kN/m.

<option> (RAMP/INSTANT/AMPLITUDE) has no effect on tabular springs

Unlike constant-stiffness springs, the tabular force-displacement law is evaluated directly against the (relative) displacement at every iteration — the loading path is governed entirely by the structure's own displacement history, exactly like a real nonlinear spring, not by an externally imposed amplitude. <option> remains mandatory input syntactically but has no bearing on the result for tabular springs.

N/T springs have no tabular variant

There is currently no spring-ground-n-tabular/spring-ground-t-tabular — nonlinear springs are only available for the global-direction family, i.e. on beam elements or 3D solid faces.

Relative displacement (installation) formulation

By default, ground springs act on the total displacement of the model, \(f = k\,\boldsymbol{u}\): the spring is force-free only when \(\boldsymbol{u}=\boldsymbol{0}\), i.e. at the very start of the analysis. This is inconvenient for springs that represent a support installed at some point during the analysis — a strut installed only after an excavation step has already deflected a wall, for instance — since such a spring would otherwise immediately register a large, unphysical force corresponding to the deflection that had already occurred before it was installed.

An optional <formulation> keyword, appended as the last entry on the data line, selects between the two available formulations:

*Dsload, <option>
<surface name>, <spring type>, <k or filename>, relative
<surface name>, <spring type>, <k or filename>, total

  • total (default — omitting <formulation> entirely is equivalent and remains backwards compatible): \(f = k\,(\boldsymbol{u}-\boldsymbol{u}_{ref})\) with \(\boldsymbol{u}_{ref}\equiv\boldsymbol{0}\) for the whole analysis.

  • 'relative': the spring is installed strain-free. Upon the first assembly of the step in which the load is (re-)declared, numgeo captures the converged displacement field at that instant — i.e. the state at the end of the previous step — as the reference field \(\boldsymbol{u}_{ref}\); from then on the spring acts on \(\boldsymbol{u}-\boldsymbol{u}_{ref}\). Re-declaring the same spring (same surface and load label) in the following step inherits \(\boldsymbol{u}_{ref}\) rather than capturing it anew, so the spring keeps its original installation state across step boundaries instead of being reset force-free at the start of every step it is re-declared in.

Strut installed after excavation

** step 2: excavate; strut not yet present
** (no *Dsload entry for the strut surface in this step)
*Step
...
** step 3: install the strut, force-free at the (already deflected) wall position
*Dsload
strut_surface, spring-ground-n, 1.5e5, relative

Remeshing

'relative' springs store a snapshot of the global displacement field at activation. This is currently incompatible with a change of mesh topology (e.g. PFEM remeshing) occurring between the step in which the reference state was captured and any later step in which it is used; numgeo aborts with a descriptive error if the size of the stored reference field no longer matches the current global solution vector, rather than silently producing incorrect results.

See the Benchmark section for a worked example demonstrating strain-free activation.

Compliant base boundary condition

The compliant base boundary condition is used to impose a seismic signal at the bottom of the FE model and at the same time damping downwards propagating waves by applying equivalent viscous forces. The distributed force acts in global direction Dir to the element faces of surface <surface name> to which the force is applied.

*Dsload, <option>
<surface name>, <compliant type>, <Dir>, <magnitude>

The <Magnitude> is defined as \(\rho \cdot c_{p,s}\) of the underlying material, where \(\rho\) is the density and \(c_{p,s}\) is the wave speed (\(c_s\) for shear waves and \(c_p\) for compression waves) The subsequent line then reads:

Two types of springs are implemented, which can be chosen by setting <compliant type> to:

  • compliant: This corresponds to the "implicit" implementation, where the current velocity \(v\) is used to calculate the viscous stress

  • compliant0: This corresponds to the "explicit" implementation, where the velocity \(v_0\) from the previous (converged) time step is used to calculate the viscous stress.

Drainage (seepage) condition

A special boundary condition is needed if the phreatic surface reaches an open, freely draining surface. In such a case the pore fluid can drain freely down the face of the dam, so at all points on this surface below its intersection with the phreatic surface. Above this point negative pore water pressures occur, with their particular value depending on the solution. This drainage-only flow condition consists of prescribing the flow velocity on the freely draining surface in a way that approximately satisfies the requirement of on the completely saturated portion of this surface.

*Dsload, <option>
<surface name>, drainage-w, <magnitude>

The <magnitude> can be approximated as \(s_k \dfrac{k^{sat}c}{\gamma_w}\)

Where \(s_k\) is a scaling factor usually in the range of \(10^3 \leq f \leq 10^4\), \(k^{sat}\) is the saturated hydraulic conductivity, \(\gamma_w\) is the unit weight of water and \(c\) the characteristic element size of the underlying finite element.

Upcoming release

With the upcoming release of numgeo, the characteristic element size of the underlying element will be automatically determined by numgeo.

Inflow/Outflow

This boundary condition allows to define a flow for infiltration boundary problems. The flow velocity \(v\) in m/s on the specific surface is directly defined in <value>. Negative values correspond to an inflow over the model boundary <surface name> into the domain. Positive values prescribe an outflow (exfiltration/evaporation).

*Dsload, <option>
<surface name>, flow-w, <value>

Note that the flow specified via the velocity takes places continuously on the defined surface area, independent of i.e. the pore water pressure. It might, however, vary over time, e.g. by coupling it with an Amplitude using the <option> keyword.