General Specifications

This section of input records covers additional I/O requests and specifications, including parallel file I/O information, initial-guess directives (viz., whether a restart comes from a neutral file or another exoII file), individual field variable initialization, debugging options, developer diagnostic options, etc. This section and several of its input records are required, as indicated below.

Output Level

Output Level = <integer>

Description / Usage

This optional card specifies the level of diagnostic information output to the file stderr. The permissible values for <integer> are 0 through 4, depending on the level of informational (debugging) output desired; higher values of the output level will produce more diagnostic information on the stdout and stderr output channels. The default output level is 0. Specific output is summarized below.

Level	Results Output
0	No diagnostic output (default).
1	Identifies the degree of freedom, the solution variable, and node at which the maximum value of norm is present.
2,3,4	Currently unused; available for developer output specification.

Examples

Following is a sample card:

Output Level = 1

Technical Discussion

This specification allows the developer a means to output specific information that would be helpful in diagnosing problems in the software. Currently, the output options are limited.

---

Debug

Debug = <integer>

Description / Usage

This optional card specifies the level of information output to files stdout and stderr. The permissible values for <integer> are -3 through 4, depending on the level of informational (debugging) output desired; higher values of the output level will produce more diagnostic information output on the stdout and stderr output channels. The default level is 0. Specific results produced for each level are summarized below. The user should exercise caution in using values other than the default for problems with large numbers of unknowns as the volume of information increases very quickly.

Level	Results Output
0	No output (default).
1	Logs activity as the code does problem setup, including setting addresses and sizes, boundary-condition (BC) conflictresolution information, and identification of the rotation conditions at every node with a boundary flag. Prints out surface boundary integral setup information. Lists matrix and solver information for each solution step.
2	Prints same information as level 1, plus provides a summary of BC type information for each BC and logs the beginning and end of matrix fill operations.
3	Prints same information as level 2, but also prints a list of variables/unknowns at each node.
4	Prints same information as for level 3.
-1	Logs activity as the code does problem setup and prints out surface boundary integral setup information as is done for mode 1. Triggers a comparison of the analytical Jacobian and the numerical Jacobian in un-scaled form, which can be used to check the compatibility of the analytical residual equations and Jacobian. Prints results only if the analytical and numerical Jacobian are different. Does not solve any equations; terminates after Jacobian print out.
-2	Same initial information as for level -1. Triggers a comparison of the analytical Jacobian and the numerical Jacobian scaled by the sum of each row of the analytical Jacobian (this helps suppress small errors in large Jacobian entries). Prints results only if the analytical and numerical Jacobian are different.
-3	Similar to level -2 except each row is scaled by the diagonal value which is usually the largest. Prints results only if the analytical and numerical Jacobian are different.

Examples

Following is a sample card:

Debug = -2

Technical Discussion

For options -1, -2, -3, viz. numerical Jacobian checking, the user must take care when interpreting the cited differences in the numerical and analytical Jacobian. The comparison is made by perturbing each variable and comparing the numerical Jacobian computed between the perturbed and unperturbed states to the analytical Jacobians at the two states. A difference is deemed significant if the numerical Jacobian falls outside the band between the two analytical values with an additional allowance for roundoff error. It is the roundoff error in the residual that is the most difficult for the Jacobian checker to estimate. This is particularly true for problems with zero initial conditions since it is impossible to determine the scale of a velocity, for example, if all the values of velocity are zero. For this reason, it is often better to use a nonzero initial condition or a scaled problem (with values order unity) when using the Jacobian checker.

Currently, there are two parameters output by the Jacobian checker that can help the user decide on the significance of the entry. The first is the relative change in the analytical residual. This quantity, labeled d_aj, is the percentage of the acceptance band that comes from changes in the analytical Jacobian from the unperturbed to perturbed states. For a non-linear dependency, the difference between the analytical Jacobians will be significant and it is reasonable to expect that the numerical Jacobian should fall within the band. If the analytical Jacobian is nearly constant over the perturbation, the accuracy of the check becomes increasingly dependent on knowing the roundoff error in the residual. So, as d_aj gets closer to unity, the user can have more confidence that the entry is significant.

