4.4.8. Element Death

Element death is a dynamic process in which existing elements are identified by their state as being active (included in the simulation) or inactive/dead (excluded from the simulation). This capability is implemented in two different flavors, one where elements are explicitly removed (Standard Element Death) and another (CDFEM) in which elements are subdivided in a manner consistent with the element death criterion. Tradeoffs between the two include:

CDFEM has been shown to possess a notion of solution convergence, whereas standard element death is only qualitatively correct.
Standard element death can be applied to bulk volume discretizations of any element topology, whereas CDFEM element death is limited to 2D triangular and 3D tetrahedral discretizations.
Generally speaking, CDFEM is more computationally expensive than standard element death but provides a higher resolution in front tracking.

With a few exceptions both element death implementations utilize essentially the same command directives.

The element death capability is composed of two parts, definition of criterion and definition of its scope. Each death criterion definition must be named uniquely (DeathName) and its scope will be the specific set of mesh entities, blocks of the input mesh to which the criterion is applied. See the command reference for details on all available commands.

Attention

While an element death definition can include many mesh entities, these entities must correspond to a single element topology, i.e. Hex8, Tet4.

The element death process will result in a new discretization that may include surfaces defined by dead elements. The new discretization will be written to a results file named the same as the original results file but appended with a suffix, e.g. for an original file t.e the new discretization would be t.e-s0002. For simulations in which elements are continually being killed this results in a numbered sequence of output files.

Note

Visualization of element death differs between standard element death and CDFEM element death but is somewhat straightforward as most applications will automatically load the collection of output files to produce the appropriate model animation.

4.4.8.1. Standard Element Death

In standard element death, characterization of the death state is monitored using an element variable (DEATH_STATUS) which denotes whether an element is currently active (DEATH_STATUS $=1$ ) or inactive (DEATH_STATUS $=0$ ). Visualization of a model with the “dead” elements removed is made possible by use of the DEATH_STATUS output variable. Since DEATH_STATUS $=0$ denotes dead elements, the DEATH_STATUS variable can then be used in conjunction with any visualization thresholding utility to animate the element death process.

During a simulation in which standard element death is defined, one can monitor the extent of element death through two values output to the log file, KILLED_ELEMENTS and TOTAL_DEAD_ELEMENTS. KILLED_ELEMENTS reports the number of elements removed from the simulation after completion of the current time step while TOTAL_DEAD_ELEMENTS is the cumulative number of elements deleted. Both KILLED_ELEMENTS and TOTAL_DEAD_ELEMENTS are also available for output to the results/heartbeat output as global variables under the same name (e.g. global variables = killed_elements).

One can also monitor the extent of element death by observing the number of unknowns in the nonlinear solution step portion of the log file. More specifically, the content of the line beginning with * Matrix:Solver: which contains the number of unknowns on processor rank 0 but and the following line beginning with * Mesh will contain the number of elements on processor rank 0.

4.4.8.2. CDFEM Element Death

In CDFEM, characterization of the death state is monitored directly by the contents of two element block entities: the original element block and an internally generated “death” part. The “death” part has the base name of original element block appended with _DEAD (e.g. the “death part” for BLOCK_3 would be BLOCK_3_DEAD). When element death occurs, elements in the original element block are removed and transitioned to the “death” part. Since the “death” part is not part of the original mesh, the user must define this part within the Finite Element Model command block in the same way as the original element block was defined e.g.

# Scope: Sierra
Begin Finite Element Model The_Mesh
  Database Name = mesh.g
  Decomposition Method = rcb

  use material foo for block_1
  use material foo for block_1_dead
  ...
End

During a simulation in which CDFEM element death is active, one can roughly monitor the extent of element death by observing the number of unknowns in the nonlinear solution step portion of the log file.

Note

As state above, the content of the line beginning with * Matrix:Solver: contains the number of unknowns on processor 0, but changes on processors other than rank 0 are not recorded in the log file.

Visualization of a model with CDFEM element death is straightforward since a clear distinction is made between the element blocks in the original mesh and the “death” part. Hence one can proceed in the same way as the original mesh.

4.4.8.3. General Death Syntax

Death criteria can be expressed in terms of any internal field. As an example, a standard element death command block named criteria DEATH_TEMP8 based upon the average nodal temperature solution on BLOCK_3 exceeding temperature of 322 K might be defined as:

# Scope: Sierra > Procedure > Aria Region
Begin Element Death death_temp8
  add volume block_3
  Criterion is Avg nodal value of solution->Temperature > 322.0
End

The equivalent syntax for CDFEM death differs only in the command block specification, Begin CDFEM death death_temp8.

# Scope: Sierra > Procedure > Aria Region
Begin CDFEM Death death_temp8
  add volume block_3
  Criterion is Avg nodal value of solution->Temperature > 322.0
End

As elements are deactivated, elements that were previously internal can become exposed as external surfaces. For consistent applications of boundary conditions, the interface between the active and inactive elements is captured in a surface part named surface_<DEATHNAME> e.g. surface_death_temp8. As an example, with standard element death a flux boundary condition applied to the surface of a block with element death occurring can be achieved with

# Scope: Sierra > Procedure > Aria Region
Begin Heat Flux Boundary Condition X-face
  Add Surface surface_4
  Add Surface surface_death_temp8
  Flux = 100.
End

where the addition of Add Surface surface_death_temp8 ensures that the boundary condition surface is continually updated.

Note

Element death impacts the existence of the element in all physics defined in the Aria Region. In problems defined with segregated physics, then, the element death behavior must be defined outside the scope of any Equation System.

In most cases the element death criteria will be evaluated based upon values computed within Aria. Here the death criteria are evaluated at the end of a solution step. With standard element death, it is also possible to evaluate the criteria based upon externally supplied “transfer” variables. In this case one can force the death criteria to be evaluated at the beginning of time step using the Transfer Element Death command line.