# 2.3. Input Commands

There are several input commands that are relevant to RVEs. In the reference region, these commands include a special RVE material model and commands to define and use a local coordinate system along which an associated RVE will be aligned. In addition to the reference region, an RVE region is needed using the `BEGIN RVE REGION` command block. The RVE region command block uses the same nested commands as any other Sierra/SM region (with some restrictions as explained in this section) and an additional line command that relates the RVEs to their parent elements in the reference region.

## 2.3.1. RVE Material Model

In an RVE analysis, any elements of the reference mesh that use an RVE must use the RVE material model. This model is defined similar to other material models as described in the Sierra/SM User Manual but uses the RVE keyword on the `BEGIN PARAMETERS FOR MODEL` command line as follows:

    BEGIN MATERIAL <string>mat_name
      #
      DENSITY = <real>density_value
      #
      BEGIN PARAMETERS FOR MODEL RVE
        YOUNGS MODULUS = <real>youngs_modulus
        POISSONS RATIO = <real>poissons_ratio
      END PARAMETERS FOR MODEL RVE
      #
    END [MATERIAL <string>mat_name]

Currently, the RVE material model tells the reference element not to perform a constitutive evaluation but to instead accept the stress tensor obtained from computation on an RVE. However, the use of an RVE material model still requires the input of Young’s modulus and Poissons ratio. These values may be used for time step estimation and hourglass computations, even though they are not used in a constitutive evaluation.

Element blocks in the RVE region can use any material model that is supported in Sierra/SM other than RVE.

## 2.3.2. Embedded Coordinate System

The finite element model of an element block in the reference mesh that uses RVEs can use an embedded coordinate system to orient the RVE relative to the reference element, if the reference elements are uniform gradient hexes. A coordinate system is defined in the sierra scope as described in the Sierra/SM User Manual. A local coordinate system is then associated with an element block through the use of a `COORDINATE SYSTEM` command line within a `BEGIN SOLID SECTION` command block.

    BEGIN SOLID SECTION <string>section_name
      #
      COORDINATE SYSTEM = <string>coord_sys_name
      #
    END [SOLID SECTION <string>section_name]

The string `coord_sys_name` must be a name associated in the input file with one of the `COORDINATE SYSTEM` command blocks in the sierra scope. This coordinate system will then be used on all elements of a block associated with a `BEGIN PARAMETERS FOR BLOCK` command block that includes the command line specifying this solid section.

Known Issue

Currently, the rotation of RVEs to a local element block coordinate system only works with uniform gradient hexes in the reference mesh.

## 2.3.3. RVE Region

A representative volume element (RVE) region must be a quasistatic region specified with the RVE keyword in the `BEGIN RVE REGION` command line. The RVE region uses the same block commands and line commands as any other quasistatic region with the addition of line commands that define which element blocks of the reference region are associated with RVEs. There are also some restrictions on boundary conditions as described in Section 2.3.6.

    BEGIN RVE REGION <string>rve_region_name
       #
       # Definition of RVEs
       ELEMENTS <integer>elem_i:<integer>elem_j
         <integer>num_intg_pts_per_elem
         BLOCKS <integer>blk_i:<integer>blk_j
         SURFACE|NODESET <integer> start_id INCREMENT
                   <integer> k
       #
       # Boundary Conditions
       #
       # Results Output Definition
       #
       # Solver Definition
       #
    END [RVE REGION <string>rve_region_name]

## 2.3.4. Definition of RVEs

One or more `ELEMENTS` command lines are used to associate elements of the reference region mesh with RVEs in the RVE region. In the

    ELEMENTS <integer>elem_i:<integer>elem_j
      <integer>num_intg_pts_per_elem
      BLOCKS <integer>blk_i:<integer>blk_j
      SURFACE|NODESET <integer>start_id INCREMENT
                      <integer>incr

command line, elements numbered `elem_i` through `elem_j` of the reference mesh and their `num_intg_pts_per_elem` integration points will be associated with RVEs (for a total number of RVEs equal to (`elem_j` - `elem_i` + 1) * `num_intg_pts_per_elem`), and each RVE will consist of `blk_i` - `blk_j` + 1 element blocks. Each integration point will be associated with a separate RVE. The block IDs of the first RVE must be `blk_i` through `blk_j` and subsequent RVEs (if `elem_j` is greater than `elem_i` or `num_intg_pts_per_elem` is greater than 1) must have consecutively increasing numbers for their block IDs.

Similarly `start_id` gives the `surface_id` of the first RVE if a single, encompassing surface is used, or the first `surface_id` or `nodelist_id` of the first RVE (the positive x surface as explained in Section 2.2) if six individual sidesets/nodeset are used. The remaining surfaces (nodesets) of the first RVE and all the surfaces of the following RVEs must be consecutively numbered following `start_id` in the mesh file as explained in Section 2.2.

