4.6. Postprocessing

Table of Contents

4.6.1. Overview 

Aria supports a number of different post-processors for doing in-situ post-processing of custom and pre-defined quantities. The native Aria post-processors are built on the same expression system that the rest of Aria uses and are compatible with GPU execution and meshes over the 32-bit limit. An expression in Aria is defined either as a material property, like DENSITY here:

DENSITY = [MODEL_NAME]

or as a degree of freedom (DOF) solved for by an equation, like TEMPERATURE here:

EQ ENERGY FOR TEMPERATURE ON BLOCK_1 USING DIFF

See Expression Overview for more information on expressions.

The Aria post-processors let you calculate exact fluxes for equations, or perform common reductions and other operations on these expressions. You can also use the expressions as inputs to user-defined string functions to produce custom output. Refer to String Functions for more details about constructing string functions.

The general syntax for Aria post-processors is

POSTPROCESS [OP] OF [TARGET] [NAME] ON [LOCATION] AS [OUTPUT]

The following sections show the specific arguments available to use and how to apply this command to a variety of common post-processing operations. For a comprehensive listing of all possible commands, the user is directed to Postprocessing.

Note

In problems contained element death, post-processed reductions represent the values just before element death.

Note

Some post-processing commands are shown here on multiple lines using the \$ line continuation character. This is optional - they can be on one line if you prefer.

4.6.2. Fluxes 

4.6.2.1. Integrated Flux 

Flux post-processors can be constructed in two ways. The most accurate method is to use the residual of a given equation on the boundary nodes excluding the boundary condition contributions. As long as the equation is solved to a sufficiently small linear residual, this method will return the exact flux applied by the discretized governing equations.

Note

Since the residual flux approach works by skipping boundary condition contributions it will not work correctly on sidesets that do not have a boundary condition applied (e.g. internal sidesets). Additionally, in cases with shell surfaces that have different flux boundary conditions on each side of the shell, the integrated flux will compute the total flux on the shell surface, not the individual contributions. In both of these cases, an expression flux postprocessor should be used.

The syntax to use the residual approach requires specifying an equation name (EQ), sideset name (SURF), and output variable name (OUTPUT):

POSTPROCESS INTEGRATED_FLUX OF EQUATION [EQ] ON [SURF] AS [OUTPUT]

For example, to post-process the heat flux on surface_1 one could use:

POSTPROCESS INTEGRATED_FLUX OF EQUATION ENERGY ON SURFACE_1 AS HEAT_FLUX

The result of this operation will be a global variable named HEAT_FLUX, which follows the Aria sign convention where positive flux is out of the domain. Since the flux ( $W/m^2$ in SI-MKS) is integrated over the specified surface, the result will have units of $W$ if the problem is in SI-MKS units.

In addition to post-processing a flux using the nodal residual of an equation, one can also post-process a flux of a given vector expression (EXPR).

POSTPROCESS INTEGRATED_FLUX OF EXPRESSION [EXPR] ON [SURF] AS [OUTPUT]

For example, to use the HEAT_CONDUCTION expression (a flux vector defined as $-k\nabla T$ ) to post-process heat flux one could use:

POSTPROCESS INTEGRATED_FLUX OF EXPRESSION HEAT_CONDUCTION ON SURFACE_1 AS HEAT_FLUX

Note

Calculating integrated flux using an expression vector like HEAT_CONDUCTION will include discretization errors not present in the residual approach and may be significantly less accurate. The residual approach should be preferred where possible. See Expression Flux Limitations for more discussion on this point.

A user-defined vector function can also be provided for the flux integration if desired, for example:

POSTPROCESS INTEGRATED_FLUX OF VECTOR_STRING_FUNCTION   \$
  f_x = "-heat_conduction_x + density*velocity_x"       \$
  f_y = "-heat_conduction_y + density*velocity_y"       \$
  f_z = "-heat_conduction_z + density*velocity_z"       \$
  ON SURFACE_1 AS HEAT_MASS_FLUX

Warning

Expression flux postprocessors use the outward facing normal of the domain on which they are run. For this reason, care must be taken when running an expression flux postprocessor on an internal sideset. In these cases, the reduction will contain contributions from both sides of the shared interface, such that terms from the +normal and -normal sides will (partially) cancel. It is recommended to always specify a touching block when postprocessing on internal sidesets to clearly define the normal vector e.g.

POSTPROCESS INTEGRATED_FLUX OF EXPRESSION HEAT_CONDUCTION ON \$
  INTERNAL_SURFACE TOUCHING BLOCK_1 AS HEAT_FLUX_B1

If the average across the internal sideset is desired, a global_function can be used (noting the minus sign on one term) e.g.

POSTPROCESS INTEGRATED_FLUX OF EXPRESSION HEAT_CONDUCTION ON \$
  INTERNAL_SURFACE TOUCHING BLOCK_1 AS HEAT_FLUX_B1
POSTPROCESS INTEGRATED_FLUX OF EXPRESSION HEAT_CONDUCTION ON \$
  INTERNAL_SURFACE TOUCHING BLOCK_2 AS HEAT_FLUX_B2
