GrainTracker

The Grain Tracker is a utility that may be used in phase-field simulations to reduce the number of order parameters needed to model a large polycrystal system. The GrainTracker utilizes the FeatureFloodCount object for identifying and extracting individual grains from a solution field. Once the FeatureFloodCount object has identified all grains, the GrainTracker does two things:

  • Match up grains from the current timestep with grains from the previous timestep.

  • Remap grains that are "close" to coming into contact.

Grain Tracking

The ability to track features over time is of interest for many simulation types. Here we present an algorithm for tracking arbitrary features on an unstructured mesh over time. The tracking stage is responsible for maintaining consistent and unique identification for an arbitrary number of moving and interacting features over time. The tracking stage is the only stage in the algorithm which requires stateful data between time steps. This is important from an implementation perspective as it can have an affect on the ability of a simulation to checkpoint, terminate, and successfully restart. Restart capabilities are useful for handling hardware faults or spreading out a long running simulation over several execution windows common in high performance computing environments.

During the first invocation of the feature tracking stage there is no previous feature data to compare against so no tracking is performed. Instead a set of IDs must be assigned to each identified feature. These IDs may be supplied externally if desired. In fact there are no restrictions on the IDs if supplied externally. The IDs need not be contiguous nor must they be unique. However, if separate features are assigned duplicate IDs and those features come into contact during a simulation, the data will be coalesced, which may or may not result in a correct simulation. If an external assignment is not desired, the feature tracking algorithm will assign a set of contiguous and unique IDs to each individual feature. This is accomplished by first sorting the identified features by the min element ID stored in each feature's data structure and assigning a number based on the sorted position. This strategy ensures a stable sorting insusceptible to different mesh partitionings.

On subsequent invocations, the feature information from the previous time step is compared against all of the features from the current time step and organized such that the best matches for all features is determined correctly. The comparison criterion is to globally minimize the centroid distances of all features simultaneously. The centroid is calculated by averaging the element centroids making up each feature. As we iterate over the new list of features, we select the feature in the previous list that is closest by centroid distance. This pairing is saved into a "best match" data structure while the remaining features are being processed.

It's possible for features to compete for the same "best match" feature on the previous time step. This indicates that a feature has been absorbed or has otherwise disappeared on the current step and that its corresponding feature from the previous step is incorrectly identifying an unrelated feature as the best match. This case is handled by marking the feature with the greater centroid distance mismatch as inactive.

When all pairs have been compared, all of the features in the best match data structure are marked ("matched") and the IDs from the previous time step are saved into the corresponding matches in the current time step. Unmatched features from both the new list and previous lists are then handled. The features in the previous list that are unmatched are marked as inactive. The unmatched features in the current list are "new", meaning that they haven't been previously identified. The former case occurs when there are exactly zero features in the current list, meaning any feature in the previous list will remain unmatched. The latter case can occur when a feature splits or when a new feature is created.

Grain Remapping

Figure 1: Red feature bounding boxes intersecting (fast check).

Figure 2: Red feature halos intersecting (complete check).

Grain remapping is implemented using a recursive backtracking algorithm capable of performing several variable swaps to transform the improperly colored grain graph into a proper one. This backtracking algorithm runs only on the root process which is the only processor that contains the complete global grain graph. When a pair of grains are located that are in close proximity Figure 1 and Figure 2, one of them is arbitrarily chosen and designated as the "target" grain indicating that we seek to remap its defining variable values to a different solution variable. Depending on the number of neighbors a graph has and the variables representing each of those neighbors, it may or may not be possible to create a valid graph by remapping only the target grain. In this case a depth-limited, depth-first search is performed seeking a series of neighbor swaps to leave the graph in a valid state.

To begin, an array of lists of size is built and populated, where is the number of variables (colors) in use. For each variable the nearest grain represented by that variable (as determined by the bounding box distance) is located and its distance is stored in the list at the corresponding array position along with the grain ID itself. In cases where the nearest bounding boxes for a given variable overlap the target grain, we maintain a negative count representing the total number of overlaps and the ID of each grain which overlaps. Otherwise we store the closest bounding box edge to bounding box edge distance for the given variable. We don't bother to calculate or store any information for grains with matching variable indices, or for grains that live on a reserved order parameter since those variables are ineligible for remapping. If there are any empty order parameters (an order parameter representing zero grains), a distance of infinity () is entered into the corresponding position prioritizing those variables for remapping. This color distance'' array is then sorted in reverse order putting the grains furthest away near the front and leaving those with several overlaps near the back.

Figure 3: Distance check against "B" Features.

Figure 4: Distance check against "C" Features.

Figure 5: Distance check against "D" Features.

Table 1: Large Red Distances

VariableDistance
A
B-2.0
C-1.0
D-3.0

