See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/355469611

Technical Note # 1 Rezone code example for a seismic analysis simulation of an

embankment dam Technical Note #1 version: 1.0 Associated with the guidebook:
"Introductory guidebook...

Article · October 2021

CITATIONS READS
0 487

1 author:

Navead Jensen
Reclamation
5 PUBLICATIONS   2 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Lower San Fernando Dam seismic evaluation (including FLAC analysis) View project

Large deformation analysis of embankment dams using FLAC2D View project

All content following this page was uploaded by Navead Jensen on 21 October 2021.

The user has requested enhancement of the downloaded file.

Technical Note # 1
Rezone code example for a seismic
analysis simulation of an embankment
dam
By: Navead Jensen, Geotechnical Engineer

Date: 10/20/2021

Technical Note #1 version: 1.0

Associated with the guidebook:
“Introductory guidebook to FLAC and FISH code for geotechnical analysis”
(version 1.0).

i
ii
Table of contents
I. Introduction ............................................................................................................................................... 7
A. General introduction information ........................................................................................................ 7
B. Model used for rezone example ........................................................................................................... 7
C. Educational purposes only .................................................................................................................... 7
II. Bad geometry errors, blow-ups, re-meshing, and rezoning ..................................................................... 7
A. “Bad geometry errors” and associated problems ................................................................................ 7
B. Element blow-ups ................................................................................................................................. 9
C. Extremely distorted elements .............................................................................................................. 9
III. General information on rezoning............................................................................................................. 9
IV. The rezone window ............................................................................................................................... 10
V. Rezoning example using “Model 1” ........................................................................................................ 11
A. General information for rezoning example using “Model 1” ............................................................. 11
B. Additional code added to the main code-file ..................................................................................... 13
C. Initial set up and variables required for rezoning ............................................................................... 13
D. Storing the original mesh coordinates ............................................................................................... 15
E. Rezoning functions and the mesh recreation function ....................................................................... 16
F. Using the rezone functions ................................................................................................................. 20
1. “Manual” use of the rezoning functionality.................................................................................... 20
2. Automated and multiple rezone functionality................................................................................ 22
G. Issues related to using the rezoning functionality ............................................................................. 22
3. Extreme distortion or _rezone function leading to a blow-up .......... Error! Bookmark not defined.
References .................................................................................................................................................. 24

iii
iv
List of Figures
Figure number Page number

Figure 1: Quadrilateral and triangular zones and subzones (a, b, c, and d) in FLAC (figure from [2]). ......... 8
Figure 2: Left: Example of an element blow-up. Right: Example of an extremely distorted element. ....... 8
Figure 3: Variable mapping that occurs in the rezone function, from [4]. ................................................. 10
Figure 4: The rezone window. Only elements inside the window will be rezoned. .................................. 11
Figure 5: Geometry for Model 1 with the x and y coordinates in feet, from Appendix A in the FLAC
guidebook version 1.0 [1]. .......................................................................................................................... 12
Figure 6: Initial configurations for Model 1 when using the rezone functionality. .................................... 13
Figure 7: Function assigning required variables for the rezoning functions to work properly. ................. 14
Figure 8: Rezone window for Model 1 from Appendix A in the FLAC guidebook version 1.0 [1]. ............. 14
Figure 9: Functions to store the x and y coordinates of the initial mesh before any table generation
occurs. ......................................................................................................................................................... 15
Figure 10: Horizontal and vertical distances stored in the “orig_xy” array in the “store_orig_xy” function.
.................................................................................................................................................................... 16
Figure 11: Rezoning function called jensen_rezone, controls parameters about the rezoning process. .. 17
Figure 12: User-defined function used to create the new mesh during a rezoning process...................... 19
Figure 13: Before (top) and after (bottom) the rezoning functions were executed on Model 1 from
Appendix A at 8.3 seconds. ......................................................................................................................... 21

v
vi
I. Introduction
A. General introduction information

This technical note documents the FLAC commands and FISH functions that can be used to “rezone” a
FLAC mesh during dynamic loading. The following assumes the reader has read and understood the
associated main text titled “Introductory guidebook to FLAC and FISH code for geotechnical analysis” [1]
and Appendix A of that text. If not, the reader can refer to the main guidebook and appendix when
necessary. Note that the term FLAC zone, zone, and element are used interchangeably in this
document.