The second parameter is a confidence measure that is the deviation between the numerical jacobian and analytical values divided by the expected value of the deviation based on roundoff error. Since the roundoff error is only known approximately, this value, called conf, is only a qualitative measure of the confidence. A conf value of 100 means that the deviation between the numerical jacobian and the analytical values is 100 times larger than the expected deviation based on roundoff error.

Here is a sample of output from a convective heat transfer problem, using the -2 option

Eqdof=92 T_0 n=31 Vardof=95 T_0 n=32 x=0
dx=0.0001 aj=-0.008188 nj=-0.008126 aj_1=-0.008188 d_aj=0
conf=1.889e+06

  >>> QCONV on SSID=1

This entry can be read as follows: The sensitivity of global equation number 92, which happens to be the T_0 energy equation at node 31, with respect to the temperature variable at node 32 (variable global degree of freedom number 95) has an analytical Jacobian of -0.008188 at the unperturbed state and a computed numerical Jacobian of 0.008126. The analytical jacobian at the perturbed state is -0.008188. For this problem the change in the analytical Jacobian is zero between the unperturbed and perturbed states, so d_aj is zero. But even though the difference is small between the analytical and numerical values, it is huge relative to the expected roundoff error, with the deviation being 1.889e+6 times the deviation attributable to roundoff error.

For each node where a deviation is found, the side boundary conditions applied at the node are printed, as shown above. If one of these boundary conditions are applied to the equation that shows an error and have the same dependency that is showing the error, this boundary condition is flagged as shown for the QCONV boundary condition above.

Before the user/developer concludes that there is a discrepancy in the analytical Jacobian, a few things should be tried:

• Giving the problem a nonzero initial guess, either by reading in a STEADY state solution, if one exists, or on transient problems using the “one” option on the Initial Guess card. Sometimes this will make many differences disappear.

• Checking whether the nodes cited in the difference outputs are boundary nodes. Specifically, if they are boundary nodes on which Dirichlet boundary conditions are specified, artificial errors can occur.

• Also, if you are in doubt that there are not reported errors, put one in by a 10 percent perturbation to the residual. The Jacobian checker should hit on those errors and report them to you.

• Check the settings in mm_numjac.h.

---

Number of Jacobian File Dumps

Number of Jacobian File Dumps = <integer>

Description / Usage

This routine will dump a serial machine independent binary file out to disk containing the Jacobian. The file is meant to be used by the auxiliary program, checkGomaJac, to compare two versions of the Jacobian. Ancillary data meant to enhance the printouts in checkGomaJac are also output to the file. The card takes one mandatory integer variable.

<integer>

If the integer is a positive number, n, then Goma will dump the first n Jacobians created (for any reason) to the current directory. If the integer is a negative value, -n, then Goma will dump a single Jacobian, the n’th Jacobian created, to the current directory.

The dumped files are named matrix.000, matrix.001, etc. Overwrites of files are allowed to occur. The files themselves are written out using the XDR protocol layer (easy, quick, and machine portable). The VBR format is used to write files out, even if the internal format used by Goma is MSR. Thus, VBR and MSR formatted Jacobians may be compared. Frontal Solver Jacobians are not compatible. The algorithm used is also compatible with parallel jobs using Goma. In other words, the Jacobian file dumped out for an 8 processor Goma run should be identical to the file dumped out by a single processor run.

In order to use this feature, it is necessary to compile Goma with the MATRIX_DUMP flag defined.

To compare two Jacobian files previously dumped out for compatibility, run checkGomaJac offline:

checkGomaJac   matrix1   matrix2

checkGomaJac will compare each entry in the row and column scaled matrices and print out in an annotated format the entries containing the largest differences.

Examples

Number of Jacobian File Dumps = 2

Technical Discussion

This capability has proven itself to be very useful in tracking changes to the Jacobian due to differences in the machine architecture, number of processes, and due to changes in the source code over time. The comparison is done using the standard RTOL, ATOL logic found in ODE solvers. In other words, a weighting vector of the form,

EQUATION

is created for each Jacobian entry, J_i. Then, a determination of the difference between J_{i`and J:sub:`i} by the following formula:

EQUATION

w_i is also used in the Jacobian column scalings, before the standard row sum scaling is applied.

Internal Sandia users can find the auxiliary program, checkGomaJac, in the directory / home/goma/arch/linux/bin on the Linux compute server, and in other ‘arch’ subdirectories for other platforms. External users should contact Goma support staff to obtain the tool.

---

Initial Guess

Initial Guess = {char_string} [filename]

Description / Usage

This optional card directs the initialization of the entire unknown vector. Three options are provided to set the entire solution field to numerical values determined by {char_string}. Three additional options are available for reading initial values of the solution vector from data files. The permissible values of {char_string} are:

zero

For an initial guess of zero (0.) for each degree of freedom in the unknown vector.

one

For an initial guess of one (1.) for each degree of freedom in the unknown vector.

random

For a random initial guess (between 0. and 1.) for each degree of freedom in the unknown vector.

read

To obtain the initial guess by reading the ASCII data file identified as the GUESS file, which must have initially been a SOLN file or a tmp_i.d (Write Intermediate Results) file.

read_exoII

To obtain the initial guess from the EXODUS II file specified by the FEM file card that is also used to supply mesh data. Any extraneous variables in the EXODUS II file that are not in the list of active variables for the current problem description are simply ignored.

read_exoII_file file name

To read the initial guess for the field variables from an EXODUS II database file different from the initial mesh database file. The file_name is specified as a single string following the read_exoII_file keyword. As with the read_exoII option, any extraneous variables not specified as active variables for the simulation will be simply ignored.

If this card is omitted, then the default behavior is to assume that a value of zero has been specified for {char_string}.

Examples

Following is a sample card:

Initial Guess = zero

Initial Guess = read_exoII_file      First_Iteration.exoII

Technical Discussion

This card provides the specification of the initial vector of unknowns in a problem. In most cases this vector is specified to be identically zero, though in some cases a nonzero vector may be of value (see Technical Discussion section of Debug card). The first three options (zero, one, random) employ an internally-generated vector of initial values, while the read option utilizes the values read from an ASCII solution file (see SOLN input card) previously calculated by Goma, and the read_exoII options employ solutions read from binary (exoII) files, not necessarily always generated by Goma.

---

Initialize

Initialize = {char_string} <integer> <float>       [units vary]

Description / Usage

This optional card provides a mechanism to set one of the field variables to a constant value across the whole domain. Definitions of the input parameters are as follows:

{char_string}

Permissible values for this input string are any variable names identified in source file rf_fem_const.h beginning at the section labeled Variable Names of unknowns. Examples include, but are not limited to, the following (note the shorthand notation for components):

VELOCITY1, VELOCITY2, VELOCITY3 (V123), MESH_DISPLACEMENT (MD123), SOLID_DISPLACEMENT (SD123), MASS_FRACTION, TEMPERATURE, PRESSURE, VOLTAGE, FILL, LS, POLYMER_STRESS (6 components, 8 modes), VELOCITY_GRADIENT (9 components), SHEAR_RATE, VOLF_PHASE (6 phases), POR_LIQ_PRES, POR_GAS_PRES, POR_POROSITY, POR_SATURATION, POR_LAST, LAGR_MULT (LM123), SURF_CHARGE, EXT_VELOCITY, EFIELD(123), SHELL (4 variables), SPECIES (7 variables).

For a more comprehensive list, see Technical discussion below.

<integer>

Species number to be initialized if the value of {char_string} is one of the SPECIES variables (see Technical Discussion); otherwise, set <integer> to zero.

<float>

Value to which the variable should be initialized.

Multiple applications of this card are valid; Goma automatically counts the number of Initialize cards.

Examples

Following is a sample card:

Initialize = VELOCITY1 0 0.

Technical Discussion

This card provides the means to globally set (i.e., the entire problem domain) initial values for any of the field variables. Since the setting of variables initialized on this card takes place after reading the initial guess (see function init_vec in file rf_util.c), it can be used to override the value in the Initial Guess file.

In order to set a field to a specific value in a particular material only, a similar Initialize capability is provided within each material block. Please check in the Material Files section of this manual.