A case with all negative distances is illustrated in Table 1. In this example, the target grain is chosen as the large grain labeled , centered on the right side of the image. All of the other colors have at least one bounding box that overlaps the large grain: 2 for , 1 for , and 3 for . The empty list () is used for the variable represented by the target grain to ensure that the same variable is never considered as a possible remapping option.

Figure 6: Distance check against "A" Features.

Figure 7: Distance check against "B" Features.

Figure 8: Distance check against "D" Features.

Table 2: Small light blue distances

VariableDistance
A52.6
B4.2
C
D-1.0

We iterate over the array of distances looking for available variables suitable for remapping the target grain. If a positive value is encountered, the grain can be immediately remapped and the algorithm returns "success". If however a negative value is encountered, we must first perform a fine-level check on each of the corresponding grain halos to see if these grains actually overlap. If they do not, we can immediately remap the target grain and return "success". If we encounter a case where there is only a single truly overlapping grain (bounding boxes and halos intersect), the algorithm tentatively marks the target grain with the other grain's variable effectively simulating a remapping operation. It then recurses on the other neighboring grain making it the new target. If the algorithm is able to find a successful remap in the recursive call, the returned "success" value indicates to the caller that the tentative mark can be removed. The "success" value can then be propagated on up the call stack. If all items in the "color distance" array are exhausted without finding a successful swap or set of swaps, the algorithm returns "fail". If we are in a recursive call, the tentative mark is removed and the next value in the array is inspected. We find that limiting the depth-first search to a relatively small depth (2 or 3) works reasonably well to fail out of impossibly tightly colored graphs faster. This also helps avoid the huge runtime penalty and exponential growth rate possible with an unlimited backtracking algorithm. Note: Tentative markings are indicated by turning on the DIRTY status flag in the feature's data structure. The DIRTY status uses an independent bit so it can exist simultaneously with another status.

Figure 9: Ready to remap.

Figure 10: Remap to "A".

Figure 11: Remap to "C".

3D Halo Images

Figure 12: 6000 grains in 3D

Figure 13: grain structure after several simulation steps.

Description and Syntax

Grain Tracker object for running reduced order parameter simulations without grain coalescence.

Input Parameters

  • variableArray of coupled variables

    C++ Type:std::vector<VariableName>

    Controllable:No

    Description:Array of coupled variables