When running a FLAC simulation, skewed or distorted elements (FLAC zones) can cause FLAC to end the
simulation early. This usually manifests in FLAC producing a “bad geometry error” and stops the
simulation from reaching equilibrium. When this occurs because of a distorted element then the user
can take action to reconfigure the geometry of the offending element. This action is sometimes referred
to as “rezoning” (or remeshing). Rezoning can be performed using several methods; one method is to
make use of the internal rezone function that is native to FLAC. There are some issues associated with
using the rezone function that can impact the analysis; therefore, it is prudent to at least recognize that
the rezoning scheme is probably not modeling reality as close as some may hope.

B. Model used for rezone example

The rezone functionality discussed in this document is tailored to a specific dynamic simulation for an
embankment dam detailed in Appendix A (version 1.0) from the document titled “Introductory
guidebook to FLAC and FISH code for geotechnical analysis” [1]. The specific model that is focused on is
“Model 1”. Model 1 uses the Mohr-Coulomb (MC) soil model during static and dynamic loading. Model
1 is considered a drained analysis during static loading and a pseudo-drained analysis during dynamic
loading. This means that excess pore pressure generation does not occur during dynamic loading within
FLAC. Instead, the soil strength response in key areas is accounted for and controlled by direct user
input. For example, assigning a low-strength cohesion and zero friction angle at a specified time to a
“problem soil”.

C. Educational purposes only

The information in this Technical Note and the associated guidebook and appendix is for educational
purposes only. The author of this document takes no responsibility nor liability in any design or analysis
that is based on this document or any associated documents.

II. Bad geometry errors, blow-ups, re-meshing, and rezoning

A. “Bad geometry errors” and associated problems

FLAC zones are quadrilateral. Each quadrilateral element can be divided into 4 triangular subzones
shown as triangles a, b, c, and d in the figure below.

7
Figure 1: Quadrilateral and triangular zones and subzones (a, b, c, and d) in FLAC (figure from [2]).

A ratio referred to as the “geometry ratio” in this document can be made by a subzone area divided by
the total area of an element. Bad geometry errors occur during FLAC simulations when the geometry
ratio for both pairs of subzones is less than a predetermined limit due to a change in shape. The default
limit is 0.19. When the geometry ratio limit is reached during a simulation, a “bad geom error” (bad
geometry error) will occur and the simulation will be halted. The bad geometry error shows in the Echo
pane in the giic window. An error or warning message may pop up in a window vaguely explaining the
nature of the error.

The geometry ratio can be set to a value higher than the default of 0.19, which will usually cause the bad
geometry error to occur at a different distortion level and/or dynamic time during the run. The
geometry ratio limit can be set by using the FLAC command set geom value, where value is an integer
input by the user. For example, to set the limit at 0.27 the command would be: set geom 0.27. Also,
the variable badgeomrat is a built-in FISH variable that FLAC keeps track of in the background of any
run. This variable tracks the smallest geometry ratio that exists in the model.

Bad geometry errors are responses to elements straining due to two reasons, element blow-ups or
extremely distorted elements with no associated blow-up. An example of each is shown in the figure
below.

Extremely distorted elements,

with no associated blow-up.

Element blow-up

Figure 2: Left: Example of an element blow-up. Right: Example of an extremely distorted element.

8
B. Element blow-ups

Although not the focus of this technical note, element blow-ups are briefly discussed in this section.
Note that the rezone functionality will not stop an element blow-up.

Element blow-ups usually occur on the surface elements and result in the elements unrealistically
moving upwards at a very fast rate. An element blow-up is considered a numerical instability where the
velocities that are being assigned to the element are not a result of naturally occurring deformation;
velocities can be on the order of 1 to 1,000 feet per second.

The reasons that explain why element blow-ups occur are not exactly known by the author, despite
many conversations with other industry participants through the years. One theory is that blow-ups
occur when FLAC expects one set of conditions based on the initial inputs, but those conditions are not
met during dynamic loading. For example, if the simulation uses the config gwflow option, then FLAC
expects that excess pore pressure generation will occur during dynamic loading. However, if the bulk
modulus of water is set to 0 during dynamic loading, then excess pore pressure generation will not occur
which may cause blow-ups. Another example is if the config gwflow option is not used at all in the run.
This will make FLAC not expect any pore pressure to exist during dynamic loading, but if pore pressure is
present during shaking (even just hydrostatic pressure), then the expectation is not met and blow-ups
will occur. Usually the blow-up doesn’t manifest unless a combination of large deformations and/or
strong shaking exists. Element blow-ups are much less common if a coupled analysis is used where a
realistic value of the bulk modulus of water is used during loading when the config gwflow command is
used, or if there is no pore pressure present if the config gwflow command isn’t used. More
information on these types of analyses can be found in Itasca’s Fluid-Mechanical interaction manual [3].