Note, the SPECIES_UNK variables are NOT used to initialize any of the species variables. Rather, the special definition called MASS_FRACTION representing the various Species Types, is the variables used in Goma input or mat files for this input record. Multiple species are initialized by combining one of these variable types with the second parameter (<integer>) on this card.

The comprehensive list of keyword variable names can be found in mm_input_util.c, if you have access to GOMA source code. Search for the function variable_string_to_int. A snapshot of the initialize-able variables in that routine is shown here:

var = VELOCITY1;
var = VELOCITY2;
var = VELOCITY3;
var = TEMPERATURE;
var = MASS_FRACTION;
var = MESH_DISPLACEMENT1;
var = MESH_DISPLACEMENT2;
var = MESH_DISPLACEMENT3;
var = PRESSURE;
var = POLYMER_STRESS11;
var = POLYMER_STRESS12;
var = POLYMER_STRESS13;
var = POLYMER_STRESS22;
var = POLYMER_STRESS23;
var = POLYMER_STRESS33;
var = SOLID_DISPLACEMENT1;
var = SOLID_DISPLACEMENT2;
var = SOLID_DISPLACEMENT3;
var = VELOCITY_GRADIENT11;
var = VELOCITY_GRADIENT12;
var = VELOCITY_GRADIENT13;
var = VELOCITY_GRADIENT21;
var = VELOCITY_GRADIENT22;
var = VELOCITY_GRADIENT23;
var = VELOCITY_GRADIENT31;
var = VELOCITY_GRADIENT32;
var = VELOCITY_GRADIENT33;
var = VOLTAGE;
var = FILL;
var = SHEAR_RATE;
var = PVELOCITY1;
var = PVELOCITY2;
var = PVELOCITY3;
var = POLYMER_STRESS11_1;
var = POLYMER_STRESS12_1;
var = POLYMER_STRESS22_1;
var = POLYMER_STRESS13_1;
var = POLYMER_STRESS23_1;
var = POLYMER_STRESS33_1;
var = POLYMER_STRESS11_2;
var = POLYMER_STRESS12_2;
var = POLYMER_STRESS22_2;
var = POLYMER_STRESS13_2;
var = POLYMER_STRESS23_2;
var = POLYMER_STRESS33_2;
var = POLYMER_STRESS11_3;
var = POLYMER_STRESS12_3;
var = POLYMER_STRESS22_3;
var = POLYMER_STRESS13_3;
var = POLYMER_STRESS23_3;
var = POLYMER_STRESS33_3;
var = POLYMER_STRESS11_4;
var = POLYMER_STRESS12_4;
var = POLYMER_STRESS22_4;
var = POLYMER_STRESS13_4;
var = POLYMER_STRESS23_4;
var = POLYMER_STRESS33_4;
var = POLYMER_STRESS11_5;
var = POLYMER_STRESS12_5;
var = POLYMER_STRESS22_5;
var = POLYMER_STRESS13_5;
var = POLYMER_STRESS23_5;
var = POLYMER_STRESS33_5;
var = POLYMER_STRESS11_6;
var = POLYMER_STRESS12_6;
var = POLYMER_STRESS22_6;
var = POLYMER_STRESS13_6;
var = POLYMER_STRESS23_6;
var = POLYMER_STRESS33_6;
var = POLYMER_STRESS11_7;
var = POLYMER_STRESS12_7;
var = POLYMER_STRESS22_7;
var = POLYMER_STRESS13_7;
var = POLYMER_STRESS23_7;
var = POLYMER_STRESS33_7;
var = SPECIES_MASS_FRACTION;
var = SPECIES_MOLE_FRACTION;
var = SPECIES_VOL_FRACTION;
var = SPECIES_DENSITY;
var = SPECIES_CONCENTRATION;
var = SPECIES_CAP_PRESSURE;
var = SPECIES_UNDEFINED_FORM;
var = POR_LIQ_PRES;
var = POR_GAS_PRES;
var = POR_POROSITY;
var = POR_TEMP;
var = POR_SATURATION;
var = VORT_DIR1;
var = VORT_DIR2;
var = VORT_DIR3;
var = CURVATURE;
var = BOND_EVOLUTION;
var = SURF_CHARGE;
var = EXT_VELOCITY;
var = EFIELD1;
var = EFIELD2;
var = EFIELD3;
var = ENORM;
var = NORMAL1;
var = NORMAL2;
var = NORMAL3;
var = SHELL_CURVATURE;
var = SHELL_TENSION;
var = SHELL_X;
var = SHELL_Y;
var = SHELL_USER;
var = PHASE1;
var = PHASE2;
var = PHASE3;
var = PHASE4;
var = PHASE5;
var = SHELL_ANGLE1;
var = SHELL_ANGLE2;
var = SHELL_SURF_DIV_V;
var = SHELL_SURF_CURV;
var = N_DOT_CURL_V;
var = GRAD_V_DOT_N1;
var = GRAD_V_DOT_N2;
var = GRAD_V_DOT_N3;
var = ACOUS_PREAL;
var = ACOUS_PIMAG;
var = ACOUS_ENERGY;
var = POR_SINK_MASS;
var = VORT_DIR1
var = VORT_DIR2
var = VORT_DIR3
var = VORT_LAMBDA
var = CURVATURE
var = LAGR_MULT1
var = LAGR_MULT2
var = LAGR_MULT3
var = BOND_EVOLUTION
var = SURF_CHARGE
var = EXT_VELOCITY
var = EFIELD1
var = EFIELD2
var = EFIELD3
var = ENORM
var = NORMAL1
var = NORMAL2
var = NORMAL3
var = SHELL_CURVATURE
var = SHELL_TENSION
var = SHELL_X
var = SHELL_Y
var = SHELL_USER
var = PHASE1
var = PHASE2
var = PHASE3
var = PHASE4
var = PHASE5
var = SHELL_ANGLE1
var = SHELL_ANGLE2
var = SHELL_SURF_DIV_V
var = SHELL_SURF_CURV
var = N_DOT_CURL_V
var = GRAD_S_V_DOT_N1
var = GRAD_S_V_DOT_N2
var = GRAD_S_V_DOT_N3
var = ACOUS_PREAL
var = ACOUS_PIMAG
var = SHELL_DIFF_FLUX
var = SHELL_DIFF_CURVATURE
var = SHELL_NORMAL1
var = SHELL_NORMAL2
var = ACOUS_REYN_STRESS
var = SHELL_BDYVELO
var = SHELL_LUBP
var = LUBP
var = SHELL_FILMP
var = SHELL_FILMH
var = SHELL_PARTC
var = SHELL_SAT_CLOSED
var = SHELL_PRESS_OPEN
var = SHELL_TEMPERATURE
var = SHELL_DELTAH
var = SHELL_LUB_CURV
var = SHELL_SAT_GASN
var = SHELL_SHEAR_TOP
var = SHELL_SHEAR_BOT
var = SHELL_CROSS_SHEAR
var = MAX_STRAIN
var = CUR_STRAIN
var = LUBP_2
var = SHELL_PRESS_OPEN_2
var = SHELL_LUB_CURV_2