POSTPROCESS GLOBAL_FUNCTION "(HEAT_FLUX_B1 - HEAT_FLUX_B2)/2" AS HEAT_FLUX_B12

4.6.2.2. Average Flux 

Similar to the integrated flux command, one can also post-process an average flux using either an equation residual or a vector expression (or string function):

POSTPROCESS AVERAGED_FLUX OF EQUATION [EQ] ON [SURF] AS [OUTPUT]
POSTPROCESS AVERAGED_FLUX OF EXPRESSION [EXPR] ON [SURF] AS [OUTPUT]

The averaged flux is defined as the integrated flux over the specified surface divided by the area of the specified surface. The resulting global variable will have units of $W/m^2$ for a problem in SI-MKS units and the same caveats about accuracy of the expression approach apply.

The AVERAGED_FLUX reduction also allows an optional weighting factor for doing a weighted average (only when operating on an expression or string function, not using the residual-based flux on an equation). For example:

POSTPROCESS AVERAGED_FLUX OF EXPRESSION HEAT_CONDUCTION \$
   ON SURFACE_1 WITH WEIGHTING "DENSITY" AS WFLUX

4.6.2.3. Flux Fields 

In addition to the integral and average flux reductions described in the prior sections you can also output the residual flux as either a scalar or vector field.

POSTPROCESS FLUX_SCALAR_FIELD OF EQUATION [EQ] ON [SURF] AS [OUTPUT]
POSTPROCESS FLUX_VECTOR_FIELD OF EQUATION [EQ] ON [SURF] AS [OUTPUT]

Both of these commands will create a nodal field on the specified sideset that can be included in your Exodus output file (see Output Reference).

The scalar field option uses the Aria sign convention where flux out of the domain is positive. The vector field option is simply the scalar field flux value multiplied by the nodal outward facing normal vector.

4.6.3. Standard Reductions (integral, average, etc)

Aria has several reduction types available that can take a spatially varying quantity and output a global variable:

POSTPROCESS [REDUCTION_TYPE] OF EXPRESSION [EXPR] ON [PART] AS [OUTPUT]
POSTPROCESS [REDUCTION_TYPE] OF FUNCTION "[FUNCTION]" ON [PART] AS [OUTPUT]

Most of these reductions can be calculated either on volumes (blocks) or surfaces (sidesets).

Reduction types include INTEGRAL, AVERAGE, MIN, MAX, and several others. The complete list of options and details of these types are defined in Operator Definitions.

The spatially varying input for the reduction post-processors can be either an expression (e.g. DENSITY or TEMPERATURE) or a string function of several expressions. For example:

POSTPROCESS INTEGRAL OF FUNCTION "TEMPERATURE*SPECIFIC_HEAT*DENSITY" \$
     ON BLOCK_1 AS INTERNAL_ENERGY

For the averaging reduction types (AVERAGE, AVERAGED_FLUX, and RMS) one can also specify an optional weighting factor as a string function. For example, to calculate a density weighted average temperature one would use:

POSTPROCESS AVERAGE OF EXPRESSION TEMPERATURE ON BLOCK_1 \$
    WITH WEIGHTING "DENSITY" as Tavg

4.6.3.1. Operator Definitions 

The available reduction operations and equations for each reduction type are defined in the following section.

4.6.3.1.1. Integral

The integral postprocessor reduction over a volume (block) is defined as:

$\int\limits_\Vol f(\vector{x}) \dV$

When evaluated on a surface, it is defined as:

$\int\limits_\Surf f(\vector{x}) \dS$

4.6.3.1.2. Average

Average (with default weight $w_e = 1$ unless specified) evaluated over a volume (blocks) is defined as:

$\frac{\int\limits_\Vol f(\vector{x}) w_e(\vector{x}) \dV}{\int\limits_\Vol w_e(\vector{x}) \dV}$

When evaluated on a sideset, the average is defined over the surface area as:

$\frac{\int\limits_\Surf f(\vector{x}) w_e(\vector{x}) \dS}{\int\limits_\Surf w_e(\vector{x}) \dS}$

4.6.3.1.3. RMS

RMS (with default weight $w_e = 1$ unless specified):

$\left( \frac{\int\limits_\Vol |f(\vector{x})|^2 w_e(\vector{x}) \dV}{\int\limits_\Vol w_e(\vector{x}) \dV} \right)^{\frac{1}{2}}$

4.6.3.1.4. L-1 Norm

The L-1 Norm (command L_1_NORM) is evaluated with:

$\int\limits_\Vol |f(\vector{x})| \dV$

4.6.3.1.5. L-2 Norm

The L-2 Norm (command L_2_NORM) is evaluated with:

$\left( \int\limits_\Vol |f(\vector{x})|^2 \dV \right)^{\frac{1}{2}}$

4.6.3.1.6. L-Infinity Norm

The L- $\infty$ Norm (command L_INF_NORM) is evaluated with:

$\max_{node} |f(\vector{x}_{node})|$

4.6.3.1.7. H-1 Semi-Norm

The H-1 Semi-Norm (command H_1_NORM) is evaluated with:

$\left( \int\limits_\Vol \grad f(\vector{x}) \bcdot \grad f(\vector{x}) \dV \right)^{\frac{1}{2}}$

4.6.3.1.8. Max

The maximum (command MAX) evaluates the nodal maximum:

$\max_{node} f(\vector{x}_{node})$

4.6.3.1.9. Min

The minimum (command MIN) evaluates the nodal minimum:

$\min_{node} f(\vector{x}_{node})$

4.6.4. Aliased Reduction Operations 

You can post-process the mass or volume of a given block using the previously defined post-processors by postprocessing an integral of density for mass or of a function of "1" for volume, but for convenience there are also shortcuts for post-processing mass and volume.

POSTPROCESS MASS ON BLOCK_1 AS M
POSTPROCESS VOLUME ON BLOCK_2 AS V

You can also use the EACH_BLOCK shortcut to automatically output these quantities per block. See Selecting Post-Processing Domains for more details.

4.6.5. Field Values 

In addition to fluxes and reduction operations, you can post-process spatially varying quantities and output them as nodal fields. The syntax for this is similar to the reduction types, the primary difference is that the output is a nodal field instead of a global variable. The nodal field created by this command can then be included in your Exodus output file (see Output Reference).

POSTPROCESS VALUE OF EXPRESSION [EXPR] ON [PART] AS [OUTPUT]
POSTPROCESS VALUE OF FUNCTION "[FUNCTION]" ON [PART] AS [OUTPUT]

POSTPROCESS VALUE OF VECTOR_STRING_FUNCTION                     \$
  f_x = "[FX]" f_y = "[FY]" f_z = "[FZ]" ON [PART] AS [OUTPUT]

POSTPROCESS VALUE OF TENSOR_STRING_FUNCTION                      \$
  f_xx = "[FXX]" f_xy = "[FXY]" f_xz = "[FXZ]"                   \$
  f_yx = "[FYX]" f_yy = "[FYY]" f_yz = "[FYZ]"                   \$
  f_zx = "[FZX]" f_zy = "[FZY]" f_zz = "[FZZ]"                   \$
  ON [PART] AS [OUTPUT]

The OUTPUT expression is then also available for use in subsequent postprocessors. If PART is a block(s), the expression is also provided on all surfaces touching the block. For example:

POSTPROCESS VALUE OF FUNCTION "X*Y*Z" ON ALL_BLOCKS AS MY_EXPR
POSTPROCESS MAX OF EXPRESSION MY_EXPR ON BLOCK_1 AS MAX_EXPR_B1
POSTPROCESS MAX OF EXPRESSION MY_EXPR ON SURFACE_1 AS MAX_EXPR_S1

There is also a shorter syntax available for post-processing expressions:

POSTPROCESS [EXPR] ON [PART]

which is equivalent to the POSTPROCESS VALUE OF EXPRESSION command.

4.6.6. Data Probes 

To evaluate the value of a quantity at a specified point, you can use the data probe processing command:

POSTPROCESS VALUE of [SRC] at [LOC] as [OUTPUT]

The evaluation location LOC can be specified either as - NODE <nodeID> – ID of a specific node in the mesh - POINT <x_coord> <y_coord> <z_coord> – specific location in the mesh

The supported SRC types are: - FIELD [NAME] – evaluate probe on existing field NAME - EXPRESSION [NAME] – evaluate probe on expression NAME - FUNCTION, VECTOR_STRING_FUNCTION, TENSOR_STRING_FUNCTION – evaluate probe on string function

Along with existing fields (e.g. solution-> fields), postprocessed fields are also available for data probes. For example:

POSTPROCESS VALUE of EXPRESSION TEMPERATURE at POINT 0. 0. 0. as Torigin

is exactly equivalent to:

POSTPROCESS VALUE of EXPRESSION TEMPERATURE on ALL_BLOCKS as TEMP_FIELD
POSTPROCESS VALUE of FIELD TEMP_FIELD at POINT 0. 0. 0. as Torigin

Similarly:

POSTPROCESS VALUE of FUNCTION "2*TEMPERATURE" at NODE 123 as T2origin

is exactly equivalent to:

POSTPROCESS VALUE of FUNCTION "2*TEMPERATURE" on ALL_BLOCKS as DBL_TEMP_FIELD
POSTPROCESS VALUE of FIELD DBL_TEMP_FIELD at NODE 123 as T2origin

For the POINT location type, the parametric tolerance and part restrictions of the search can be optionally specified using

POSTPROCESS VALUE of EXPRESSION TEMPERATURE at POINT 0. 0. 0. as T2origin \$
  with TOLERANCE 1e-3 RESTRICTED to BLOCK_1 BLOCK_2

Warning

The POINT location is Eulerian (remains at a fixed point throughout the simulation), whereas the NODE specification is Lagrangian (sticks to that node and thus follows any deformation of the mesh at that node). For a Lagrangian specification of a specific point, see the nearest functionality of a heartbeat block.

4.6.6.1. Points outside the domain 

By default, the POINT probes will pick a tolerance based on the mesh sizes and search for a matching element not farther than that tolerance. A user can also specify a tolerance with the with tolerance X argument.