C. Extremely distorted elements

The rezone function can help resolve the issue created when elements become distorted. Extremely
distorted elements with no associated blow-up are usually located where the strain concentrations
occur in the model, most often where the slip surface is located as shown in the right part of Figure 2
above. Bad geometry errors in this situation usually occur when strains are on the order of 100% or
more. When a bad geometry error is encountered during a run the simulation is stopped. Two
approaches to reshape elements to acceptable geometries after a bad geometry error has occurred are
to either use the rezone function or to manually remesh particular elements using mouse-action to
navigate to the Alter->Shape menu in the graphical interface. Using the Alter->Shape approach can be
useful, but isn’t recommended for most cases.

III. General information on rezoning

As discussed above, the rezone function can be beneficial for extremely distorted elements that are not
associated with an element blow-up. The rezone function is a native function that is built into the FLAC
internal code. The essence of the function is to map properties from one mesh to another that exist in
the same two-dimensional (2D) space. The function does this by first capturing and storing parameters
associated with a pre-rezone mesh, followed by assigning those properties to a different set of elements

9
with different geometry in the same space in a post-rezone mesh. The process is conceptually depicted
in the figure below.

Solid = old mesh

Dashed = new mesh

Figure 3: Variable mapping that occurs in the rezone function, from [4].

Unfortunately, FLAC doesn’t automatically create the new mesh to which the stored properties from the
original mesh will be assigned. This must be done by the user. Details of one such function is the
primary topic of this document.

When the rezone function maps the variables from the old mesh to the new mesh there is some
property “smearing” that occurs where the properties of adjacent elements may be averaged together
in some manner. For example, if two adjacent elements have a 30° and 32° friction angle before the
rezone then the friction angles may be something similar to 30.1 and 31.9 degrees after the rezone. The
extent of property averaging can be more or less than what is discussed here and, in some cases, can be
substantial. The properties can be checked before and after a rezone to identify the magnitude of the
issue. Property averaging is a known issue and should be considered when using the rezone function
and weighed against potential benefits.

IV. The rezone window

One of the inputs into the rezone function is the extents to which the rezoning of the mesh will occur.
An entire mesh can be rezoned or just a portion of the mesh. In the example discussed in this
document, only a portion of the mesh is rezoned and the “localized” rezoning option is used by
employing the set range command (which is discussed in greater detail below). The rezone window is a
rectangular shape of elements that designate a window that will include and exclude elements that will
be rezoned or not. If elements are within the window, then the elements are rezoned, and they are not
if they are outside of the window. A rezone window on a simplified embankment geometry is shown in
the figure below for illustrative purposes. The mesh in the figure is not the mesh used for the example
for this document.

10
 _iz1 zone Rezone window
column

_jz2

_iz2 zone
column

_jz1

_ig1 _ig2
jline (black dashed line)

Figure 4: The rezone window. Only elements inside the window will be rezoned.

There are four variables that make up the rezone window that are pointed out in the figure above.
These are _iz1, _iz2, _jz1, and _jz2. These represent the outer zones of the rezone window. The _iz1
and _iz2 are the vertical columns of zones (elements) that are on the left and right ends of the window,
respectively. The _jz1 (that uses j instead of i) and _jz2 are the horizontal columns of zones (elements)
that are on the bottom and top ends of the window, respectively. Other variables that are associated
with the rezone window but are not required by FLAC to define the window are the grid points at the
bottom left corner (_ig1) and bottom right corner (_ig2) of the window, and the jline variable along the
bottom of the window. The _ig1 and _ig2 variables are not explicitly required for the rezone function to
work, but are needed for the user defined functions discussed in this document that that reconfigure
the new mesh. Th jline variable is another variable not required by FLAC, but is also used in the user
defined functions that reconfigure the new mesh. The jline variable is the row of grid points that are at
the bottom of the rezone window, these must all have the same j value.

V. Rezoning example using “Model 1”