---

External Field

External Field = <char_string1> {char_string2} <file_name> [char_string_3]

Description / Usage

This optional card format provides a mechanism for reading-in nodal field variables stored in an EXODUS II file. Each field variable is specified on a separate input card, with the following input parameters:

<char_string1>

Name of the nodal field to be read; it should correspond to a nodal variable name in the EXODUS II file.

{char_string2}

Two- to eight-character value that identifies the type of interpolation to be applied to the external variable field. Possible values are as follows:

• Q1 - Linear

• Q2 - Quadratic

• Q2_LSA - Special quadratic for 3D analysis of 2D LSA

• Q1_D - Linear with special surface dofs

• Q2_D - Quadratic with special surface dofs

• Q2_D_LSA - Special quadratic discontinuous for 3D

  analysis of 2D LSA

• PQ1 - Bilinear discontinuous

• PQ2 - Biquadratic discontinuous

• P0 - Piecewise constant

• Pl - Piecewise linear

• SP - Subparametric; linear on interior,

  quadratic on surface

<file_name>

Name of the EXODUS II file from which the nodal field is to be read. When Goma is compiled with LIBRARY_MODE defined (see Appendix 2) and the external field will be passed into Goma from a driver code, this entry will be either IMPORT (for nodal variables) or IMPORT_EV (for element variables), instead of a file name.