If the probe does not find a matching element within its tolerance, the default behavior is to error out. When the point is outside any elements, but less than the tolerance away from one, it will snap to the nearest element and warn.

To change the behavior of the data probe when it is more than the tolerance outside of an element, add the points_outside_tol argument. For example:

POSTPROCESS VALUE of EXPRESSION TEMPERATURE at POINT 0. 0. 0. as T2origin \$
  points_outside_tol = nan

When the point is outside the specified tolerance, its value here will be set to NaN. Other options include zero, bignum (1e100), or abort (the default). Using NaN should be preferred since most plotting tools will handle automatically omitting the values and it is the least likely to be mistaken for a real value.

If a data probe leaves the mesh and switches to a specified value mode it will continue to set that value every step until it comes back into the mesh, at which time it will return to normal operation.

4.6.7. Mesh Fields 

A limited set of reduction post processors are available for post processing mesh fields directly. These are: min, max, average, L1 Norm, L2 Norm, L $\infty$ Norm, and RMS. Unlike expression post processors, mesh field post processors operate directly on the values stored in STK mesh fields as opposed to calculated by the expression system. The advantage of this is that it allows post processing operations that would be impossible otherwise (eg. post processing on node sets). The downside is a potential loss of accuracy as field post processors are unaware of the underlying finite element discretization and expression relationships. The most obvious example of this is that calculating the L2 norm of a solution field will give a different result than if the L2 norm of the same solution DOF were post processed using an expression based post processor. This is because the expression post processor will perform an integral using the finite element basis, whereas the field post processor will compute a simple nodal sum of squares. It is recommended that expression post processors be preferred to field post processors whenever possible.

The field post processor line command is:

POSTPROCESS [REDUCTION] of field [FIELD NAME] at [LOC] as [OUTPUT]

Field post processors can be calculated with block style syntax as well with this source line:

SOURCE TYPE = FIELD NAME = [FIELD NAME]

The reduction types that can be used with field post processors are:

MIN – $\min_{e} f(e)$
MAX – $\max_{e} f(e)$
AVERAGE – $\frac{\sum_e f(e)}{N_e}$
L_1_NORM – $\sum_e |f(e)|$
L_2_NORM – $\sqrt{\sum_e f^2(e)}$
L_INF_NORM – $\max_{e} |f(e)|$
RMS – $\sqrt{\frac{\sum_e f^2(e)}{N_e}}$

e denotes the entity type over which the field is defined (element or node), $N_e$ is the number of entities in the part the post processor is calculated over, and f(e) is the value of the field at a given entity.

4.6.8. Global Values 

To create a post-processor whose inputs are only global variables, you can use the global function postprocessor command:

POSTPROCESS GLOBAL_FUNCTION "[FUNCTION]" as [OUTPUT]

For example:

POSTPROCESS AVERAGE OF EXPRESSION TEMPERATURE ON BLOCK_1 AS T_avg
POSTPROCESS AVERAGE OF EXPRESSION DENSITY ON BLOCK_1 AS rho_avg
POSTPROCESS GLOBAL_FUNCTION "T_avg + rho_avg" as T_rho_avg

Note

Global functions are evaluated one at a time in the order specified in the input file, and are always run last, after reduction and value post-processors.

Global functions may contain circular references. If a global function uses its output value as one of its inputs, the value used will be the output from the prior evaluation. This allows the creation of “latching” functions or state shifts.

For example, to create a variable that switches from $0$ to $1$ to indicate if the domain ever had an average temperature above 500 at any time in the simulation one could do:

POSTPROCESS GLOBAL_FUNCTION                    \$
   "(Tavg>500 && abv500==0) ? 1 : abv500"      \$
   as abv500

Alternately, to keep the last 4 time states for a global variable and create a trailing average one could do:

POSTPROCESS AVERAGE OF EXPRESSION TEMPERATURE ON BLOCK_1 AS Tavg
POSTPROCESS GLOBAL_FUNCTION "Tavg2" as Tavg3
POSTPROCESS GLOBAL_FUNCTION "Tavg1" as Tavg2
POSTPROCESS GLOBAL_FUNCTION "Tavg0" as Tavg1
POSTPROCESS GLOBAL_FUNCTION "Tavg"  as Tavg0

POSTPROCESS GLOBAL_FUNCTION              \$
    "(Tavg3 + Tavg2 + Tavg1 + Tavg0)/4"  \$
    as T_running_avg

On a given step, this will first calculate a new value for Tavg, then shift the stored values of TavgX back by one position each and finally calculate a trailing average of the last 4 time step values.

4.6.9. Post-Processing Specific Models 

By default Aria sums source terms and boundary flux terms together in a single expression (e.g. ENERGY_SOURCE or ENERGY_FLUX). To post-process specific contributions to these expressions requires an extra argument to select which model you want to post-process.

For example, consider a case where you have two boundary conditions applied and two source terms in an energy equation

Source for Energy on block_1 = Melting_Source
Source for Energy on block_1 = Joule_Heating

BC Flux for Energy on surface_1 = Generalized_Rad
BC Flux for Energy on surface_1 = Generalized_Nat_Conv