A. General information for rezoning example using “Model 1”

Model 1 in Appendix A in the FLAC guidebook [1] is the simulation that the following rezone example
was performed on. Recall that Model 1 is a pseudo-drained model where the config gwflow command
is used, but the bulk modulus of water is assigned a value of 0 during dynamic loading. As previously
mentioned, this approach can lead to element blow-ups; however, the approach is still used for this
example regardless. Every line of code for Model 1 will not be reviewed in detail, but certain pieces will
be discussed.

Before moving forward, it is noted that the rezoning functionality is best thought of as a collection of
commands and functions that work together to rezone the model. The rezoning functions described in
this document include the native rezone function known by FLAC and various other user-written
11
functions. Additionally, there are a variety of functions and commands that can occur before and after
the rezoning process. Some of these actions include the removal and reapplication of boundary
conditions and reservoir pressures, and the reassignment of “group numbers”. These before and after
rezoning actions are necessary to perform the rezoning process multiple times and automatically during
a dynamic run, otherwise the user would have to perform these actions by hand before and after each
rezone. The before and after functions are sometimes created out of convenience and sometimes out
of necessity. Either way they are performed because the i,j values of the elements and grid points can
change during the rezone. The change in i,j values has bearing on potential actions afterward a rezone,
such as finding the new i,j gridpoint on the upstream face where the reservoir pressure is to be
reapplied. However, these additional functions are considered beyond the scope of this document and
were not included, only the actual remeshing functionality was focused on for this example. This means
that only one rezone occurs in this example, but functions to facilitate multiple and automatic rezoning
are at least touched on throughout the discussion in this document.

To remind the reader of Model 1 from Appendix A in the FLAC guide [1], the geometry is shown in the
figure below for reference.

Figure 5: Geometry for Model 1 with the x and y coordinates in feet, from Appendix A in the FLAC guidebook version 1.0 [1].

12
B. Additional code added to the main code-file

The following four pieces of code were added to the main code-file for Model 1 from Appendix A [1] so
that the rezoning functionality would work (note that the four pieces of code were inserted into the
code-file at different locations and not all in one location).

1.) Assignment of required variables for the rezoning functions to work properly (see the
rezone_variables function).
2.) Storing the x and y coordinates of the original elements before any tables were originally generated
during mesh creation (see the store_orig_xy function).
3.) Assignment of the variables needed for the rezone function to work (see the jensen_rezone
function).
4.) Execution of the user-written set of functions needed to recreate the mesh before rezoning occurs
(see the rezone_created_by_user function).

C. Initial set up and variables required for rezoning

The initial set up for Model 1 is shown below.

Figure 6: Initial configurations for Model 1 when using the rezone functionality.

The initial configurations for Model 1 shown above are exactly the same as was shown in Appendix A of
the FLAC guidebook [1]. The next step was to assign the needed variables to be used in the rezoning
functions, this was done by executing the following function called rezone_variables shown in the figure
below.

13
Figure 7: Function assigning required variables for the rezoning functions to work properly.

It is recommended that these variables be defined as soon possible in the code-file, here they were
defined immediately after the initial configurations. Lines 30 through 33 assign the columns and rows of
elements that define the rezone window. The columns and rows of elements at the edges of the rezone
window for this model are shown in the following figure.

_jz2 = 14 (imid,jmid)
zone row

_iz2 = 35
_iz1 = 3 zone column
zone column

_jz1 = 3 jline: j=3.

zone row (dashed line)

Figure 8: Rezone window for Model 1 from Appendix A in the FLAC guidebook [1].

The jline variable assigned a value of 3 in this case on line 45 of Figure 7 is used in the function that
recreates the new mesh, the location of it is also shown in the above figure. The imid and jmid variables
assigned on lines 36 and 37 of Figure 7 are the i and j value of the coordinate that is at about the
approximate midpoint on the ground surface of the model. The _isurf and _isurf1 variables are assigned
14
table identification values on lines 41 and 42 of Figure 7. These tables are used to define the ground
surface after deformation occurs and during a rezone. The _isurf, _isurf1, imid, and jmid variables
ensure that FLAC uses the correct path (over the embankment instead of under) along the boundary grid
points when executing a few different commands and functions, as discussed later. The upst_gs,
dnst_gs, i_last, _ig1, and j_ig2 variables represent grid points in the model (see Figure 7 for
explanations) and a play a role in rezoning process. The rezone_count variable is simply a counter that
increases by 1 every time a rezone is performed. This is useful for simulations that have multiple
rezones, which is not the case in this example.