Required Parameters

  • bound_value0Absolute value of the lower bound for the variable value that represents a region not assigned to the grain. Must be positive, but the actual value used is -bound_value.

    Default:0

    C++ Type:double

    Controllable:No

    Description:Absolute value of the lower bound for the variable value that represents a region not assigned to the grain. Must be positive, but the actual value used is -bound_value.

  • boundaryThe list of boundaries (ids or names) from the mesh where this object applies

    C++ Type:std::vector<BoundaryName>

    Controllable:No

    Description:The list of boundaries (ids or names) from the mesh where this object applies

  • compute_halo_mapsFalseInstruct the Postprocessor to communicate proper halo information to all ranks

    Default:False

    C++ Type:bool

    Controllable:No

    Description:Instruct the Postprocessor to communicate proper halo information to all ranks

  • compute_var_to_feature_mapFalseInstruct the Postprocessor to compute the active vars to features map

    Default:False

    C++ Type:bool

    Controllable:No

    Description:Instruct the Postprocessor to compute the active vars to features map

  • connecting_threshold0.09The threshold for which an existing feature may be extended (defaults to "threshold")

    Default:0.09

    C++ Type:double

    Controllable:No

    Description:The threshold for which an existing feature may be extended (defaults to "threshold")

  • enable_var_coloringTrueInstruct the Postprocessor to populate the variable index map.

    Default:True

    C++ Type:bool

    Controllable:No

    Description:Instruct the Postprocessor to populate the variable index map.

  • error_on_grain_creationFalseTerminate with an error if a grain is created (does not include initial callback to start simulation)

    Default:False

    C++ Type:bool

    Controllable:No

    Description:Terminate with an error if a grain is created (does not include initial callback to start simulation)

  • execute_onINITIAL TIMESTEP_ENDThe list of flag(s) indicating when this object should be executed, the available options include FORWARD, ADJOINT, HOMOGENEOUS_FORWARD, ADJOINT_TIMESTEP_BEGIN, ADJOINT_TIMESTEP_END, NONE, INITIAL, LINEAR, NONLINEAR, POSTCHECK, TIMESTEP_END, TIMESTEP_BEGIN, MULTIAPP_FIXED_POINT_END, MULTIAPP_FIXED_POINT_BEGIN, FINAL, CUSTOM.

    Default:INITIAL TIMESTEP_END

    C++ Type:ExecFlagEnum

    Options:FORWARD, ADJOINT, HOMOGENEOUS_FORWARD, ADJOINT_TIMESTEP_BEGIN, ADJOINT_TIMESTEP_END, NONE, INITIAL, LINEAR, NONLINEAR, POSTCHECK, TIMESTEP_END, TIMESTEP_BEGIN, MULTIAPP_FIXED_POINT_END, MULTIAPP_FIXED_POINT_BEGIN, FINAL, CUSTOM, TRANSFER

    Controllable:No

    Description:The list of flag(s) indicating when this object should be executed, the available options include FORWARD, ADJOINT, HOMOGENEOUS_FORWARD, ADJOINT_TIMESTEP_BEGIN, ADJOINT_TIMESTEP_END, NONE, INITIAL, LINEAR, NONLINEAR, POSTCHECK, TIMESTEP_END, TIMESTEP_BEGIN, MULTIAPP_FIXED_POINT_END, MULTIAPP_FIXED_POINT_BEGIN, FINAL, CUSTOM.

  • flood_entity_typeELEMENTALDetermines whether the flood algorithm runs on nodes or elements

    Default:ELEMENTAL

    C++ Type:MooseEnum

    Options:NODAL, ELEMENTAL

    Controllable:No

    Description:Determines whether the flood algorithm runs on nodes or elements

  • halo_level2The thickness of the halo surrounding each feature.

    Default:2

    C++ Type:unsigned short

    Controllable:No

    Description:The thickness of the halo surrounding each feature.

  • op_numArray of coupled variables (num_name)

    C++ Type:unsigned int

    Controllable:No

    Description:Array of coupled variables (num_name)

  • polycrystal_ic_uoOptional: Polycrystal IC object

    C++ Type:UserObjectName

    Controllable:No

    Description:Optional: Polycrystal IC object

  • prop_getter_suffixAn optional suffix parameter that can be appended to any attempt to retrieve/get material properties. The suffix will be prepended with a '_' character.

    C++ Type:MaterialPropertyName

    Controllable:No

    Description:An optional suffix parameter that can be appended to any attempt to retrieve/get material properties. The suffix will be prepended with a '_' character.

  • remap_grainsTrueIndicates whether remapping should be done or not (default: true)

    Default:True

    C++ Type:bool

    Controllable:No

    Description:Indicates whether remapping should be done or not (default: true)

  • reserve_op0Indicates the number of reserved ops (variables that cannot be remapped to)

    Default:0

    C++ Type:unsigned short

    Controllable:No

    Description:Indicates the number of reserved ops (variables that cannot be remapped to)

  • reserve_op_threshold0.95Threshold for locating a new feature on the reserved op variable(s)

    Default:0.95

    C++ Type:double

    Controllable:No

    Description:Threshold for locating a new feature on the reserved op variable(s)

  • secondary_percolation_boundariesPaired boundaries with "primaryary_percolation_boundaries" parameter

    C++ Type:std::vector<BoundaryName>

    Controllable:No

    Description:Paired boundaries with "primaryary_percolation_boundaries" parameter

  • specified_boundariesAn optional list of boundaries; if supplied, each feature is checked to determine whether it intersects any of the specified boundaries in this list.

    C++ Type:std::vector<BoundaryName>

    Controllable:No

    Description:An optional list of boundaries; if supplied, each feature is checked to determine whether it intersects any of the specified boundaries in this list.

  • threshold0.1The threshold value for which a new feature may be started

    Default:0.1

    C++ Type:double

    Controllable:No

    Description:The threshold value for which a new feature may be started

  • tracking_step0The timestep for when we should start tracking grains

    Default:0

    C++ Type:int

    Controllable:No

    Description:The timestep for when we should start tracking grains

  • use_interpolated_stateFalseFor the old and older state use projected material properties interpolated at the quadrature points. To set up projection use the ProjectedStatefulMaterialStorageAction.

    Default:False

    C++ Type:bool

    Controllable:No

    Description:For the old and older state use projected material properties interpolated at the quadrature points. To set up projection use the ProjectedStatefulMaterialStorageAction.

  • use_less_than_threshold_comparisonTrueControls whether features are defined to be less than or greater than the threshold value.

    Default:True

    C++ Type:bool

    Controllable:No

    Description:Controls whether features are defined to be less than or greater than the threshold value.

  • var_name_baseArray of coupled variables (base_name)

    C++ Type:std::string

    Controllable:No

    Description:Array of coupled variables (base_name)

  • verbosity_level1Level 0: Silent during normal operation, Level 1: Informational messages but no detailed grain structure printouts, Level 2: Verbose output including data structure dumps, Level 3: Debugging mode.

    Default:1

    C++ Type:short

    Controllable:No

    Description:Level 0: Silent during normal operation, Level 1: Informational messages but no detailed grain structure printouts, Level 2: Verbose output including data structure dumps, Level 3: Debugging mode.