If you wanted to post-process the total energy source and total flux you could use the previously defined commands as:

Postprocess value of expression energy_source on block_1 as Esrc
Postprocess value of expression energy_flux on surface_1 as Eflux

Note

The name of the expression here (e.g. “energy_flux”) comes from the applied BC line. For BC [TYPE] for [EQ] the name will be Postprocess value of expression EQ_TYPE on .... If you are using a Calore-style BC block, you must find the equivalent 1-line BC command to determine what name to use here.

However, if you wanted to post-process contributions from individual models you would need to add the model name:

Postprocess value of expression energy_source on block_1 \$
  Model Joule_Heating as Esrc_jh

Postprocess value of expression energy_flux on surface_1 \$
  Model generalized_nat_conv as Eflux_conv

4.6.10. Universal Expressions 

You can define universal expressions to provide pre-calculated quantities for both material models and post-processors. These act as global, spatially varying functions, and can be evaluated anywhere their inputs are available. The UNIVERSAL ARIA EXPRESSIONS block is added at the Sierra scope (top-level) and is applied to all Aria regions in the problem.

Begin universal aria expressions
  User Expression = [MODEL] user_tag=[NAME] [MODEL_ARGS]
End

For example, to define universal expressions for temperature in Celsius (called tempC), and radius (called rad) you would add:

Begin universal aria expressions
  User Expression = Scalar_String_Function         \$
      user_tag = "tempC" f = "temperature - 273.15"

  User Expression = Scalar_String_Function         \$
      user_tag = "rad" f = "sqrt(x^2 + y^2 + z^2)"
End

Then you could use this expression in your post-processors like this:

Postprocess average of expression tempC on block_1 as TCavg_1
Postprocess average of expression tempC on block_2 as TCavg_2

You could also use tempC or rad as inputs for material properties or in initial conditions and boundary conditions within your Aria regions. For example, to add an initial condition as a function of radius you would use:

IC for Temperature on all_blocks = Scalar_String_Function f = "200 + 30*rad"

4.6.11. Postprocessing Existing Results 

Occasionally it is useful to postprocess existing results files, for example to convert temperatures from Kelvin to Celsius, or to evaluate an intermediate quantity like thermal conductivity that was not included in the initial results. This is possible in Aria by using a combination of an IO Region, Transfer, and XFER equations.

The basic steps for postprocessing existing results is to:

Copy the input file used to generate the results to a new file.

Replace the list of equation terms (MASS, DIFF, etc) with XFER to prevent Aria from re-solving the problem.

Comment out or remove all boundary conditions and source terms.

Add a Finite element model that uses the existing results file as the database.

Add an IO Region referencing that finite element model, and include the Timestep adjustment interval = 1 command in that block.

Setup a Transfer for the solution fields from the existing results file to the Aria region.

Add the new desired postprocessors and output specifications to the Aria region. Make sure to set the results output frequency to output every step and change the output file name to not overwrite the existing results.

Change the time stepping parameters for the Aria Region to use a fixed time step size with the initial time step size matching the termination time. This will let the IO region control the time step to match the times present in the existing results.

Run Aria using the modified copy of the input file.

A complete example of this is presented in Postprocessing Additional Quantities.

Note

There are a few limitations to this approach:

The existing results file must have all the prerequisite field data to calculate the new quantity that is being postprocessed.

Postprocessing of results for problems with Bulk Fluid Elements should use the existing results file for the problem geometry. This will preserve consistency between the element blocks on the grid and results file to facilitate transfer from the IO_Region.

Because we switched equations to XFER and commented out boundary conditions and source terms it is not possible to postprocess integrated fluxes on boundaries, applied boundary condition values, or source term values.

4.6.12. Advanced Details 

4.6.12.1. Selecting Post-Processing Domains 

To evaluate a post-processor on a single block or surface, you can simply use the block or surface name directly:

POSTPROCESS AVERAGE OF EXPRESSION TEMPERATURE ON BLOCK_1 AS T_AVG

To evaluate a post-processor on multiple blocks, you can create an assembly or a mesh group (see Assemblies and Mesh Groups) and evaluate the post-processor on that group:

Mesh Group core_blocks = block_1 block_2 block_3
POSTPROCESS AVERAGE OF EXPRESSION TEMPERATURE ON core_blocks AS T_AVG

For combinations of parts involving both part lists and CONTACTING or TOUCHING notation (see below) you may need to use a block-style post-processor, which supports multiple location commands (Block Style Commands).

You can also use the default aliases ALL_BLOCKS, ALL_SURFACES, and ALL_BULK_ELEMENTS to select all blocks, surfaces, and bulk nodes respectively. The following aliases can be used to apply the postprocessor at each location

EACH_BLOCK: Apply the postprocessor on each active element block in the mesh
EACH_SURFACE: Apply the postprocessor on each active surface in the mesh
EACH_BULK_ELEMENT: Apply the postprocessor on each active bulk node in the mesh

For example, the following command on a mesh containing block_1, block_2, and block_3 will produce four global variables: T_AVG_BLOCK_1, T_AVG_BLOCK_2, T_AVG_BLOCK_3, and T_AVG_TOTAL.