D. Storing the original mesh coordinates

After the rezone_variables function is executed, the code-file for Model 1 continues as shown in
Appendix A of the FLAC guidebook with the creation of the mesh and temporary assignment of the
elastic soil model to all of the elements. At this point in the code-file two functions required for the
rezone to perform correctly were added, the create_orig_xy_array and store_orig_xy functions. The
store_orig_xy function must be executed after the initial mesh is created, but before any tables are
generated, including before the gen table 141 command is issued. This is because the store_orig_xy
function stores the x and y coordinates of every grid point of the mesh free from any changes the gen
table command makes to the mesh. These are functions are shown in the figure below.

Figure 9: Functions to store the x and y coordinates of the initial mesh before any table generation occurs.

The create_orig_xy_array function on line 74 creates a 3D array with the appropriate i and j values for
the model. The 3D array is called orig_xy and has four “layers”, whose values are stored in the
store_orig_xy function. The first layer of the orig_xy array is for the x value of each grid point, the
second is for the y value of each grid point, the third is for the vertical distance between the grid point
that the loop is on and the grid point on the jline that has the same i grid point value. The vertical
distance for an example grid point that the loop is on is pointed out on the figure below (it is 40 feet in
the example in the figure below). The fourth layer of the array is the horizontal distance between the
grid point that the loop is on and the grid point on the jline that has the same i grid point value (this
value is 0 feet in the example in the figure below).

15
 Grid point loop is on.
<i,j> = <23,11>
(x,y) = (100,140)

Associated jline grid point:

<i,j> = <23,2>
Vertical distance: (x,y) = (100,100)
40 ft
Horizontal distance:
0 ft in this case.
jline: j-grid point = 2

Figure 10: Horizontal and vertical distances stored in the “orig_xy” array in the “store_orig_xy” function.

The information in the orig_xy array is used during the rezoning process when creating the new mesh so
that the new mesh exactly matches the location of every grid point of the original mesh relative to the
grid points on the jline. The relative location is needed because the enitre mesh (unrealistically) moves
slightly during a dynamic analysis if fixed boundary conditions are not used. The orig_xy array also
captures the different thicknesses of each element within the mesh. The new mesh could be created
based on an assigned element thickness for every element (all squares for example), but this may not be
desired for every situation. This detail is just one of many examples of how the recreation of a new
mesh could differ between users depending on a variety of factors.

E. Rezoning functions and the mesh recreation function

After the initial mesh is recorded, free of any table generations, the code-file for Model 1 continues as
shown in Appendix A of the FLAC guidebook. The next steps include inputting material properties,
running the initial static solve, setting history points, assigning the initial reservoir load and phreatic
surface, modifying moduli properties and running the final static solve, applying the dynamic boundary
conditions, and applying the earthquake loading. Immediately before simulating the dynamic load,
additional code was added in “step 10.1”. The additional code consisted of two new functions required
for the rezone to perform correctly. The first function called jensen_rezone is shown in the figure
below.

16
Figure 11: Rezoning function called jensen_rezone, controls parameters about the rezoning process.

Executing the jensen_rezone function will direct FLAC to perform the rezone (which occurs on line 377
in the above figure). The jensen_rezone function assigns various items that FLAC needs in order to
perform a successful rezone. This is also where other functions that perform actions before and after a
rezone can be included. For this example, no extra functions were included for performing actions
before and after the rezone, but some recommendations are shown in the above figure. The
rezone_count variable is increased by one on line 367. Line 368 uses the command command to allow
commands to be used inside of the FISH function. The unmark command unmarks all of the grid points
in the model. The apply remove mech commands on line 370 and 371 remove mechanical boundary
conditions from the model. If seepage boundary conditions were being used (which they are not in this
case), then the apply remove gw command could be used to remove those boundaries as well. The
upst_gs, dnst_gs, imid, jmid, and i_last variables used in the apply remove mech commands were
assigned earlier in the code-file in the rezone_variables function (Figure 7). The apply remove
command removes boundary conditions between two grid points traveling along the shortest path on
the boundary between those two points. Sometimes that shortest path is along the bottom of the
model instead of the along the top (over the embankment), which is why it is necessary to perform the
apply remove command in two pieces using the grid point at the imid and jmid coordinates to ensure
that the shortest distance is over the model on the ground surface. If multiple and automated rezones
are required during the simulation, then the imid and jmid coordinates would need to be redefined
before the next rezone occurs, preferably by writing a function and executing it somewhere below the
endcommand command, on line 380 for example.