[char_string3]

Optional character string. Only optional available is “timedependent” which enables nodal variables to be interpolated to the current time step. This option is useful for transient coupling, viz. a case in which a transient field variable is used to drive a time-dependent simulation. A good example of this is a transient current density field from a electromagnetics calculation being used to drive a transient thermal calculation with Joule heating.

Examples

The first example:

External Field = VX Q2 velocity.exoII

External Field = VY Q2 velocity.exoII

The second example:

External Field = JX_FIELD Q2 fields.exoII

External Field = JY_FIELD Q2 fields.exoII

External Field = BTHETA_FIELD Q2 fields.exoII

The third example:

External Field = DMX Q1 IMPORT

External Field = DMY Q1 IMPORT

External Field = P_POR Q1 IMPORT_EV

The fourth example:

External Field = JE_N_1 Q1 emfields.exoII time_dependent

Technical Discussion

The field variables read into Goma from the Example cards can be accessed in any user-defined subroutine.

In the case of variables named VX, VY, or VZ, these fields are automatically loaded to the appropriate velocity component so they can be used in an advection-diffusion analysis, i.e., VX, VY, VZ are reserved names for <char_string1> and a user-defined routine is not required. Thus the variables for the two fields, “VX” and “VY”, read from the file named “velocity.exoII” in the first example above, would be automatically accessed when the advection term is left on in the energy or species_bulk equation cards. In other words, without solving the momentum equations, one can access an external velocity field for advection-diffusion problems. These variables would have quadratic interpolation (Q2) applied to the velocity values read.

The three cards in the second example can be used to read two components of a current density field (JX_FIELD, JY_FIELD), and the azimuthal component of a magnetic field (BTHETA_FIELD) from the file “fields.exoII” (generated by some other analysis code). These fields are then accessed in the user-defined subroutines as

fv->external_field[0], fv->external_field[1], and fv->external_field[2],

respectively, as an interpolated value at an integration point. NOTE that these fields are brought in as a part of the BOUSS_JXB_FORCE on the Navier Stokes source card. These are to be distinguished from the electromagnetic fields in the fourth example which correspond to Solid Momentum Source models.

Note that the number of field variables read from the EXODUS II file must not exceed the value MAX_EXTERNAL_FIELD set in the include file rf_fem_const.h. Should that occur, a new version of Goma must be compiled with an increased value of MAX_EXTERNAL_FIELD. The user should consult notes on building Goma if (s)he has questions regarding how to do this.

The third example assumes that Goma has been compiled with LIBRARY_MODE and is linked in to an external driver code along with another program which will compute some variables and pass their values into Goma; here the imported fields are the X and Y components of mesh displacement (nodal variables) and porosity (an element variable). There is a naive first order interpolation function in Goma to obtain nodal values of fields which are imported as element variables. Although Goma does not solve for these variables, their values are included in the output Exodus file.

In the fourth example a field JE_N_1, the x-directed current density field, timedependent, is brought in from emfields.exoII. Typically, depending on the dimension of the problem, additional fields JE_N_2, JE_N_3 are also brought in as current density is a e. These fields are part of the JXB Solid Momentum Source model, together with the magnetic nodal field quantities, BE_N_1, BE_N_2, and BE_N_3.

Several other standard external fields variables are supported in GOMA. Namely:

FVP11, FVP22, etc. These fields are useful for the elastoviscoplasticity model. Please consult GOMA tutorial GT-019.2 for more details.

SAT, HEIGHT, PERM, CROSS_PERM, SH_SAT_CL_POROSITY, etc. These are specially designated external fields which are mapped to variations in these properties corresponding to thin porous media. Please see GT-038.

References

GT-019.2. Elastoviscoplastic (EVP) Consitutive Model in GOMA: Theory, Testing, and Tutorial, P. R. Schunk, A. Sun, S. Y. Tam, and K. S. Chen. Memo to Distribution. March 13, 2003.

