Setting Velocity and Transport Values

These commands are used within grid-based boundary conditions blocks to set velocity conditions and boundary conditions for any transport properties (such as temperature or concentration).

Velocity Conditions

The scripted Velocity command sets velocity conditions to all nodes within the parents's block shape:

Velocity (dir),(style),<(value)>,<(time)>

In XML files, the command is:

<DisBC dir='(dir)' style='(style)' vel='(value)' time='(time)'
                function='(function)' id='(id)'/>

where

• (dir) is 1, 2, or 3 to specify the velocity direction as in the x, y, or z direction (In scripted files, (dir) can be x, y, or z or can be R or Z if axisymmetric). You can also set velocity in a direction that is not along an axis. For details see help on skewed velocity conditions
• (style) specifies the style of the applied velocity. Each velocity depends on two parameters specified by arguments (value) and (time). If either argument is not supplied, they are set to zero. The standard units are velocity units for (value) and alt time units for (time) (but the units may change depending on the (style) setting).
• (function) - if the (style) is function (or 6), this attribute in XML files specifies a user defined function. In scripted files, the user defined function should replace the (value) argument and must be entered as quoted text. The function should evaluate to the desired velocity in velocity units.
• (id) - this attribute in XML files specifies an ID for the boundary condition. In scripted files, IDs are set using the BoundaryID command.

Moving Wall Velocity Conditions

A moving wall boundary condition models a wall moving through the grid normal to the x, y, or z axis with any provided velocity. This condition sets velocity on the wall surface and will include as many nodes on either side of wall as needed for optimal results. This type of boundary condition is illustrated on the left and it shows a wall moving in the x direction that is to the right of all material points. The wall starts on nodes selected by this Velocity command, but can move by a provided displacement function of time. Based on the current wall position, this condition sets velocity on all active nodes outside the wall (notes to the right of the pictured wall) and on all active nodes inside the wall (left of the pictured wall) that are within a distance d (in units of grid cells) of the wall. The option is currently only in OSParticulas, but will me moved to NairnMPM in its next major update.

If desired, this condition can specify a velocity gradient to have the nodal conditions vary with position. For example, for a wall moving in the x direction, a provided velocity gradient sets [math]\displaystyle{ dv/dx }[/math] and the x-direction velocity boundary condition applied to nodes near the wall are:

    [math]\displaystyle{ v_i = v_{wall} + {dv\over dx}\left(x_i-x_{wall}\right) }[/math]

where [math]\displaystyle{ v_{wall} }[/math] is the wall velocity specified by this boundary condition, [math]\displaystyle{ x_i }[/math] is position of node with a boundary condition, and [math]\displaystyle{ x_{wall} }[/math] is the current wall position.

In scripted files, moving wall velocity boundary conditions are created by Velocity commands that set the (style) to "gradient" and adds some new parameters:

Velocity (dir),"gradient",(velFxn),0,(depth),<<gradFxn)>,<(dispFxn)>

In XML files, the DisBC command adds some new attributes::

<DisBC dir='(dir)' style='6' function='(velFxn)' depth='(depth)'
                gradfxn='(gradFxn)' dispfxn='(dispFxn)' id='(id)'/>

where the presence of a (depth) attribute makes this command a moving wall boundary condition. In the above commands, the parameters are:

• (dir) is 1, 2, or 3 to specify wall moving in the x, y, or z direction (In scripted files, (dir) can be x, y, or z or can be R or Z if axisymmetric). Moving walls could potentially be oriented in any direction or even curved, but only straight walls normal to a grid axis are implemented now.
• (velFxn) is a user defined function of time (t in alt time units) and initial nodal point position (in length units). The function should evaluate to the wall velocity in velocity units.
• IN scripted files, the fourth parameter must be "0". The value is ignored, but it is needed for parameter alignment.
• (depth) has two functions. The sign of (depth)</t> determines if the wall is at minimum edge (if minus) or positive edge (if plus) of material points along the selected axis. Walls are expected to be outside all material points and this parameter determines where the wall is relative to all material points. The magnitude of (depth) determines how many nodes will get velocity boundary conditions (the value of d in the above pictured moving wall in units of grid cells). Experience suggests the (depth) should be at least 1 grid cell and maybe 1.5 grid cells when using <a href="MPMMethod.html">spline shape functions</a>. It can be adjusted for optimal results.
• (gradFxn) is a user defined function of time (t in alt time units) and current wall position (in length units). The function should evaluate to a velocity gradient in the wall-axis direction in (velocity units)/(length units). If this parameter is omitted, the velocity gradient is assumed to be zero (all nodes near the wall get the same velocity). If (gradFxn)="mirror", the gradient will be calculated from velocities extrapolated to the grid by interpolating from two active nodes near (depth) grid cells from the wall to the current wall position and velocity (see nodes "1" and "2" in the above picture moving wall). A "mirror" gradient can improve boundary conditions in problems where you do not know the velocity gradient, but you do know it should not be zero.
• (dispFxn) is a user defined function of time (t in alt time units) and initial nodal point position (in length units). The function should evaluate to the current wall displacement from its initial position in length units. Often this function is integral of (velFxn), but may differ, such as to change initial position to be offset from the initial node. If omitted, the displacement is zero or the wall is fixed on the initial node.
• (id) - this attribute in XML files specifies an ID for the boundary condition. In scripted files, IDs are set using the BoundaryID command.

Skewed Velocity Conditions

Using two velocity conditions along two axes is not the same as setting a fixed velocity along the direction of the resultant velocity vector. To set velocity in a single direction that is not along a cartesian axes, you have to use a skewed velocity condition. In script files, the command is:

Velocity (skewDir),(style),(value),(time),(angle1),<(angle2)>

in XML files, the command is:

<DisBC dir='(skewDir)' style='(style)' vel='(value)' time='(time)'
                    angle='(angle1)' angle2='(angle2)'/>

where

• (skewDir) defines two or three axes. For 2D or axisymmetric analyses, it can only be skewxy (or 12 or skewrz). For 3D anlyses, it can additionally be skewxy, skewxz, skewyz, or skewxyz (or 12, 13, 23, or 123). Note that XML files must use the numeric options and not any of the "skew" options. When using two axes, those axes define the plane of the skewed direction. The option skewxyz means velocity in any arbitrary polar direction.

• (style), (value), and (time) mean the same as for velocity conditions along an axis. In scripted files, all these parameters must be supplied to preserve alignment of parameters through to the (angle) parameters.

• (angle1) defines the direction for the normal vector for the velocity as a clockwise rotation from the first axis in a skew pair. In other words, skewxy applies velocity in the direction (cos(angle1), -sin(angle1)), 0), skewxz applies velocity in the direction (cos(angle1), 0, -sin(angle1)), and skewyz applies velocity in the direction (0, cos(angle1), -sin(angle1)). For skewxyz, (angle1) is a polar angle as explained next.

• (angle2) is only used for skewxyz and it is the azimuthal angle. The normal vector will be (cos(angle2) sin(angle1) sin(angle2) sin(angle1), cos(angle1)).

Temperature Conditions

When doing conduction calculations, you can set fixed temperatures on the grid. Temperature boundary conditions are ignored unless conduction is activated. The scripted Temperature command sets emperature conditions to all nodes within the parents's block shape:

Temperature (style),(value),<(time)>

In XML files, the command is:

<TempBC style='(style)' value='(value)' time='(time)' function='(function)'/>

where

• (style) specifies the style of the applied temperature. Each temperature depends on two parameters specified by arguments (value) and (time). If either argument is not supplied, they are set to zero. The standard units are degrees K for (value) and alt time units for (time) (but the units may change depending on the (style) setting).
• (function) - if the (style) is function (or 6), this attribute in XML files specifies a user defined function. In scripted files, the user defined function should replace the (value) argument and must be entered as quoted text. The function should evaluate to the desired temperature in degrees K.

Thermal stresses are caused by temperature difference relative to the stress free temperature. If the stress free temperature has not been set, its default value is zero and thus temperature boundary conditions set the temperature difference. If the stress free temperature is set to a non-zero value, the temperature boundary conditions use the absolute temperature and the temperature difference is calculated by subtracting the stress free temperature.

Concentration or Poroelasticity Conditions

When doing diffusion calculations, these conditions set fixed concentration on the grid, but when doing Poroelasticity calculations, these same conditions set pore pressure on the grid. Only one of these options can be active in a single simulation. These boundary conditions are ignored if neither diffusion calculations nor poroelasticity calculations are activated.

When doing diffusion calculations, the concentration is set as a concentration potential from 0 to 1 where 1 is the saturation concentration of a material type. The scripted Concentration command sets concentration conditions to all nodes within the parents's block shape:

Concentration (style),(value),<(time)>

When doing poroelasticity calculations, the condition sets pore pressure. The scripted PorePressure command sets pore pressure conditions to all nodes within the parents's block shape:

PorePressure (style),(value),<(time)>

In XML files, the concentration and pore pressure commands are the same (the simulations determine which conditions are set):

<ConcBC style='(style)' value='(value)' time='(time)' function='(function)'/>

In the above commands:

• (style) specifies the style of the applied concentration potential or pore pressure. Each option depends on two parameters specified by arguments (value) and (time). If either argument is not supplied, they are set to zero. For diffusion, the standard units are dimensionless concentration potential for (value) and alt time units for (time). For poroelasticity, the standard units are pressure units for (value) and alt time units for (time) (but the units for each may change depending on the (style) setting).

• (function) - if the (style) is function (or 6), this attribute in XML files specifies a user defined function. In scripted files, the user defined function should replace the (value) argument and must be entered as quoted text. For diffusion, the function should evaluate to the desired concentration potential (between 0 an 1). For poroelasticity, the function should evaluate to the desired pressure in pressure units.

Boundary Condition ID

The BoundaryID command (in scripted files only) sets an ID to assign to subsequent boundary conditions. The main reason to assign IDs to boundary conditions is to control the calculation of reaction forces. The command is:

BoundaryID <(negnum)>

where (negnum) is an integer value (less than zero) for the boundary condition ID. All supported boundary conditions will use this ID until it is changed by another BoundaryID command. If (negnum) is omitted the ID reverts to zero. The number should be less than zero to avoid conflict with IDs for boundary conditions created by rigid material particles. The only boundary conditions that currently make use of an ID are velocity boundary conditions. In XML files, velocity boundary condition IDs are set with an attribute on the <DisBC> command.

Boundary conditions created by symmetry planes will automatically have IDs of -10, -11, -20, -21, -30, or -31, depending on the plane edge. Other boundary conditions should not use these IDs unless either there are no symmetry planes or you want the other boundary conditions lumped in with the symmetry plane boundary conditions.

Boundary conditions created when extrapolating rigid material particles before setting the boundary condition will all automatically have ID of -40. When using the ExtrapolateRigid mode, all boundary conditions created by rigid materials will have the same -40 boundary ID and the archived reaction force will be the total force on all those particles. In this mode, it is not possible to archive reaction forces from individual rigid material types.