POSTPROCESS AVERAGE OF EXPRESSION TEMPERATURE ON EACH_BLOCK AS T_AVG

4.6.12.1.1. Post-Processing on Contact Surfaces

To postprocess one of the previous quantities on a contact surface, you must use the SURFACE_A CONTACTING SURFACE_B notation for the PART argument. The post-processor will only be evaluated on the portions of SURFACE_A which are in contact with SURFACE_B.

For example:

POSTPROCESS VALUE OF EXPRESSION CONTACT_HEAT_TRANSFER_COEFFICIENT \$
    ON SURFACE_1 CONTACTING SURFACE_2 AS CONTACT_HTC

Note

Since the postprocessor is run only on the faces of SURFACE_A, discontinuous quantities are NOT averaged. The postprocessed value(s) correspond only to the values on SURFACE_A.

4.6.12.1.2. Post-Processing on Surface Subsets

To postprocess one of the previous quantities on a subset of a surface based on what block it is in contact with you can use the SURFACE_A TOUCHING BLOCK_B notation for the PART argument.

The post-processor will only be evaluated on the faces of SURFACE_A which are connected to BLOCK_B.

For example:

POSTPROCESS VALUE OF EXPRESSION TEMPERATURE \$
    ON SURFACE_1 TOUCHING BLOCK_2 AS TSURF_2

4.6.12.1.3. Post-Processing on Internal Sidesets

An internal sideset occurs when a surface exists in between two blocks, as is demonstrated below for some internal surface s shared between block_1 and block_2

      top
+------+------+
|      |      |
|  1   s   2  |
|      |      |
+------+------+

A postprocessor specified on this internal_surf will contain contributions from the values using block_1s expressions as well as block_2s. If the value is continuous across the interface, this will not affect the result. Special care must be taken when postprocessing a quantity which is discontinuous across an internal surface, or one which is connected to multiple blocks. For value postprocessors, contributions of each block are accounted for as defined by the AVERAGING METHOD specified. For example if an internal surface is shared by two blocks, then

POSTPROCESS VALUE OF EXPRESSION DISC_QTY \$
    ON INTERNAL_SURF AS QSURF

will contain the contributions of both

POSTPROCESS VALUE OF EXPRESSION DISC_QTY \$
    ON INTERNAL_SURF TOUCHING BLOCK_1 AS QSURF_B1
POSTPROCESS VALUE OF EXPRESSION DISC_QTY \$
    ON INTERNAL_SURF TOUCHING BLOCK_2 AS QSURF_B2

Similarly for integral reduction types, the average value of the quantity on the surface is taken. For example if an internal surface is exactly shared by two blocks, then

POSTPROCESS AVERAGE OF EXPRESSION DISC_QTY \$
    ON INTERNAL_SURF AS AVGQ

is equivalent to

POSTPROCESS AVERAGE OF EXPRESSION DISC_QTY \$
    ON INTERNAL_SURF TOUCHING BLOCK_1 AS AVGQ_B1
POSTPROCESS AVERAGE OF EXPRESSION DISC_QTY \$
    ON INTERNAL_SURF TOUCHING BLOCK_2 AS AVGQ_B2
POSTPROCESS GLOBAL_FUNCTION \$
    "(AVGQ_B1 + AVGQ_B2)/2" AS AVGQ

For nodal operations (Min, Max, and L-Infinity Norm), the postprocessor can be seen as applying the operator over the limit approaching the surface from each block. For example for some internal surface touching 3 blocks:

POSTPROCESS MAX OF EXPRESSION DISC_QTY \$
    ON INTERNAL_SURF AS MAXQ

is equivalent to

POSTPROCESS MAX OF EXPRESSION DISC_QTY \$
    ON INTERNAL_SURF TOUCHING BLOCK_1 AS MAXQ_B1
POSTPROCESS MAX OF EXPRESSION DISC_QTY \$
    ON INTERNAL_SURF TOUCHING BLOCK_2 AS MAXQ_B2
POSTPROCESS MAX OF EXPRESSION DISC_QTY \$
    ON INTERNAL_SURF TOUCHING BLOCK_3 AS MAXQ_B3
POSTPROCESS GLOBAL_FUNCTION \$
    "MAX(MAXQ_B1, MAXQ_B2, MAXQ_B3)" AS MAXQ

Note

If a quantity is only defined on one side of an internal sideset, one must specify TOUCHING to avoid a missing expression error.

Note

When working with shared surfaces, one must ensure that the mesh is defined such that the sideset is associated with all connected blocks. For example in Cubit, the default behavior of sideset creation connects it to only one block touching the surface. In order for the surface to be touching all connected blocks, it must be defined with the With Respect To box checked and wrt volume set to either all or the blocks of interest.

4.6.12.2. Block Style Commands 

All of the prior post-processing line commands can also be written as multi-line block commands if desired. For example, instead of

POSTPROCESS VALUE OF EXPRESSION TEMPERATURE ON BLOCK_1 AS TEMP1

you could use

