Augmenting Conditions Specifications#
The augmenting condition capability in Goma enables the addition of supplemental constraints and auxiliary conditions to the problem via standardized and user-defined function(s) (in files mm_augc_util.c and user_ac.c respectively). These supplemental constraints (equations) are used to define relationships between unknowns, boundary condition data, material properties, and virtually any other extracted quantity from Goma post processing routines. Examples include:
- Goma unknowns:
Specify a relationship between two or more unknowns, e.g. the distance between two nodes remains fixed at a specified value.
- Material properties:
Solve for a material property value such that another condition is met, e.g., find the liquid viscosity at which the velocity gradient at a wall becomes zero, or to maintain a relationship between the temperature, pressure, and density.
- Boundary condition floats:
Constrain the problem so that a specified relationship always exists between boundary condition data floats (which may not necessarily be Dirichlet conditions), i.e., the parameters of a boundary condition specification, or between parameters of different boundary conditions.
- Postprocessing constraints:
Postprocessing of solutions can define auxiliary variables that allow feedback of integrated results into the solution as constraints. Examples include integral constraints on surface forces, heat flux through a wall, volume flux and species flux.
- Other constraints:
Examples include constraints on volume, mass and component mass.
- Mixed constraints:
Augmenting conditions can invoke any combination of the above types in a single auxiliary constraint. Thus, a relationship can be specified between any of the Goma unknowns, material properties, boundary condition floats, and postprocessed variables.
The Goma augmenting condition capability handles all of the above types. Providing the variable of interest is passed to the augmenting condition user-definition routine (described below) via a data structure or argument, the augmenting condition can be applied. The number of augmenting conditions is unlimited but must be set by the user. An important consideration in the addition of augmenting conditions however is increased computational cost (time and storage) as the number of augmenting conditions increases. There are no limits on the density (number of non-zeroes) of the augmenting condition residual equation or the level of interaction between the unknowns.
Two pieces of information must be specified to add an augmenting condition to a Goma analysis: identification of the AC and its parameters (Section 2.3) and the addition of new unknowns to the Goma system of equations (Section 2.4). This latter step consists of creating a function which specifies the relationship between the variables of interest. The extra unknowns must be equal in number to the augmenting conditions and be one of four types: boundary condition data floats, material properties, volume constraints or flux constraints. Volume and flux augmenting condition standardized relationships have already been defined in function std_aug_cond (file mm_augc_util.c); the user must specify the functional relationship for boundary conditions and material properties in the user_aug_cond_residuals function (file user_ac.c).
Augmented System Solution#
Adding extra equations to the original Goma system of equations yields an augmented set of equations. In Goma, the augmented system of equations is solved by a bordering algorithm (Chan and Resasco, 1986). This method is essentially a block elimination of the augmented equations.
The original Goma system has the advantage that it is sparse, usually with small bandwidth. This leads to computational benefits (speed and storage) that can be realized when using direct frontal and iterative solvers. The bordered algorithm is suitable for the augmented system of equations because the decomposition of the original Goma set of equations is already required; one additional, but much smaller, decomposition for the augmented equations adds little calculational cost compared to the original system decomposition. If there are N augmenting conditions, the bordered algorithm solves the augmented system of equations with one decomposition and N+1 back-substitutions of the Goma original system, plus one NxN system solution. One further advantage of the bordered algorithm is that the augmenting equations can have much wider bandwidth than the original system without substantial growth in the computer time and memory for decomposition.
In the case where the original system is singular but the augmented system is not, the bordered algorithm will fail to solve the system. An instance in which this occurs is the tracking of a turning point in a parameter. Here, the original Goma set of equations is singular while the augmented system is not.
Required Specifications in the Goma Input File#
A new section must be added to the Goma input file to identify the new unknowns and other needed data. This section is required only when augmenting conditions are present in the numerical model and has the following form:
-------------------------------------
Augmenting Condition Specifications
-------------------------------------
Number of augmenting conditions = -1
AC = BC 29 1
AC = MT 4 1300
END OF AC
Augmenting Condition Specifications#
The following cards are used to specify augmenting conditions in Goma.
Augmenting Conditions Initial Guess#
Augmenting Conditions Initial Guess = {read | other}
Description / Usage#
This card is used to direct the specification of the initial guess for values of the augmenting condition parameters.
- read
Initial guesses are read from the ASCII file identified on the GUESS file card.
- other
Any other string that is not read, or if this card is missing altogether, the initial guesses for the augmenting condition values will be obtained from the input deck itself or the material file.
Note that the computed values of the augmenting conditions are automatically written at the end of the SOLN file, so it is usually necessary when employing this option to copy the SOLN file to the GUESS file before restarting.
Examples#
In the following example, the initial guesses for the augmenting condition values will be obtained from the input deck itself or the material file.
Augmenting Conditions Initial Guess = none
Number of Augmenting Conditions#
Number of augmenting conditions = <integer>
Description / Usage#
This card allows the user to specify the number of augmenting condition cards to be read. This card must be present in order to run a problem employing augmenting conditions.
- <integer>
N, an integer parameter that is either the number of AC cards to be read or -1.
Goma will try to read N cards that start with: AC = between this card and a line having only the string END OF AC. If Goma finds fewer than N cards before encountering this string, it will stop with an error. More than N cards is fine; the excess are ignored. If N is -1, Goma will read all the augmenting condition cards between this card and the END OF AC card.
Examples#
In the following example, the initial guesses for the augmenting condition values will be obtained from the input deck itself or the material file.
Number of augmenting conditions = -1
AC = FC 1 0 0 VOLUME_FLUX 4 {-PI}
AC = FC 1 1 0 FORCE_TANGENT1 3 {3*5.0}
END OF AC
In this example, Goma will read and execute two different augmenting conditions.
Technical Discussion#
When doing arc length continuation with augmenting conditions, one additional AC record will be automatically created so the number of reported augmenting conditions will be incremented to N+1. In this case, N is still the number of AC cards to be read, which would not include this additional AC (for which there is no input card).
AC (Boundary Condition)#
AC = BC <bc_id> <integer> <float_list>
Description / Usage#
This type of augmenting condition allows the user to connect an additional constraint equation (user-supplied) to a specific boundary condition float parameter which is allowed to vary as an additional degree of freedom during the solution process. The constraint equation is added to the function user_aug_cond_residuals in the file user_ac.c. A discussion of this function specification and examples is supplied in later sections of this manual.
A description of the card syntax follows:
- BC
A mandatory string indicating that the augmenting condition is attached to a boundary condition parameter.
- <bc_id>
An integer parameter identifying the boundary condition index whose parameter is going to be used as the additional unknown. The first index is zero, starting from the first read boundary condition in the input file, and proceeding sequentially upwards. The Technical Discussion describes a method for automatically determining <bc_id>.
- <integer>
A parameter identifying the index of the float parameter that is to be varied on the boundary condition specification identified by <bc_id>. The leftmost float value is assigned index zero and the index increases sequentially left to right.
- <float_list>
A list of float parameters that can be used in user_aug_cond_residuals to evaluate the augmenting conditions. They are stored in sequence in the array augc[i].DataFlt.
Examples#
For the following set of boundary condition cards:
Number of BC = -1
BC = U NS 10 0.0
BC = V NS 10 0.0
BC = W NS 10 0.0 1.0
an example augmenting condition card of type BC is:
AC = BC 2 0 1.0 0.25
The augmenting condition card attaches the (unspecified, in this example) constraint to the first float parameter on the BC = W NS 10 card. Note that there are two float parameters on this card - the first is the specified z-velocity component on node set 10 and the second parameter is required when a Dirichlet condition is attached to an augmenting equation. Ordinarily, Dirichlet conditions are applied by direct substitution, but when the second parameter is present, the condition is included as a residual equation along with all the other residual equations. Naturally, it is this latter form that should be used when an augmenting condition is attached to the boundary condition. The two float parameters supplied on the card can be used in user_aug_cond_residuals as the variables augc[0].DataFlt[0] = 1.0, augc[0].DataFlt[1] = 0.25.
Technical Discussion#
The function user_aug_cond_residuals is passed an integer index iAC. This is the index of each AC card in order of its appearance in the input deck (with the zero being assigned to the first AC card that appears). The arbitrary float parameters supplied on the card in <float_list> can be accessed in this function in the array augc[iAC].DataFlt. The variable DataFlt[0] corresponds to the first float parameter in <float_list> and so on.
Often the augmenting condition constraint written in function user_aug_cond_residuals must make use of the values of nodal unknowns. These can be determined using the function Index_Solution as follows:
The boundary condition index of any boundary condition can be found with the following feature. The NS or SS designator string on the boundary condition in question should be changed (temporarily) to NC or SC, respectively. Then Goma should be run with the arguments as follows:
goma -i input_file -a -bc_list
This invokes a code fork that does not run the problem but analyses the input deck and prints out the index of the boundary conditions flagged by the previous procedure. The values of these indices can be used directly in the augmenting condition cards for <bc_id>
The augmenting condition constraints are additional residual equations solved simultaneously with the other residual equations associated with the nodal degrees of freedom. The unknown degrees of freedom associated with these equations are the boundary condition float values identified on each augmenting condition card. The new equations also introduce a different structure to the matrix being solved. The formerly sparse, banded Jacobian matrix has now been augmented by rows and columns on its periphery that are potentially populated. This requires a bordered matrix algorithm for the solution of this type of matrix. A consequence of this algorithm is that the residual and update norms of the augmenting conditions are computed separately. The user will see these norms appear as a second row of output at each and every iteration. If these are missing, the augmented system is not being solved.
Note that the value of the augmenting condition parameter values can be displayed after each iteration by setting Debug = 1 in the input deck.
AC (Material property)#
AC = MT <mat_id> <material_prop_tag> <float_data_list>
Description / Usage#
This augmenting condition type attaches a material property (viscosity, thermal conductivity, surface tension, etc.) to an augmenting constraint. The value of the material property value is permitted to vary as any other degree of freedom in order that the user-supplied augmenting condition is satisfied.
Definitions of the input parameters are as follows:
- MT
A string designator identifying the AC card as a material property type.
- <mat_id>
An integer parameter identifying the material whose property is being varied.
- <material_prop_tag>
An integer parameter that associates an integer tag with a type of material property. The material property value designated by this tag will be varied in the solution process. The following tables show the association between material property and integer tag.
- <float_data_list>
A list of float parameters that can be used in user_aug_cond_residuals to evaluate the augmenting conditions. They are stored in sequence in the array augc[i].DataFlt.
General Physical Properties
Property |
TAG |
---|---|
THERMAL_CONDUCTIVITY |
1100 |
ELECTRICAL_CONDUCTIVITY |
1200 |
VISCOSITY |
1300 |
SURFACE_TENSION |
1400 |
HEAT_CAPACITY |
1500 |
VOLUME_EXPANSION |
1600 |
DENSITY |
1700 |
POROSITY |
1800 |
PERMEABILITY |
1900 |
REL_GAS_PERM |
2000 |
REL_LIQ_PERM |
2100 |
SATURATION |
2200 |
MELTING_POINT_LIQUIDUS |
2500 |
MELTING_POINT_SOLIDUS |
2600 |
FLOWINGLIQUID_VISCOSITY |
2700 |
Generalized Newtonian Models
Property |
TAG |
---|---|
MU0 |
4000 |
NEXP |
4100 |
MUINF |
4200 |
LAM |
4300 |
AEXP |
4400 |
ATEXP |
4500 |
WLFC2 |
4550 |
TAU_Y |
4600 |
FEXP |
4610 |
MAXPACK |
4800 |
FICKDIFF_X |
4810 |
FICKDIFF_Y |
4820 |
Viscoelastic Models
Property |
TAG |
---|---|
TIME_CONST |
5000a |
WT_FUNC |
5100a |
ALPHA |
5200a |
PTT_XI |
5300a |
PTT_EPS |
5400a |
a This is the TAG_ID for the first viscoelastic mode; subsequent mode TAG_IDs are incremented by 1, e.g., TAGC_TIME_CONST(mode i) = TAGC_TIME_CONST + i
Solid Elastic Models
Property |
TAG |
---|---|
LAME_MU |
6000 |
LAME_MU_CONTACT_LINE_G0 |
6001 |
LAME_MU_CONTACT_LINE_G1 |
6002 |
LAME_MU_CONTACT_LINE_R0 |
6003 |
LAME_LAMBDA |
6100 |
CONV_LAG_VELX |
6201 |
CONV_LAG_VELY |
6202 |
CONV_LAG_VELZ |
6203 |
CONV_LAG_ROTRATE |
6221 |
CONV_LAG_ROT_X0 |
6222 |
CONV_LAG_ROT_Y0 |
6223 |
CONV_LAG_ROT_Z0 |
6224 |
RS_LAME_MU |
6300 |
RS_LAME_LAMBDA |
6400 |
POISSON |
6600 |
STRSS_FR_SOL_VOL_FRAC |
6610 |
This is only a partial list of the available material property tags. To find the latest tag definitions (those active in your version of Goma), look in the Goma header file mm_mp_const.h. The initial value of the extra unknowns is taken from those values given in the input, material definition, and geometry definition (if any) files.
Examples#
The following is an example this AC card:
AC = MT 1 1400
This card indicates that this augmenting condition constraint is associated with the surface tension value found in the material file designated for material 1.
Note that the value of surface tension originally supplied in the material final will be used as a starting guess. However, at the end of the computation a different value for surface tension will have been determined and save in the memory location for this material property. If an ASCII output file is requested (SOLN file = ), the value of the surface tension will appear at the end of the file following the output of the nodal unknown vector.
Technical Discussion#
See the technical discussion appearing in the documentation for the AC(Boundary Condition) card.
Theory#
No Theory.
FAQs#
No FAQs.
References#
Gates, I.D., D.A. Labreche, and M.M. Hopkins, “Advanced Capabilities in GOMA 3.0 - Augmenting Conditions, Automatic Continuation, and Linear Stability Analysis,” SAND2000-2465, Albuquerque, NM, (2001).
AC (Flux Condition)#
AC = FC <mat_id> <bc_id> <data_float_index> <FC_type> [species_id] <sideset> <flux_value>
Description / Usage#
This card attaches a boundary condition float parameter to an integrated flux constraint on a boundary sideset. The flux constraint consists of requiring a specific value for some integrated quantity over the sideset, for example, force, heat flux or fluid flowrate. A number of standard flux constraints have been provided so that a user- defined flux is not necessary. During the solution process the boundary condition parameter is allowed to vary as the additional degree of freedom associated with the flux constraint.
Definitions of the input parameters are as follows:
- FC
Mandatory string indicating that this augmenting condition is of variety Flux Condition.
- <mat_id>
An integer parameter identifying the identification number of the material on which the flux integration will be performed. Material properties needed in evaluating the flux constraint will be obtained from this material and only those elements belonging to this material will contribute to the flux integral
- <bc_id>
An integer parameter giving the index of the boundary condition card whose parameter is being used as the new degree of freedom. Numbering begins with zero, starting with the first boundary condition in the input file and proceeding sequentially upward with each read boundary condition card.
- <data_float_index>
An integer parameter that identifies the boundary condition parameter that will be varied. It is an index that starts at zero with the leftmost float value on the <bc_id> boundary condition card and increments upward from right to left.
- <FC_type>
A string parameter specifying one of the standard flux constraint equations. Choices are (all in capitals):
FORCE_X
FORCE_Y
FORCE_Z
FORCE_NORMAL
FORCE_TANGENT1
FORCE_TANGENT2
HEAT_FLUX
VOLUME_FLUX
SPECIES_FLUX
CHARGED_SPECIES_FLUX
CURRENT
PORE_LIQ_FLUX
TORQUE
AVERAGE_CONC
SURF_DISSIP
AREA
VOL_REVOLUTION
CURRENT_FICKIAN
NEG_LS_FLUX
POS_LS_FLUX
N_DOT_X
ELEC_FORCE_NORMAL
ELEC_FORCE_TANGENT1
ELEC_FORCE_TANGENT2
ELEC_FORCE_X
ELEC_FORCE_Y
ELEC_FORCE_Z
NET_SURF_CHARGE
DELTA
ACOUSTIC_FLUX_NORMAL
ACOUSTIC_FLUX_TANGENT1
ACOUSTIC_FLUX_TANGENT2
ACOUSTIC_FLUX_X
ACOUSTIC_FLUX_Y
ACOUSTIC_FLUX_Z
ACOUSTIC_INTENSITY
LS_DCA
See below for a detailed description of each of these constraints.
- [species_id]
This is an integer parameter that identifies the species component that is evaluated in the SPECIES_FLUX constraint. When other flux constraints are used this parameter should not appear.
- <side set>
An integer parameter that identifies the side set over which the flux condition will be integrated. Those elements that belong to <mat_id> and have faces included in <side set> will be evaluated in the integration.
- <flux_value>
A float parameter that specifies the value that is assigned to the flux integral. At the end of the solution procedure, the flux integral will be equal to this float value.
Examples#
The following are two examples of this AC type:
Number of augmenting conditions = -1
AC = FC 1 0 0 VOLUME_FLUX 4 {-PI}
AC = FC 1 1 0 FORCE_TANGENT1 3 {3*5.0}
END OF AC
Technical Discussion#
The following list describes precisely some of the preceding FC_type constraint equations. In the following, \(\Phi\) is the <flux_value> parameter and \(\Gamma\) is the side set specified above.
For material blocks with ARBITRARY mesh motion:
FORCE_X:
FORCE_Y:
FORCE_Z:
FORCE_NORMAL:
FORCE_TANGENT1:
FORCE_TANGENT2:
HEAT_FLUX:
VOLUME_FLUX:
SPECIES_FLUX:
where:
\(\boldsymbol{\Pi}\) = fluid stress tensor
\(\rho\) = fluid phase density
\(\mathbf{u}\) = fluid velocity vector
\(\mathbf{u}_m\) = mesh velocity vector
\(\mathbf{e}_x\), \(\mathbf{e}_y\), \(\mathbf{e}_z\) = cartesian unit bases
\(\mathbf{n}\) = normal vector to side set
\(\mathbf{t}_1\) = first tangent vector to side set
\(\mathbf{t}_2\) = second tangent vector side set (3D only)
\(\mathbf{q}\) = diffusive heat flux
\(C\) = heat capacity per unit mass
\(\mathbf{j}_i\) = diffusive flux of species i
\(c_i\) = concentration of species i.
In the case of a LAGRANGIAN material, only the FORCE flux constraints are relevant. They have the same form as the preceding except that there are no convective contributions to the flux and Π represents the solid stress tensor.
For additional technical notes regarding this augmenting condition type see the AC (Boundary Condition) section.
AC (Volume Constraint)#
AC = VC <mat_id> <vc_type> <bc_id> <data_float_index> <species_id> <volume_value>
Description / Usage#
This augmenting condition card allows the user to specify a boundary condition parameter as an unknown parameter in order to satisfy an integrated volumetric constraint. Three types of constraint are allowed: mesh volume, mass in mesh, and mass of species in mesh. All three integrated constraints are computed automatically and so no user-defined function is needed. See below for a mathematical description of each type of integrated constraint.
This card attaches a boundary condition parameter to these integrated constraints as an additional unknown degree of freedom. This parameter is specified in exactly the same way as detailed in the AC (Boundary Condition) section.
Definitions of the input parameters are as follows:
- VC
Mandatory string identifying the augmenting condition card as being of type Volume Constraint.
- <mat_id>
An integer parameter giving the material identification number (element block id in the mesh) over which the integrated volume constraint is to be applied. That is to say, if more than one material occupies a problem domain, a volume constraint can only be applied to the space occupied by one of the materials for any given augmenting condition.
- <vc_type>
An integer parameter that sets the type of volume constraint as follows:
vc_type = 1 (mesh volume):
\[V_T = \int_V dV\]vc_type = 2 (mass in mesh):
\[V_T = \int_V \rho dV\]where ρ is the fluid density.
vc_type = 3 (mass of species in mesh):
\[V_T = \int_V \rho y_i dV\]where \(y_i\) is the mass fraction of the ith species.
- <bc_id>
An integer parameter giving the index of the boundary condition card whose parameter is being used as the new degree of freedom. Numbering begins with zero, starting with the first boundary condition in the input file and proceeding sequentially upward with each read boundary condition card.
- <data_float_index>
An integer parameter that identifies the boundary condition parameter that will be varied. It is an index that starts at zero with leftmost float value on the <bc_id> boundary condition card and increments upward from right to left.
- <species_id>
An integer parameter that identifies the species number to be used when evaluating a vc_type = 3 constraint equation. For other types of constraints, it is still necessary for the syntax, but is unused. Good procedure sets it to zero.
- <volume_value>
A float parameter that fixes the value of VT used in the expressions above. That is, it fixes the value that the integrated quantity will have at the end of the computation.
Examples#
The following is an AC (Volume Constraint) card with its accompanying boundary condition card.
AC = VC 1 1 2 1 0 3.14156
which has the following set of boundary conditions
Number of BC = -1
BC = U NS 1 0.0
BC = V NS 1 1.0
BC = CAPILLARY SS 10 1.0 10.0 0.0
...
This augmenting condition then applies to material 1 and will fix the mesh volume of this material to 3.14156. To do this it will vary the external pressure applied via the CAPILLARY card (the second float parameter). Note that the value given for this pressure in the input deck serves as a starting guess. At the end of the calculation, a new value for pressure will be in the memory location assigned to this float parameter. If an ASCII solution file is requested (via SOLN file =), the parameter value will be written following the output of the nodal unknown vector.
Technical Discussion#
See the technical discussion appearing in the documentation for the AC (Boundary Condition) card.
References#
SAND2000-2465: Gates, I.D., Labreche, D. A., Hopkins, M. M. and Wilkes, E. D., 2001. “Advanced Capabilities in GOMA 3.0 - Augmenting Conditions, Automatic Continuation, and Linear Stability Analysis,” Sandia Technical Report.
AC (Overlapping Grid Boundary Conditions)#
AC = OV <SSID> <integer1> <integer2><integer3>
Description / Usage#
This type of augmenting condition is used to invoke the overlapping grid algorithm for fluid-structure interaction problems, which applies a kinematic constraint along either the moving part of the solid boundary or the zero contour of a phase function field within the fluid which follows this boundary, and enables sensitivities from both phases to be included. When this card is provided in conjunction with an appropriate set of interfacial boundary conditions (see below), this AC is replaced with m new augmenting constraints – two per element side along the side set specified by <SSID>.
This algorithm works with either of the following two sets of interfacial boundary conditions:
LS_NO_SLIP, SOLID_FLUID_CONTACT, FLUID_SOLID_CONTACT
or
LAGRANGE_NO_SLIP, OVERSET(BAAIJENS)_SOLID_FLUID, OVERSET(BAAIJENS)_FLUID_SOLID
The primary difference between these two sets is that the former imposes the kinematic condition from the fluid side and the latter from the solid side. The same physical equations are applied in either case.
A description of the card syntax follows:
- OV
A mandatory string indicating that the augmenting condition is being used to invoke the overlapping grid algorithm.
- <SSID>
The SS index of the moving solid boundary, taken directly from the ExodusII input file.
- <integer1>
The element block index for the solid phase, taken directly from the ExodusII input file.
- <integer2>
The element block index for the fluid phase, taken directly from the ExodusII input file.
- <integer3>
Location of the Lagrange multiplier unknowns. For now, this entry must be zero, which indicates that the unknowns are stored in the augmenting conditions.
Examples#
For a case where a fluid is in element block 1 and the solid is in element block 2 with sideset 10 defined along the moving boundary, the appropriate augmenting condition card of type OV is:
AC = OV 10 2 1 0
Note that the first three integers come directly from the input mesh file and thus do not depend on which of the above boundary condition sets is chosen. It is only necessary that those BC’s which are applied from the solid side have the same side set ID specified.
Technical Discussion#
If it is necessary to specify any other type of augmenting condition in the same problem, this card must be the last one in the list.
When this card is present, a check will be done for the presence of any of the above interfacial boundary conditions. An error will occur if none are specified.
There is a routine which counts the number of element sides in side set <SSID> and allocate the necessary number of augmenting constraints to be used in the program (This changes nAC). Goma must be compiled with a sufficient value for the constant MAX_NGV, which must be at least nAC+5. The default value of this constant is set to 10 in the file rf_io_const.h; this value can either be changed there or overridden by specifying “-DMAX_NGV=<#>” in the DEFINES section of the makefile.
References#
Baaijens, F. P. T. “A fictitious domain/mortar element method for fluid-structure interaction,” Int. J. Numer. Meth. Fluids. 35, 2001, 743-761.
AC (Phase Velocity of Level Set)#
AC = LSV <integer_list> <VX|VY|VZ> <float1>
Description / Usage#
This type of augmenting condition is used to connect a boundary condition to an augmenting constraint on the average velocity of one of the phases of the level set field. This is useful for performing a simulation in the reference frame of a moving material when the velocity is not known a priori, such as a bubble rising through a quiescent fluid.
The <integer_list> has four parameters; definitions of the input parameters are as follows:
- LSV | LS_VELOCITY
A mandatory string indicating the name of the augmenting condition card.
- <integer1>
An integer parameter giving the material identification number over which the phase volume constraint is applied. That is to say, if more than one material is present, the phase velocity constraint can only be applied to the space occupied by the level set phase in one material.
- <integer2>
An integer parameter giving the index of the boundary condition card whose parameter is being used as the new degree of freedom. Numbering begins with zero, starting with the first boundary condition in the input file. For this augmenting condition, this is generally a velocity boundary condition.
- <integer3>
An integer parameter that identifies the floating point parameter of the boundary condition that will be varied. It is an index that starts at zero with the left-most float value on the <int2> boundary condition cast and increments upward from left to right.
- <integer4>
An integer parameter which specifies the level set phase whose velocity will be constrained by this augmenting condition.
> 0: The constraint will be placed on the phase where the level set function has positive values.
< 0: The constraint will be placed on the phase where the level set function has negative phase.
- <VX|VY|VZ>
This string parameter specifies which component of the velocity will be constrained by the augmenting condition.
VX: The x component of the phase velocity will be constrained.
VY: The y component of the phase velocity will be constrained.
VZ: The z component of the phase velocity will be constrained.
- <float1>
A float parameter that fixes the volume averaged velocity of the level set phase specified by <int4>.
Examples#
The following is an example of using this augmenting condition to perform a calculation in the moving reference frame of the negative level set phase where the reference frame velocity is not known a priori:
AC = LSV 1 0 0 -1 VX 0.0
Applied to boundary condition:
BC = U NS 4 0.0 1.0
The x component of the velocity of the negative level set phase of material #1 is set to zero and the first floating point parameter of the first velocity boundary condition is used as the new degree of freedom. Note that the Dirichlet boundary condition has the additional float parameter 1.0 so that the boundary condition equation is retained as a residual equation. The initial guess for the boundary velocity in this case is 0.
Technical Discussion#
The velocity of the specified phase of the level set field is calculated using a volume average over the domain where the level set fill function has positive or negative values as specified. The boundary between the two phases is defined as the zero contour line of that fill function. The ‘thickness’ of the region around the embedded interface where material properties transition between the properties of the two pure phases is specified by the “Level Set Length Scale” card in the input deck. Within the diffuse interface region, the contribution to the averaged velocity integral is weighted by a smoothed Dirac delta function. Additional information about the embedded interface and the form of the delta function are available in the technical discussion section of the “Level Set Length Scale” card.
See the technical discussion section of the AC (Boundary Condition) card for additional information regarding augmenting conditions.
AC (Periodic Boundary Condition)#
AC = PBC <var_name> <sideset_id1> <sideset_id2>
Description / Usage#
This augmenting condition card allows the user to specify that a field variable has the same value at both ends of a given domain. The ends are specified as side sets, which must have the same number of nodes with the same spacing between them.
Definitions of the input parameters are as follows:
- PBC
Mandatory string identifying the augmenting condition card as being of type Periodic Boundary Condition.
- <var_name>
A string indicating the variable whose value will be matched at the specified periodic boundaries of the problem domain. This variable must be active throughout the region bordered by these two boundaries.
- <sideset_id1>
An integer parameter that identifies the sideset at one of the two periodic boundaries for the specified variable. This sideset must be coextensive with this domain boundary.
- <sideset_id2>
An integer parameter that identifies the sideset at the other periodic boundary for the specified variable. This sideset must be coextensive with this domain boundary.
Examples#
The following is an AC (Periodic Boundary Condition) card which specifies periodic boundaries for voltage at sidesets 20 and 30:
AC = PBC VOLTAGE 20 30
Technical Discussion#
When this augmenting condition is invoked, the degrees of freedom (DOF’s) of the specified variable at corresponding points on the two periodic boundaries are matched. During equation assembly, a Lagrange multiplier constraint is applied to each pair of DOF’s to enforce the constraint, which in residual form is:
where \(x_1\) and \(x_2\) are the unknown values at corresponding points along the two specified periodic boundaries, and λ is the added unknown associated with this constraint. This residual and all relevant sensitivities to problem unknowns are assembled into the appropriate augmenting condition arrays and solved along with any other active augmenting conditions via the internal bordering algorithm within Goma’s nonlinear solver.
References#
SAND2000-2465: Gates, I.D., Labreche, D. A., Hopkins, M. M. and Wilkes, E. D., 2001. “Advanced Capabilities in GOMA 3.0 - Augmenting Conditions, Automatic Continuation, and Linear Stability Analysis,” Sandia Technical Report.
END OF AC#
END OF AC
Description / Usage#
This card is the companion card to the Number of augmenting conditions card. The END OF AC card signals the end of the Augmenting Conditions Specifications section of the Goma input. When the Number of augmenting conditions (= -1) is set to negative one, Goma will read all the augmenting condition cards until this card is encountered in the input file. This card may omitted if the integer N on the Number of augmenting conditions card is not -1.
Examples#
Typical usage of this card is illustrated below:
Number of augmenting conditions = -1
.
.
.
END OF AC
Technical Discussion#
See companion card Number of augmenting conditions.