The rez set history command on line 372 directs FLAC to track the history of grid points through
rezoning; however, this functionality is not reliable. To ensure that certain histories are tracked,
creating user-defined functions that are executed before and after the rezone command on line 377 is
recommended (this was not done for this example since multiple, automated rezones were not
performed). The rez set range command on line 373 assigns the corner elements of the rezone window
by using the variables defined in the rezone_variables function (Figure 7).

17
The rez set surface commands on lines 374 and 375 of Figure 11 define the line (table) that will be used
as the ground surface for the new mesh to be created during rezoning, which is the ground surface just
prior to rezoning. The two tables making up the ground surface in conjunction with the imid and jmid
variables are used for the same reasons discussed earlier, to ensure that FLAC uses the ground surface
that goes over the model instead of under the model. The _isurf and _isurf1 variables are assigned
identification values of 142 and 143 in the rezone_variables function in the code-file. The _isurf
variable is used to represent the line (table) from the upstream grid point to the midpoint along the
ground surface and the _isruf1 variable is used to represent the line (table) from the midpoint to
downstream grid point along the ground surface. During the rezoning process these two lines are
combined into one line using the same _isurf table value of 142 and that is why the seq 1 and seq 2 key
words are used on lines 374 and 375. Therefore, the _surf table value of 142 represents the upstream
ground surface line at certain points in the rezoning process and the entire ground surface at other
points.

The rez set meth command tells FLAC which function will be used to create the new mesh. This is a
user-defined function and can vary between users and models. The function for this example was called
rezone_created_by_user and is shown in the figure below.

18
Figure 12: User-defined function used to create the new mesh during a rezoning process.

The rezone_created_by_user function does not need to be executed since FLAC will execute it when the
jensen_rezone function is executed. The function has three parts as explained below.

When the mesh was originally created the zones above the initial ground surface were “nulled out”.
When an element is “nulled out” it is not vanquished from the model, it is just assigned what can be
thought of as a “null soil model”. This means that any null zone still exists in the model, but it is ignored
by FLAC during dynamic calculations. The first part of the rezone_created_by_user function (lines 391
to 397) reassigns a soil constitutive model (MC in this case) to the elements within the rezone window
that were previously nulled out, by making use of the if statement and the fact that the “null soil model”
is identified as model 1 (see line 393). Note that for FLAC 8.0, the constitutive model within the rezone
window must be the same, otherwise rezoning will not work. For FLAC 8.0, the rezoning functionality is
thought to only work for soil models that are built into the FLAC code (such as the MC or Finn-Byrne soil
19
models), but not for user defined models (such as pm4silt [5]) or externally created models based on
FISH files (such as the Roth model [6]). Further investigation into the compatibility of the rezoning logic
with other soil models is recommended for FLAC 8.1.

The second part of the rezone_created_by_user function (lines 401 to 408) recreates the original mesh
within the rezone window that existed before any tables were generated or null zones were nulled out,
but includes any unrealistic (and usually small) movement that the entire mesh may have seen during
the loading process when not using fixed boundaries. The unrealistic movement is accounted for so that
the relative x,y coordinates of each grid point is calculated correctly. Recreation of the original mesh is
done by looping over the grid points that are in the rezone window and above the jline. Then, the x
coordinate for each grid point above the jline is assigned a new x coordinate, which is the same x
coordinate as the grid point on the jline that has the same i coordinate. This is done using the match_x
variable on lines 402 and 405 in the above figure. The y coordinate for each grid point above the jline is
assigned the vertical distance that originally existed between the grid point being looped over and the
grid point with the same i value on the jline. This is done on lines 403 and 406 of the above figure by
making use of the orig_xy array created in the store_orig_xy function discussed earlier, and the start_y
variable defined in the rezone_variables function.