BEGIN POSTPROCESS VALUE
  SOURCE TYPE = EXPRESSION NAME = TEMPERATURE
  LOCATION = BLOCK_1
  OUTPUT NAME = TEMP1
END

The general syntax for the block-style post-processors is

BEGIN POSTPROCESS [REDUCTION_TYPE]
  SOURCE TYPE = EXPRESSION NAME = [EXPR]
  LOCATION = [PART]
  OUTPUT NAME = [OUTPUT]
  [WEIGHT FUNCTION = "WFCN"]
  [MODEL = MODEL_NAME]
END

BEGIN POSTPROCESS [REDUCTION_TYPE]
  SOURCE TYPE = FUNCTION "[FUNCTION]"
  LOCATION = [PART]
  OUTPUT NAME = [OUTPUT]
END

For reference, the syntax for the block style commands is outlined in Postprocessing. The primary advantage of the block style command is that you can use multiple LOCATION commands to evaluate the post-processor on multiple parts without using a mesh group or assembly. This allows more complicated combinations of conditions that would not be possible with the line-style command. For example:

BEGIN POSTPROCESS AVERAGE
  SOURCE TYPE = EXPRESSION NAME = TEMPERATURE
  LOCATION = SURFACE_1
  LOCATION = SURFACE_3 TOUCHING BLOCK_2
  LOCATION = SURFACE_4 CONTACTING SURFACE_5
  OUTPUT NAME = TAVG_SURFS
END

4.6.12.3. Self Referencing Field Postprocessing 

Similar to Global Values, self-referencing string functions are supported in value postprocessors. This allows running fields throughout a simulation. E.g. to get the maximum temperature observed at each node over a simulation, one could use the following

POSTPROCESS VALUE OF FUNCTION "TEMPERATURE > MAX_TEMP ? TEMPERATURE : MAX_TEMP" \$
  on block_1 as MAX_TEMP

Note that the initial value taken for a self-referenced field is $0$ (e.g. MAX_TEMP in this example). To start with a different initial value, one can declare the initial value as a user field e.g.

USER FIELD REAL NODE SCALAR MIN_TEMP ON block_1 VALUE = 1e10
POSTPROCESS VALUE OF FUNCTION "TEMPERATURE < MIN_TEMP ? TEMPERATURE : MIN_TEMP" \$
  on block_1 as MIN_TEMP

4.6.12.4. Binary State Fields 

In some cases, a user may wish to track a “state” condition that preserves history as time advances. An example is a material that undergoes an irreversible phase change once it reaches a certain temperature. In this scenario, there is a need to track all nodes or elements that have ever gone above the phase change temperature, not just entities that are above the temperature at the current time step, so that material properties can be set accordingly. This could be accomplished with self-referencing string functions like the following for a nodal field

POSTPROCESS VALUE OF FUNCTION "TEMPERATURE > 1500 ? 1.0 : PHASE_CHANGED" \$
  on block_1 as PHASE_CHANGED

Or like this for an element field

POSTPROCESS VALUE OF FUNCTION "TEMPERATURE > 1500 ? 1.0 : PHASE_CHANGED" \$
  on block_1 as PHASE_CHANGED using P0

However, Aria also provides a shorthand for these operations called binary state fields. Binary state fields are intended to represent a spatially varying two state condition that can be toggled on or off when specified criteria are met but otherwise maintains its state as time advances. Binary state fields will also persist through restarts, which may not always be the case for self-referencing string functions. The common use case for binary state fields is controlling material properties, so they are specified in the material block as opposed to the Aria region or equation system blocks like other postprocessors.

Begin Aria Material material1
  User Expression = Binary_State User_Tag = my_binary_state Initial_State = Inactive \$
    Activation_Function = "element_average_temperature > 1000" Location = Element
End

The above example would create a binary state field that tracks elements whose average temperature has gone above 1000. Aria will automatically generate the necessary postprocessors to populate the defined binary state fields on any of the element blocks the material is used on. Binary state fields cannot be created on surfaces or edges. These postprocessors will be added to the last defined equation system, meaning that binary state fields will always be updated at the very end of a time step. Expressions using a binary state field during an equation solve will use the previous time step’s value. The active state of a binary state field is defined as $1.0$ and the inactive as $0.0$ . This allows them to be easily used in string function conditionals such as the below example that switches thermal conductivity between two values depending on the state

Thermal Conductivity = Scalar_String_Function f = "my_binary_state ? 0.1 : 10"

Element binary state fields can also make use of element averaged expressions. These can be specified in the activation or deactivation criteria using the syntax ELEMENT_AVERAGE_[EXPRESSION]. Element average expression are the volume average of the specified expression over the element.

4.6.12.5. Nodal Averaging Method 

Depending on their continuity, expressions may not have unique values at the nodes of the mesh. For example, any expression that is derived from a gradient operation of a Q1 interpolation can be multi-valued at a given node (e.g., darcy velocity derived from Q1 pressure field, heat flux vector derived from Q1 temperature field, etc.).

Aria supports three nodal averaging methods (i.e., SUPPORT_WEIGHTED, SUPPORT_AVERAGE, SIMPLE) that can be applied in these situations to output a unique post-processed value at the nodes of the mesh using the following line command