Optional Parameters

  • allow_duplicate_execution_on_initialFalseIn the case where this UserObject is depended upon by an initial condition, allow it to be executed twice during the initial setup (once before the IC and again after mesh adaptivity (if applicable).

    Default:False

    C++ Type:bool

    Controllable:No

    Description:In the case where this UserObject is depended upon by an initial condition, allow it to be executed twice during the initial setup (once before the IC and again after mesh adaptivity (if applicable).

  • condense_map_infoTrueDetermines whether we condense all the node values when in multimap mode (default: false)

    Default:True

    C++ Type:bool

    Controllable:No

    Description:Determines whether we condense all the node values when in multimap mode (default: false)

  • control_tagsAdds user-defined labels for accessing object parameters via control logic.

    C++ Type:std::vector<std::string>

    Controllable:No

    Description:Adds user-defined labels for accessing object parameters via control logic.

  • enableTrueSet the enabled status of the MooseObject.

    Default:True

    C++ Type:bool

    Controllable:Yes

    Description:Set the enabled status of the MooseObject.

  • execution_order_group0Execution order groups are executed in increasing order (e.g., the lowest number is executed first). Note that negative group numbers may be used to execute groups before the default (0) group. Please refer to the user object documentation for ordering of user object execution within a group.

    Default:0

    C++ Type:int

    Controllable:No

    Description:Execution order groups are executed in increasing order (e.g., the lowest number is executed first). Note that negative group numbers may be used to execute groups before the default (0) group. Please refer to the user object documentation for ordering of user object execution within a group.

  • force_postauxFalseForces the UserObject to be executed in POSTAUX

    Default:False

    C++ Type:bool

    Controllable:No

    Description:Forces the UserObject to be executed in POSTAUX

  • force_preauxFalseForces the UserObject to be executed in PREAUX

    Default:False

    C++ Type:bool

    Controllable:No

    Description:Forces the UserObject to be executed in PREAUX

  • force_preicFalseForces the UserObject to be executed in PREIC during initial setup

    Default:False

    C++ Type:bool

    Controllable:No

    Description:Forces the UserObject to be executed in PREIC during initial setup

  • max_remap_recursion_depth6The recursion depth allowed when searching for remapping candidates. Note: Setting this value high may result in very computationally expensive searches with little benefit. (Recommended level: 6)

    Default:6

    C++ Type:unsigned short

    Controllable:No

    Description:The recursion depth allowed when searching for remapping candidates. Note: Setting this value high may result in very computationally expensive searches with little benefit. (Recommended level: 6)

  • outputsVector of output names where you would like to restrict the output of variables(s) associated with this object

    C++ Type:std::vector<OutputName>

    Controllable:No

    Description:Vector of output names where you would like to restrict the output of variables(s) associated with this object

  • primary_percolation_boundariesA list of boundaries used in conjunction with the corresponding "secondary_percolation_boundaries" parameter for determining if a feature creates a path connecting any pair of boundaries

    C++ Type:std::vector<BoundaryName>

    Controllable:No

    Description:A list of boundaries used in conjunction with the corresponding "secondary_percolation_boundaries" parameter for determining if a feature creates a path connecting any pair of boundaries

  • tolerate_failureFalseAllow the grain tracker to continue when it fails to find suitable grains for remapping. This will allow the simulation to continue but it will also allow non-physical grain coalescence. DO NOT USE for production results!

    Default:False

    C++ Type:bool

    Controllable:No

    Description:Allow the grain tracker to continue when it fails to find suitable grains for remapping. This will allow the simulation to continue but it will also allow non-physical grain coalescence. DO NOT USE for production results!

  • use_displaced_meshFalseWhether or not this object should use the displaced mesh for computation. Note that in the case this is true but no displacements are provided in the Mesh block the undisplaced mesh will still be used.

    Default:False

    C++ Type:bool

    Controllable:No

    Description:Whether or not this object should use the displaced mesh for computation. Note that in the case this is true but no displacements are provided in the Mesh block the undisplaced mesh will still be used.

  • use_global_numberingTrueDetermine whether or not global numbers are used to label features on multiple maps (default: true)

    Default:True

    C++ Type:bool

    Controllable:No

    Description:Determine whether or not global numbers are used to label features on multiple maps (default: true)

  • use_single_mapFalseDetermine whether information is tracked per coupled variable or consolidated into one (default: true)

    Default:False

    C++ Type:bool

    Controllable:No

    Description:Determine whether information is tracked per coupled variable or consolidated into one (default: true)

Advanced Parameters

Input Files

Child Objects