The increment value `incr` indicates the number of sidesets present on the exterior of the RVEs. This is used to determine how to increment the IDs of the sidesets from one RVE to the next and to determine how to prescribe periodic boundary conditions on the RVE. The increment can have a value of either one or six. A value of one indicates that each RVE has one sideset that encompasses all six faces, while a value of six specifies that six sidesets or nodesets are present, one on each face. Nodesets are not allowed for the case where `incr` is one.

The following example shows the use of the `ELEMENTS` command line:

    elements 1:5 1 blocks 1:2 surface 7 increment 6
    elements 6:6 1 blocks 11:14 nodeset 15 increment 6

These commands generate the RVEs shown in Fig. 2.2.1.

The first `ELEMENTS` command line specifies that elements with element IDs 1 through 5 in the parent region mesh each have one integration point and that each integration point has an RVE with two element blocks. The RVE associated with the integration point of element 1 of the parent region will have two element blocks starting with `block_id` of 1 and ending with a `block_id` of 2. Subsequent RVEs will have consecutively numbered element blocks. For example: the integration point of parent element 2 will be associated with an RVE that consists of element blocks 3 and 4 in the RVE region, the integration point of parent element 3 will be associated with the RVE that has element blocks 5 and 6, etc. Again, this is the case for the first five elements of the parent region mesh. The keyword `SURFACE` specifies that all the periodic boundary conditions generated by the code for the RVEs for elements 1 to 5 will use sidesets in the RVE region mesh. These sidesets will start with id 7 for the positive-x face of the RVE associated with parent element 1 and continue consecutively for the other faces of the RVE and the RVEs associated with the integration points of parent elements 2 through 5 (in the order specified in Section 2.2). In other words, the positive-x face of the RVE for parent element 1 is sideset 7, negative-x is sideset 8, positive-y is sideset 9, negative-y is sideset 10, positive-z is sideset 11, and negative-z is sideset 12. The sidesets for the RVE for parent element 2 will start with id 13 and continue consecutively in the same face order. The process continues for all five RVEs specified in this command line.

The second `ELEMENTS` line specifies that the integration point of element 6 of the parent region mesh will be associated with the RVE that consists of element blocks 11, 12, 13, and 14. The `NODESET` keyword says this RVE has a nodeset associated with each face of the RVE, starting with nodeset id 15 on the positive-x face, with id’s increasing consecutively for the other five faces in the same order described in the paragraph above.

The six elements specified in these command lines must be in element blocks of the reference region mesh that use the RVE material model.

## 2.3.5. Multi-Point Constraints

In the case in which the RVE has non matching surfaces, and therefore includes a block of membrane elements on the exterior surfaces, the user must specify a set of multi-point constraints (MPCs) to tie the membranes to the surface. This is done in the input file through use of an `MPC` command block:

    RESOLVE MULTIPLE MPCS = ERROR
    BEGIN TIED MPC
      TIED FACES = <string>membrane_surface_id
      TIED NODES = <string>RVE_surface_id
      SEARCH TOLERANCE = <real>tolerance
    END

In this case, the `membrane_surface_id` corresponds to the single sideset that encompasses the membrane block is the side-a surface and the single sideset that encompasses the exterior surfaces of the RVE is the side-b surface. While the underlying RVE may have non matching exterior surfaces, the opposing surfaces of the membrane block must have matching discretizations. More detailed information on the use of MPCs, is discussed in the Sierra/SM User Manual.

## 2.3.6. RVE Boundary Conditions

Strain rates computed by elements in the reference region are applied through periodic prescribed velocity boundary conditions on the faces of the associated RVEs. These are generated internally by Sierra/SM so the periodic boundary conditions do not need to be in the user’s input file. However, because the RVE region is quasistatic, each of the RVEs must be fixed against rigid body motion. This must be done in the input file through use of the prescribed velocity boundary conditions:

    BEGIN PRESCRIBED VELOCITY pres_vel_name
      NODE SET = <string>nodelist_name
      FUNCTION = <string>function_name
      SCALE FACTOR = <real>scale_factor
      COMPONENT = <string>X|Y|Z
    END [PRESCRIBED VELOCITY pres_vel_name]

This type of boundary condition is described in detail in the Sierra/SM User Manual but the use for RVEs is restricted- Either the function must always evaluate to 0.0 or the `scale_factor` must have a value of 0. This is essentially a way of using the prescribed velocity boundary condition to fix the nodes in `nodelist_name`. However, in order for these conditions to work with the periodic boundary conditions used to apply the strain rate, `PRESCRIBED VELOCITY` must be used rather than `FIXED DISPLACEMENT` or `PRESCRIBED DISPLACEMENT` boundary conditions.

Generally, three `BEGIN PRESCRIBED VELOCITY` command blocks will be needed, one each for X, Y, and Z components. In order to eliminate rigid body motion without over constraining the motion, each `BEGIN PRESCRIBED VELOCITY` block should constrain exactly one node of an RVE in one component direction. (However, `nodelist_name` may contain nodes from multiple RVEs. Separate boundary condition blocks are not required for each RVE.). To prevent rigid body rotations, the three constrained nodes on each RVE should not be collinear.