GT-038.0: Pixel-to-Mesh Tool Tutorial for GOMA. P R. Schunk, Memo to distribution, 10 November 2009.

---

Export Field

Export Field = <integer1>

Description / Usage

Special capability for use in library mode, a mode in which GOMA is called as a library from a driver program. This card is used to indicate which fields will be exported for use in other codes.

<integer1>

Name of the nodal field to be read; it should correspond to a nodal variable name in the EXODUS II file.

Technical Discussion

See Appendix 2.

---

External Pixel Field

External Pixel Field = <char_string1> {Q1|Q2} <file_name> <integer1>

Description / Usage

This optional card format provides a mechanism for reading-in pixel fields which are converted (mapped, with a least squares algorithm) to finite element fields with the chosen interpolation. After GOMA execution these fields are output in exodusII format in a file map.exoII. Please see discussion below and Tutorial GT-038 for more details and important tips.

<char_string1>

Name of the nodal field to be read; it should correspond to a nodal variable name you wish to have in the output EXODUS II file. If you subsequently wish to read the field in again and use as an EXTERNAL_FIELD model on other material property card, the chosen name matters.

{Q1 | Q2}

The type of interpolation to be applied to the external pixel field variable field. Possible values are as follows:

• Q1 - Linear

• Q2 - Quadratic

<file_name>

Name of the text file name with the pixel points. The pixel field format in this file should be as follows:

• # pixel points

• x_1, y_1, z_1 value

• x_2, y_2, z_2 value

• …

• x_N, y_n, z_n value

<integer1>

Material block ID to which the pixel field is mapped.

Examples

External Pixel Field = HEIGHT Q1 tread.txt 1

Technical Discussion

Please consult the tutorial GT-038 before using this capability. Many user tips are given together with a more thorough explanation on the proper use This capability is extremely memory intensive, and excessive grid sizes and pixel densities can blow out the memory on your machine. As of 12/22/2012 (the end of the Mayan calendar) these fields are used typically to bring in pattern maps for scaling porous media and lubrication height properties.

SAT, HEIGHT, PERM, CROSS_PERM, SH_SAT_CL_POROSITY, etc. These are specially designated external fields which are mapped to variations in these properties corresponding to thin porous media. Please see GT-038.

References

GT-038.0: Pixel-to-Mesh Tool Tutorial for GOMA. P R. Schunk, Memo to distribution, 10 November 2009.

---

Pressure Datum

Pressure Datum = <float> { atm | torr | cgs }

Description / Usage

This card is used to set a thermodynamic pressure datum on fluid or solid mechanics problems that calculate equations of state requiring a true value for the total pressure. The total pressure is then defined as the sum of a constant base thermodynamic pressure, specified by this card, and a variable hydrodynamic pressure calculated via the pressure unknown. Definitions of the input parameters are as follows:

<float>

Value of the thermodynamic pressure datum.

{ atm | torr | cgs }

Units of the float specified above.

Examples

Following is a sample card:

Pressure Datum = 1.0 atm

Technical Discussion

The value of this variable is stored in the unified problem description structure in cgs units. It is then used in consistency checks and as input into some equation of state routines, such as the ideal gas equation of state routine.

---

Anneal Mesh on Output

Anneal Mesh on Output = {yes | no}

Description / Usage

This optional card enables the user to specify that the mesh displacements should be set to zero for the next continuation step. Valid options for this input card are

yes

Set the mesh displacements to zero for the next continuation step.

no

Do not set the mesh displacements to zero for the next continuation step. This is the default.

There are two important restrictions: 1) annealing the mesh will not work for the TOTAL_ALE mesh motion types, and 2) only the last time step will be annealed for transient problems.

Examples

Following is a sample card:

Anneal Mesh on Output = yes

Technical Discussion

Annealing a mesh is accomplished by adding the displacements (from the solution) to the base positions (from the FEM file) and writing the resulting nodal positions to a new EXODUS II file, currently anneal.exoII. During the annealing process, the displacement field is also set to zero. This file would be used to restart a subsequent analysis where the anneal.exoII is copied to, or becomes, the file used in a read_exoII option for an Initial Guess.