The third and final part of the rezone_created_by_user function (lines 411 through 428) defines the
current surface of the mesh and nulls out the elements above that surface. This function was modified
from a similar function found in the Theory and Background manual [4]. The first loop from lines 411 to
415 is where the tables _isurf and _isurf1 that contain the two pieces (upstream and downstream) of
the ground surface coordinates are combined into one table (_isurf) that contains all of the ground
surface coordinates (_isurf overwrites itself to become the full table). The ground surface is then
generated using the rez_exe(‘commands here’) function on line 416 (where the ‘commands here’ string
is the command to be executed, input by the user). The rez_exe() function is the only valid way to
execute commands within a user-defined mesh creating function within the rezoning logic specified by
the set method command (meaning, command/endcommand will not work here). The second loop
starting on line 417 loops through the zones in the rezone window and nulls out any zones whose
centroid is above the ground surface table by making use of the rez_exe() function again.

F. Using the rezone functions

1. “Manual” use of the rezoning functionality

The rezoning functions can be invoked “manually” by typing in the name of the function, jensen_rezone
in this case, or it can be run automatically when the geometry ratio limit is met by an element during the
simulation. In this example, none of the additional items and functions required for multiple and
automated use of the rezoning functions were included. Instead, the rezoning process was invoked
manually for Model 1 at the end of the run, or 8.3 seconds into dynamic loading. Note that the function
can be invoked manually at any time by the user if the simulation is paused or stopped; there is no need
to wait for a “bad geometry error” to occur, this holds true even when the rezoning function is set up to
be automated. The figure below shows the mesh before and after the jensen_rezone function was
manually executed at the end of the run for Model 1.

20
Figure 13: Before (top) and after (bottom) the rezoning functions were executed on Model 1 from Appendix A at 8.3 seconds.

The original ground surface is shown in both the before and after plots. The mesh in the “after” (bottom
of the above figure) plot has remeshed elements with the new ground surface that existed in the model
after deformation occurred but right before rezoning occurred.

In this example, the jensen_rezone function was executed after the solve dytime 8.3 command was ran.
The last line of code in the code-file is a print command. If after the jensen_rezone function is
executed, the continue command was manually typed into the command line on the bottom left-hand
corner of the giic window of FLAC, the simulation would go to the next line of code, the print command.
Instead, if the dynamic loading continued beyond 8.3 seconds, and next line of code was solve dytime 9
for example, then the continue command could be manually typed into the command line and the
simulation would continue. However, if this is actually done for Model 1, and the run is continued to 9
seconds of dynamic time, an upstream element blow-up occurs. This is partially due to the fact that the
reservoir pressures were not reinstated after the rezone function was executed, but mostly because this
is a pseudo-drained analysis. Since using the rezone command usually entails the use of the continue
command afterwards, and if the rezone code is set up for multiple uses (which it is not in this example),
it is recommended that the dynamic loading portion of the FLAC simulation be broken into smaller time
increments, 1 second for each solve dytime command for instance.

21
2. Automated and multiple rezone functionality

The rezoning functions can also be set up for automated use during the simulation. This is done by
uncommenting the set rez_func=function_name command (where function_name) would be the name
of the rezone function (jensen_rezone in this case). When the rezoning function is automated, the
trigger for rezoning is when an element within the mesh reaches the geometry ratio limit. The default
ratio is 0.19. If the ratio is set to a higher value, say 0.45 (by using the set geom 0.45), then the rezone
function would trigger with less strain and would triggering more often.

As previously mentioned, the example ran above was not set up for automated or multiple uses. For
multiple uses to occur, the list of functions commented out on lines 380 to 384 on Figure 11 would need
to be created, plus some other optional functions. The first of these functions is a function that would
recalculate the imid and jmid variables of the new mesh. The function called boung written and
provided by Itasca may be helpful in this type of function in order to identify grid points on the boundary
of the new mesh. A function to reapply the reservoir pressure would be required as well. When making
this function, consideration on how to handle the reservoir elevation may be needed if the crest
remnant goes below the current reservoir elevation during the simulation. Another function to
implement multiple rezone functionality, is a function to reapply any seepage related boundary
conditions that were removed before rezoning.

Note that the after plot on the bottom of Figure 13 shows some elements that have no associated
group. This is denoted by “blank” looking elements, one at the upstream toe and about seven on the
downstream face and toe. A user can tell that these blank elements were in fact rezoned correctly by
verifying that the elements have a soil model and properties. Recall that the group number for each
element was assigned in the main code-file (as explained in Appendix A [1]) by using the ini ex_1=#
group ’soil name’ command, where “#” is a stand in for an identification number for each soil.
Unfortunately, the rezone function doesn’t track group numbers defined by the extra grid variable.
Separate user-written functions would need to be written and executed before and after the rezone
function within the jensen_rezone function to store and remap the group number for the blank
elements. If this was done, then the extra variable used for the group number could be plotted to see
the group of the blank elements.