POSTPROCESS VALUE OF EXPRESSION MYEXPR ON BLOCK_1 \$
    AS MY_AVERAGED_NODAL_FIELD AVERAGING METHOD = [METHOD]

In most cases, the SUPPORT_WEIGHTED method (DEFAULT) is a good choice and is defined as

$f_i = \frac{\displaystyle{\sum_{e \in E} f_e(\vector{x}_i) \int\limits_{\Vol_e} \phi^i_e\left(\vector{x}\right) w_e(\vector{x}) \dV}}{\displaystyle{\sum_{e \in E} \int\limits_{\Vol_e} \phi^i_e\left(\vector{x}\right) w_e(\vector{x}) \dV}}$

where $E$ is the set of elements $e$ connected to node $i$ , $\phi^i_e\left(\vector{x}\right)$ is the element shape function for node $i$ and where $f_e(\vector{x}_i)$ is the expression value evaluated at node $i$ using the local element shape functions. Note $f_e(\vector{x}_i)$ may be multi-valued at node $i$ , hence the subscript $e$ . Lastly, $w_e\left(\vector{x}\right)$ is an optional weighting that can be applied via the WITH WEIGHTING syntax e.g.,

POSTPROCESS VALUE OF EXPRESSION MYEXPR ON BLOCK_1 \$
    WITH WEIGHTING "DENSITY" AS MY_MASS_AVERAGED_NODAL_FIELD AVERAGING METHOD = SUPPORT_WEIGHTED

When WITH WEIGHTING is not specified, one can interpret the SUPPORT_WEIGHTED nodal value as a volume weighted average i.e.,

$f_i = \frac{\displaystyle{\sum_{e \in E} f_e(\vector{x}_i) \Delta V^i_e}}{V_i}$

where $\Delta V^i_e = \displaystyle{\int\limits_{\Vol_e} \phi^i_e\left(\vector{x}\right) \dV}$ is the volume contribution to node $i$ from connected element $e$ and where $V_i = \displaystyle{\sum_{e \in E} \Delta V^i_e}$ is the total nodal volume for node $i$ . As an aside, note that the finite element shape functions form a partition of unity and so the volume of an element will always be completely accounted for through the sum of its contributions to it nodes.

Similarly, the SUPPORT_AVERAGED method is defined as

$f_i = \frac{\displaystyle{\sum_{e \in E} \int\limits_{\Vol_e} f_e(\vector{x}) \phi_e^i\left(\vector{x}\right) w_e(\vector{x}) \dV}}{\displaystyle{\sum_{e \in E} \int\limits_{\Vol_e} \phi_e^i\left(\vector{x}\right)w_e(\vector{x}) \dV}}$

where $f_e(\vector{x})$ is now the expression value at a point within the element. As such, this nodal averaging method corresponds to an average of the expression within the support domain.

Lastly, the SIMPLE method is defined as the numeric average of the nodal values:

$f_i = \frac{\displaystyle{\sum_{e \in E}} f_e(\vector{x}_i)}{ N_E }$

Note

If an expression corresponds to a field interpolation (i.e., COEFF_OP) then the nodal averaging operations are skipped and the known unique nodal value is simply returned.

4.6.13. Legacy Postprocessor Conversion 

The suite of postprocessors described above are an improvement on the legacy postprocessing capabilities that preceded it, adding additional functionality, concise syntax, and GPU support. As part of the migration to this suite, a conversion tool is provided. The tool is available with a sierra module, e.g.

$ module load sierra
$ legacyPP2aria legacy_file.i native_aria_file.i

and a detailed explanation of its syntax can be found in the help description

$ legacyPP2aria --help

This tool takes a given input file, and converts all legacy postprocessors to the corresponding native Aria postprocessors in the given output file. This typically has the added benefit of making the input more concise. For example

begin field function tempK
  Use Nodal Field Solution->Temperature
end

begin average value postprocessor avg_temp_block_1
  use function tempK
  Volumes block_1
end

begin min max postprocessor max_temp_block_1
  use function tempK
  Volumes block_1
  compute max
end

begin evaluate function postprocessor pt1_temp_block_1
  At Nearest Node
  Location -0.015 0 -0.02
  Volumes block_1
  Use Function tempK
end

...

begin aria region myRegion
  ...

  evaluate postprocessor avg_temp_block_1
  evaluate postprocessor max_temp_block_1
  evaluate postprocessor pt1_temp_block_1
end

becomes

begin aria region myRegion
  ...

  postprocess average of expression temperature on block_1 as avg_temp_block_1
  postprocess max of expression temperature on block_1 as max_temp_block_1
  postprocess value of expression temperature at point -0.015 0 -0.02 as pt1_temp_block_1
end

If the script fails to convert a line, it will keep the original postprocessor intact and will prepend a comment stating why it failed e.g.

# Unable to convert post processor. [REASON]
begin average value postprocessor foo
  ...
end

Note

The legacyPP2aria tool is not meant to cover all corner cases of use. If you are stuck, reach out to sierra-help@sandia.gov for help converting legacy postprocessors to native Aria equivalents.