G. Issues related to using the rezoning functionality

Setting up the rezoning functionality can be useful to the FLAC user when modeling large deformations
is required. The rezoning functions allow for the continuation of the simulation beyond the point where
element distortion forces FLAC to produce the “bad geometry error”. However, the user should be
thoughtful when implementing the rezoning functionality and know the limits. Some hard limits include
that the rezone function cannot be used in axissymetry, multistepping, and FISH models. Also, no
interfaces and attaches can be within the rezone window. Additionally, only one soil model can be used
within the rezone window.

One obvious problem to consider is that FLAC is a continuum modeling scheme attempting to model a
phenomenon that is difficult to characterize as a continuum. When large failures of embankment dams
occur the soil mass will likely bifurcate through localized shear offsets or tensile separations, creating
blocks of soil mass. Sliding blocks of soil is difficult to impossible to model in FLAC regardless of if
rezoning is used.
22
Another consideration is that the rezone function will smear properties between elements. The
magnitude of this effect depends on the property difference of the adjacent zones. The magnitude of
change can be checked by the user after each rezone occurs.

Other issues that are thought to be related to the numerical code exist as well. One of these is that the
rezone function will sometimes assign a value of zero to the density or moduli of a section of elements
within the rezone window. When this happens, the elements are usually rezoned, but the properties
are not remapped correctly. Another issue that has been seen is when the rezoning functions (as shown
in this appendix) are used on a geometry that is peculiar in some manner, then the rezoning function
will not work properly remesh. This can happen if the embankment fails in such a way that the ground
surface “goes back on itself”. This can occur when the slip surface exits the through a dam face. This
can also happen in the rare instance when elements “overlap” each other during loading and FLAC does
not halt the simulation. In either case, some remeshing with mouse-action after navigating to the
Alter->Shape options may be required before performing a rezone. A common trouble-shooting
approach to use when the rezoning functions are not working is to force a rezone at a different time
during the simulation. Usually at a dynamic time that is earlier in the simulation than the time when the
rezone did not work properly. If the automated rezoning functionality is used, this can be accomplished
by making the geometry ratio larger than the default value of 0.19. If the manual rezoning approach is
followed, then restoring a .sav file before the problem-rezone is suggested, followed by an immediate
rezone.

One last issue that may appear, that may be specific to the set of rezoning functions as described in this
appendix, is when very thin elements are created on the surface of the newly rezoned mesh. The
elements that are created by FLAC are so thin that they are difficult to see unless an extreme close-up
look is performed using the graphical interface. A newly created thin zone will manifest when the newly
created mesh looks perfectly rezoned, but the timestep of the simulation is dramatically smaller, causing
the simulation to run very slowly. In this case, the thin zone will have to be located and nulled out
manually by the user before continuing the run

Given the limitations and issues that are associated with the rezone function, there will inevitably be
some FLAC practitioners that will disagree with the use of, or be wary of using the rezoning scheme
under any circumstances. This is a valid stance that this appendix does not attempt to argue.

23
 References
[1] "Introductory guidebook to FLAC and FISH code for geotechnical analysis, Version 1.0", Jensen,
Navead, February 26th, 2021.
[2] "FLAC User's Guide" Itasca Consulting Group Inc., Minneapolis, MN, 2016.
[3] "FLAC Fluid-Mechanical Interaction," Itasca Consulting Group, Inc, Minneapolis, MN, 2011..
[4] "FLAC Theory and Background", FLAC version 7.0, Itasca Consulting Group Inc., Minneapolis,
Minnesota, 2011..
[5] "PM4SILT (Version 1): A silt plasticity model for earthquake engineering applications" Boulanger, R.
W., and Ziotopoulou, K., Univ. of Cal. at Davis, Dept. of Civil & Env. Engineering, January 2018.
[6] "Updates to a Practice-Oriented Liquefaction Model", Dawson, E., M., Mejia, L., H., Goecongress
2012, conference proceedings, Oakland, California, March 25-29, 2012.

24

View publication stats