# Menus

- File Menu
- Edit Menu
- Model Input Menu
- Plot Input Menu
- Analysis Input Menu
- Solve and Cancel Solve
- Make Plot Menu
- Analysis Menu
- License Menu
- Help
- About Anaqsim

# File Menu

### Open

This selection opens a dialog that allows you to find and open existing input files (.anaq extension). These files store the data you edit under the Model Input, Plot Input, or Analysis Input menus in XML file format. XML is a common ASCII database file format. You could edit these directly with a text or XML editor, but that is not recommended since it risks corrupting input with improper values or format. When you open a file, the layout of elements in the model is drawn to the plot view.

If you want to be able to open .anaq files by double-clicking on them in Windows Explorer, in addition to opening them from the File/Open menu, the Windows operating system must associate .anaq files with Anaqsim. In case this association was not established during installation you can manually do it with Windows Explorer. To do this, locate a .anaq file in Windows Explorer. Right click on the file and then select Open with, then select Chose default program. In the dialog that pops up, check the box next to Always use the selected program to open this kind of file and then select the Browse button and browse to find the Anaqsim.exe file in the Program Files / Fitts Geosolutions / Anaqsim software directory. Now Windows will associate .anaq files with Anaqsim.exe, and you can open any .anaq file directly from Windows Explorer by double-clicking on it.

### Save, Save As

The Save As option brings up a dialog that allows you to save your input to a file with a new name. Using Save saves the input to the same file name. If you have yet to save input and have no filename, it will function like Save As. When you save, you save the input data tables to an XML format database file with the .anaq extension.

### Close

This closes the input you are working on and clears all the associated data tables in memory. After selecting Close, you may begin editing a new model.

### Save locations for Initial Transient Heads

A transient model needs initial heads so it can compute the head change that occurs during the first time step. These values are needed at the location of each basis point in each spatially-variable area sink, which account for storage fluxes. The initial head values come from a pre-existing model, which could be steady or transient. Initial heads are also retrieved for discharge-specified wells, hydrograph points, and transient line conditions (see Analysis Input Menu for the last two items).

The initial conditions model must have the same number and extent of layers as the transient model, at least in areas with basis points, wells, hydrograph points, or transient line condition lines. When the initial head locations are written, each location is identified by its x,y coordinates and its layer. This is new in release 2020-1; prior releases wrote the x,y coordinates and the internal domain number. The change made in release 2020-1 allows different domain configurations between the initial and the transient models, which can be helpful. Because of this change, you must not mix initial head location or initial head files created prior to release 2020-1 with a release 2020-1 or later model. To avoid incompatibility when you switch to release 2020-1, re-create the initial head location file and the initial heads file as outlined below using release 2020-1.

To create a transient model that has a proper set of initial heads, these steps are necessary:

- Make sure the transient model you begin to create has been saved to it's own unique file name, different from the file that contains the input for the model that will provide the initial condition heads.
- Set up the transient model (i.e. uncheck Steady under Model Input/General, establish the time step sequence under Model Input/Time Steps, adjust input for the transient case, set up all spatially-variable area sinks, make the appropriate settings under Analysis Input/Hydrograph Points and Analysis Input/Transient Line Conditions, etc.
- Select File/Save Locations for Initial Transient Heads, which saves the locations for transient starting heads from the transient model (these are the locations of all basis points associated with spatially-variable area sinks in the transient model and locations of hydrograph points, wells, and transient line conditions. This saves the level and the coordinates of each of these to a binary file with the .ihl extension.
- Close the transient model.
- Open the initial conditions model (the one that represents conditions at the start of the transient run). Solve it. Select File/Write Initial Transient Heads, click on the initial heads file you would like to use for this simulation, and click Open. This reads in the locations saved from the .ihl file saved in step 3.
- A dialog opens asking you to name the binary initial heads file. The default name is the same as the initial conditions input file but with the .hds ending. Anaqsim then writes the initial heads at the locations in the .ihl file to a binary file with the .hds file extension.
- Close the initial conditions model.
- Open the transient model. After checking that all model parameters are set correctly for the transient run, select Solve. At this point Anaqsim will ask you to select the .hds file containing the initial heads created in step 6.

When you solve the transient model, the heads are read in and used to determine the head change in the first time step at each basis point.

### Write Initial Transient Heads

See the discussion under Save Locations for Initial Transient Heads for an overview of setting up initial heads for transient models.

### Save Solution

This allows you to save the model solution after you have solved. Later, you can open the model input file, then load the saved solution, and avoid the "Solve" step. This is particularly handy for large models that have longer solve times, and allows you to save your solution and come back to it later for making plots or doing analysis of the solution. All model objects with their strengths are saved in a binary format, to a file that has the same name as the input file, but with the ".solu" filename extension instead of ".anaq".

### Load Saved Solution

This allows you to load in a previously saved model solution. To make use of this, first open the model input file for the model, then load the saved solution, which avoids the need for the "Solve" step. This is particularly handy for large models that have longer solve times, and allows you to save your solution and come back to it later for making plots or doing analysis of the solution. All model objects and their strengths are read in from a binary file that has the same name as the input file, but with the ".solu" filename extension instead of ".anaq".

### Export Input Data to Excel File

This causes the entire input database to be written to one excel file in the same directory as the input file (*.anaq), written to a file with the same name but the excel suffix (*.xlsx). The Excel file has multiple sheets, one for each data table. Each sheet contains the same headers as the data tables plus all rows of input. This is a handy way to document model inputs all in one readable file.

### Exit

This exits Anaqsim. A dialog asks if you want to save the current input before exiting. The same is achieved by clicking on the red "x" at the upper right corner of the Anaqsim window.

# Edit Menu

This is like edit menus in most other Windows applications with Cut, Copy, and Paste menu choices. These functions are also available with the usual keyboard shortcuts: control-x (cut) control -c (copy) control -v (paste).

# Model Input Menu

### General

This item has only one line of input. The first item is checked if the model is steady-state and not checked if the model is transient. To simulate storage fluxes in transient models, spatially-variable area sinks (SVAS) are required. If you try to solve a transient model without any SVAS, Anaqsim gives an error message.

The other three items are text values that document the length and time units used in the model, and provide comments to document the run. The model uses consistent length and time units throughout. For example, if you chose meters and days, then hydraulic conductivity, specific discharge, and average linear velocity are in m/day, well discharges are in m3/day, and time markers on pathlines are in days.

### Solution

The two data tables under this menu define settings involved in solving the system of equations in your model. The first defines parameters involved in solver iterations, and the second lays out the solution accuracy needed before iteration ceases.

#### Solve Settings

- Underrelaxation is a parameter that governs how unknown strength parameters are updated at each iteration. If underrelaxation is 1.0, the new strength parameter equals the parameter from the most recent iteration. If this value is 0.7, the new strength parameter is weighted 70% by the parameter at the most recent iteration and 30% by the parameter at the previous iteration. Lower values help damp out oscillations in parameter values from iteration to iteration and may improve convergence in some situations. Higher values close to 1.0 speed convergence when oscillation is not a problem. A good range for most cases is 0.9 to 1.0.
- Maximum Iterations. When solving, iteration continues until the tolerances specified in Check Settings are met at all boundary condition control points or basis points, or if those criteria are not met, iteration ceases when this maximum number of iterations is reached.
- Starting Heads. For transient runs, the first time step needs initial heads from some source. There are two possibilities here:
- Assign a constant value of head for each domain. The starting head at a point is set to the domain's average head, which is specified under Domains input. In the case of a Discharge-Specified (Multi-Domain) well, the starting head is set to the average head of the first domain listed. This option should only be used for very simple transient runs where the initial condition is a uniform, flat, constant head.
- Read initial heads from a file. This file is written by the initial (time zero) model, which is another Anaqsim model of the same area that may be steady or transient (see discussion of this file under the File menu).

- Almost_dry_fraction. This parameter affects the solution in cases with unconfined, confined/unconfined, unconfined interface, and confined interface domains, where the heads can drop to low enough levels that the freshwater saturated thickness of the domain approaches zero. Instead of letting the domain have zero or negative saturated thickness, Anaqsim has a minimum saturated thickness. In an unconfined, confined/unconfined, or unconfined interface domain, the minimum saturated thickness = (average head - base elevation) * Almost_dry_fraction. In a confined interface domain, the minimum saturated thickness = (top elevation - bottom elevation) * Almost_dry_fraction. When heads drop to or below a level that would create this minimum saturated thickness, the aquifer is treated like a confined aquifer with this fixed minimum saturated thickness. This prevents domains from actually going completely dry and helps models converge despite portions of some domains approaching "dry" conditions. Setting
- Almost_dry_fraction to a low value means that very little simulated horizontal discharge will occur in "'dry" portions of the domain. Heads in these "dry"' areas will drop to unrealistically low levels (below the base of an unconfined domain, for example), and have little real meaning. When contour plots are made of head, these unrealistically low values are neglected. These low heads do appear in other outputs such as the panel to the left of the plot and in profiles. Using higher values of Almost_dry_fraction may help convergence by limiting the magnitude of head gradients in "dry" areas, at the expense of allowing more actual discharge in "dry" areas. You can check the amount of discharge in a "dry" area by using the Analysis/Conditions Along a Line and making a profile of domain discharge along or across a line. Chose a low enough value of Almost_dry_fraction so the discharge in these "dry" areas is acceptably small.
- Interface_leakage_option. This specifies one of two options for computing vertical leakage at a spatially-variable area sink basis point where a fresh/salt interface is present. If unchecked (default), the vertical leakage is computed just like it is in all other cases: the vertical leakage rate is proportional to the difference in head from one level to the next. If this column is checked and an interface is present in the overlying layer, the head difference is computed by using the freshwater head that is at pressure equilibrium with static salt water at the base of the overlying layer; the head in the overlying layer is not used to compute the head difference. The head that is used to represent the overlying layer is the same as the head at the toe of the interface in the overlying layer. The unchecked mode is appropriate when the resistance to vertical flow between levels is due to the K3 of the domains themselves. The checked mode is appropriate when the resistance to vertical flow between levels is due to an aquitard between the levels that is not explicitly modeled (in this case the resistance of the aquitard must be incorporated into the K3 values specified in the upper and/or lower domain). See Fitts et al (2015) for comparisons of these methods and discussion.

#### Check Settings

These settings define the accuracy of boundary conditions required of the solution; iteration continues until these conditions are met. If when Solve is pressed the solution converged before reaching the maximum number of iterations, all boundary conditions were met within the tolerances specified here.

These settings also affect the function of Analysis/Check Boundary Conditions at Latest Iteration, which is used to check how well the solution meets specified boundary conditions. Such conditions include heads at head-specified wells and linesinks, extraction at spatially-variable area sink basis points, etc. When you select Analysis/Check Boundary Conditions at Control Points, each boundary condition is checked, and if the discrepancy between the specified condition and the model-simulated condition is greater than a threshold you specify here, the program prints the discrepancy to the run log. If the discrepancy is less than the threshold, nothing is printed. In cases where the solution did not converge to within these tolerances during the Solve process, the offending boundary conditions are listed along with their accuracy. This can be a help to home in on which boundary conditions are holding up the Solve process.

Four kinds of boundary condition tolerances are defined as follows.

- Head_check_tolerance is the threshold for the magnitude of discrepancy between specified and modeled heads, used at head-specified wells and line boundaries.
- Qn_check_tolerance is the threshold for discrepancies in the computed discharge per length along River line elements. It units are discharge/length [(L
^{3}/T)/L = L^{2}/T]. - Q_check_tolerance is the threshold for discrepancies in discharge, which are used along inter-domain line boundaries and normal-flux specified boundaries. In both cases, the condition being checked is the total discharge across a segment along the line [L
^{3}/T]. For inter-domain boundaries, it is the comparison of discharges on opposite sides of the boundary. For normal-flux specified boundaries it is the difference between modeled and specified discharges based on the specified discharge per length times the length of the segment. - Extraction_check_tolerance is the threshold for discrepancies in the modeled extraction (Equation 13 of Fitts (2010)) and the extraction computed from head values (Equation 6 of Fitts (2010)). The units of extraction and this threshold are discharge/area [(L
^{3}/T)/L^{2}= L/T].

### Time Steps

This input is used only for transient models. If you are doing a transient model, make sure you uncheck Steady under Model Input/General. Each row of input in the Time Steps table defines a time period, during which all boundary conditions are constant. For example, a model could have three time periods with different recharge rates, river stages, or well discharge rates in each of the three periods, but within each period the values remain constant.

For each time period, you specify the total length of the time period (Period_Length), the number of time steps the period is divided into (Steps_in_period), and the time step multiplier (Step_multiplier). The multiplier causes the length of successive time steps to grow by a factor equal to the time step multiplier. The following table illustrates the lengths of time four time steps for a period that is 100 time units long, using various time step multipliers.

Time Step | Multiplier = 1.0 | Multiplier = 1.5 | Multiplier = 2.0 |

1 | 25.00 | 12.31 | 6.67 |

2 | 25.00 | 18.46 | 13.33 |

3 | 25.00 | 27.69 | 26.67 |

4 | 25.00 | 41.54 | 53.33 |

Total Time: | 100.00 | 100.00 | 100.00 |

In all cases, the total time of the period is 100, but the lengths of the four steps change as the time step multiplier changes. This scheme is the same as employed in MODFLOW. Using a multiplier larger than 1.0 helps concentrate computing power early in the time period when there is more transient change occurring. Transient storage fluxes, which are part of spatially-variable extraction, are computed for each time step using a finite-difference approximation of the governing equation (Equation 6 of Fitts, 2010).

### Domains

The properties of each domain (called a subdomain in Fitts, 2010) are set with data tables under this menu. Different tables define the properties of different kinds of domains. A domain is a polygonal region of the model in a certain model level. Inside a domain, the aquifer properties (hydraulic conductivities, base elevation, storativity, porosity, etc) are homogeneous.

The boundary of a particular domain is defined by a combination of line boundaries that, in their input, are listed as external to the domain. Head-specified, normal flux-specified, and inter-domain boundaries can be external boundaries for domains. Other line boundaries like river and discharge-specified line boundaries are internal to domains and do not define domain boundaries. See the discussion under Subdomains and Model Levels for more detail and some examples.

All domain input data tables may be accessed through the main menu or by using a pop-up context menu when the cursor is over the plot.

#### Boundaries of Domains

The geometry of the boundary of each domain is not specified in the domain data tables, but is determined by the distribution line boundaries that define the external domain boundaries. Line boundaries that can be external domain boundaries are head-specified, normal flux-specified, and inter-domain. The data that is input for these types of line boundaries include information about which domain(s) that they bound. All domains should be completely bounded by such line boundaries, so that their geometry is unambiguous. See the discussion under Subdomains and Model Levels for more detail and some examples.

For the best accuracy, make sure the coordinates of the starting and ending points of adjacent external line boundaries match exactly (copy them). For example, if a domain boundary has two line boundaries defining it - one head-specified and the other inter-domain, make sure that the start/end points where these two line boundaries join have the exact same coordinates.

#### Input Common to All Domains

Several parameters are common and required input for any type of domain:

- The label_unique allows you and the model keep track of which domain is which. When adding wells, line boundaries, etc. to the model, this label defines which domain these features are in. These labels are required and must be unique (no two domains should have the same label). Once the labels have been declared and other features have been added to the model, do not change the labels because doing so would require changing the domain label of each well, line boundary, and area source/sink that is in that domain.
- The level of a domain refers to where this domain fits in the vertical sequence of model levels. In a multi-layered part of a model, the level begins at 1 at the uppermost level and increases in deeper levels. The level may be from 1 to a maximum of 15. If there are vertically stacked domains in a multi-level part of the model, vertical leakage is assumed to occur between domains that are at different levels but occur at the same x,y coordinate. For example, if three domains in a three-level part of the model were assigned levels 1, 2, and 4, there could be vertical leakage between levels 1 and 2 and between levels 2 and 4, if this area of the model has spatially-variable area source/sinks. When making plots of model results, plots show one level at a time.
- For Average_head, list your best estimate of the average head in this domain for your simulation. This then defines a constant that is added to the discharge potential for this domain. More details are given about this in the next topic.
- The value of Porosity is used in computing average linear velocity and advection travel times along pathlines. The average linear velocity = specific discharge/porosity. For a solute that adsorbs to the porous medium, the solute travel time will be be longer than the pure water advective travel time. If you want to plot travel times that factor in retardation of a solute, you may input Retardation Factor * Porosity instead of Porosity in this column and the travel times will reflect travel of a retarded solute plume.
- K1_horizontal is the horizontal hydraulic conductivity. In a domain that is anisotropic in the horizontal plane, K1 differs from K2, and these represent the principle hydraulic conductivities in the horizontal plane. K1 > K2, K1 < K2, and K1 = K2 are all possible.
- K2_horizontal is the horizontal hydraulic conductivity. In a domain that is anisotropic in the horizontal plane, K2 is in the direction normal to the K1_horizontal direction. To simplify inputs, you can enter "=K1" if K2=K1 and the domain is isotropic in the plane of the domain. If you want a fixed ratio of anisotropy, you can enter "=K1*D" where D is a real number. Using "=K1" or "=K1*D" is particularly handy for parameter estimation, to limit the number of parameters being estimated.
- Angle_K1_to_x is the angle, in degrees, between the x axis and the direction of K1_horizontal. Positive angles are measured counter-clockwise from the x axis.
- K3_vertical_top defines the vertical hydraulic conductivity of the upper half of the domain. This parameter is only used if there is vertical leakage with spatially-variable area source/sinks. To simplify inputs, you can enter "=K1" if K3=K1 and the domain is isotropic normal to the plane of the domain. If you want a fixed ratio of anisotropy, you can enter "=K1*D" where D is a real number less than or equal to 1.0. For example, make K1/K3 = 10 by entering "=K1*0.1". Using "=K1" or "=K1*D" is particularly handy for parameter estimation, to limit the number of parameters being estimated.
- K3_vertical_bottom defines the vertical hydraulic conductivity of the lower half of the domain. This parameter is only used if there is vertical leakage with spatially-variable area source/sinks. To simplify inputs, you can enter "=K1" if K3=K1 and the domain is isotropic normal to the plane of the domain. If you want a fixed ratio of anisotropy, you can enter "=K1*D" where D is a real number less than or equal to 1.0. For example, make K1/K3 = 10 by entering "=K1*0.1". Using "=K1" or "=K1*D" is particularly handy for parameter estimation, to limit the number of parameters being estimated.

#### Details about Average_head

In other two-dimensional AEM programs such as TWODAN, the flow region is open to infinity, and one unknown that needs to be solved for is the amount of flow that goes between the modeled area and infinity. In these programs, to generate an equation to solve for that additional unknown, you specify a head at one location ("reference head" in TWODAN).

In Anaqsim, each domain model is closed and finite, so there is not that extra unknown. You specify the average head in each domain. which in turn defines a constant that is added to the potential for that domain. Since there are linesinks that bound each subdomain, the flow field outside those linesinks does not matter (the flow to/from infinity doesn't affect the solution inside the domain boundary). You could specify a variety of different average head values, within a reasonable range (close to the actual average), and get essentially identical results.

Say you have a simple Anaqsim one-domain model that has head-specified boundaries all around the external boundary, with h=100. There is zero recharge, so h should be 100 everywhere inside the domain. If you specify the average domain h=100, the program adds a constant to the potential that is the potential corresponding to h=100. On solving, it will turn out that the boundary conditions are met perfectly everywhere on the boundary and the boundary linesinks all have zero discharge; the analytical model will boil down to the simple equation h(x,y)=100. With zero discharges in the boundary linesinks, there is no flow to or from infinity to the model boundary from the outside (even though you never see this part of a domain model, it exists).

Now imagine that instead you set the average domain head to 110, which adds a larger constant to the potential for this domain. Now, to achieve the boundary h=100, the boundary linesinks need to extract water to pull the head surface down. In this case the solution on and inside the boundary will still be approximately h=100, but there will be flow to the outside of the boundary linesinks from infinity. Likewise, if you set the average domain head to 90, the solution on and inside the boundary will be approximately h=100, but there will be flow from the outside of the boundary linesinks to infinity. When you change the average head for a domain, it changes the part of the domain solution that you never see - the part that lies outside the external boundary of the domain.

If you use long line elements with few parameters and the average head is not close to the actual average, the differences in the external, unseen part of the model may have some visible impact on the model within the domain boundary. The most likely manifestation will be some lumpiness in the head surface near those boundary elements. Correct this by choosing a more representative average head and/or shortening line boundary elements and increasing the number of parameters per line.

#### Confined and/or Unconfined

Starting with release 2015-1, confined, unconfined, and confined/unconfined domains are in the same data table, which allows the user to quickly switch between these domain types. For confined and/or unconfined domains, these parameters are needed in addition to those that are common to all domains:

- Domain_Type determines which type of domain is to be modeled. Confined, Unconfined, and Confined/Unconfined are the three options. For Confined, the domain is always a fixed saturated thickness equal to the top elevation minus the bottom elevation, and the domain's transmissivity is independent of head. Confined domains generate linear equations, while the other two options can generate nonlinear equations. It is often wise to begin your modeling with confined domains which tend to converge faster and be less prone to numerical issues associated with nonlinearity and drying up. Later, it is easy to switch to unconfined or confined/unconfined domain types. With the Unconfined domain type, the domain is always unconfined and the Top_elevation is not used (although some value must be input). The Confined/Unconfined domain type behaves like a confined aquifer when the head equals or exceeds the top elevation, but like an unconfined aquifer where the saturated thickness depends on head, when head drops below the top elevation (see Strack, 1989, section 8; Haitjema, 1995, section 3.1.3; Strack, 2003, equation 3).

Never put an unconfined domain beneath an overlying domain, because the unconfined domain saturated thickness is always computed as head minus base elevation. If you think an underlying domain may become unconfined, use confined/unconfined rather than unconfined

- Top_elevation defines the elevation of the top of the domain. Not used for unconfined domain type.
- Bottom_elevation defines the elevation of the bottom of the domain.
- Storativity (S) is the dimensionless elastic storage parameter. S normally is the saturated thickness times specific storage (Ss). Starting with release 2021-1, there is an option to input the value of specific storage instead of storativity. This can simplify input by avoiding the step of multiplying by saturated thickness. To input specific storage, enter "Ss:" in front of the value. For example, if you entered "Ss: 0.0037", the value of storativity in this confined domain would be set to 0.0037 * b, where b is the saturated thickness (top elevation - bottom elevation). See Storage Parameter Details for more on how different storage parameters apply for different domain types.
- Specific_yield (Sy) is the dimensionless storage parameter for the unconfined domain type. See Storage Parameter Details for more on how these parameters apply for different domain types.

For numerical stability where the saturated thickness of an unconfined or confined/unconfined domain approaches zero, Anaqsim imposes a minimum saturated thickness. When heads drop near or below the bottom, the domain reverts to a confined-type domain with a fixed minimum saturated thickness. This facet of Anaqsim is governed by a parameter called Almost_dry_fraction under Solution/Solve Settings.

#### Confined Interface

For confined interface domains, these parameters are needed in addition to those that are common to all domains:

- Top_elevation defines the elevation of the top of the domain.
- Bottom_elevation defines the elevation of the bottom of the domain. The saturated thickness is the difference between the top and bottom elevations.
- Storativity is the dimensionless storage parameter that applies in the confined portion of this type of aquifer, equal to saturated thickness times specific storage. As described under Confined and/or Unconfined domains, you may enter specific storage values here instead of storativity values.
- Salt_elevation defines the elevation of the surface of the salt water, which is assumed to be static. Typically this is about the elevation of sea level.
- DensityRatio is the ratio of the salt water density to fresh water density. This varies from place to place, but is often near 1.025.

Interface domains in Anaqsim are based on the Ghyben-Herzberg approximation:

- The salt water is hydrostatic - pressure is proportional to depth below Salt_elevation. This assumption is reasonable when the flow is roughly steady.
- The fresh/salt water interface is sharp, with no mixing.
- Fresh water within a domain is hydrostatic (Dupuit approximation); there is no vertical resistance to flow.

The confined interface domains are based on the techniques presented by Strack (1989) on pages 101-106 and in Fitts et al (2015). These domains are confined with fresh water from top to bottom when heads are high enough that there is no interface, or they are confined with an interface and some salt water if heads are low enough. Confined interface domains would go to zero fresh water saturated thickness when the fresh water head drops to a level where the fresh water pressure at the top of the domain equals the salt water pressure at that elevation. This occurs where the freshwater head = Top_elevation + (Salt_elevation - Top_elevation) * DensityRatio. For numerical stability where the fresh water saturated thickness approaches zero, Anaqsim imposes a minimum saturated thickness. When heads are low enough, the domain reverts to a confined-type domain with this minimum saturated thickness. This facet of Anaqsim is governed by a parameter called Almost_dry_fraction under Solution/Solve Settings.

Generally transient simulations with interface domains will be inaccurate because it is assumed that the salt water has a hydrostatic distribution of pressure on the interface. In most transient situations, the salt water is moving, and when that movement has a vertical component, the hydrostatic pressure assumption is violated. If you feel the hydrostatic salt water assumption is still reasonable, you may proceed with a transient simulation but Anaqsim will issue a warning. See Storage Parameter Details for more on how storage parameters apply to this domain type.

#### Unconfined Interface

For unconfined interface domains, these parameters are needed in addition to those that are common to all domains:

- Bottom_elevation defines the elevation of the bottom of the domain. The saturated thickness is the difference between the head and the bottom elevation.
- Specific_yield is the dimensionless storage parameter for an unconfined aquifer.
- Salt_elevation defines the elevation of the surface of the salt water, which is assumed to be static. Typically this is about the elevation of sea level.
- DensityRatio is the ratio of the salt water density to fresh water density. This varies from place to place, but is often near 1.025.

Interface domains in Anaqsim are based on the Ghyben-Herzberg approximation:

- The salt water is hydrostatic - pressure is proportional to depth below Salt_elevation.
- The fresh/salt water interface is sharp, with no mixing.
- Fresh water within a domain is hydrostatic (Dupuit approximation); there is no vertical resistance to flow.

The unconfined interface domains are based on the techniques presented by Strack (1989) on pages 108-111 and in Fitts et al (2015). These domains are unconfined with fresh water from the water table to the bottom when heads are high enough that there is no interface, or they are unconfined with an interface and some salt water if heads are low enough. Unconfined interface domains would go to zero fresh water saturated thickness when the fresh water head drops to Salt_elevation. To avoid dry conditions, keep all heads in the domain above Salt_elevation. For numerical stability where the fresh water saturated thickness approaches zero, Anaqsim imposes a minimum saturated thickness. When heads are low enough, the domain reverts to a confined-type domain with this minimum saturated thickness. This facet of Anaqsim is governed by a parameter called Almost_dry_fraction under Solution/Solve Settings.

Generally transient simulations with interface domains will be inaccurate because it is assumed that the salt water has a hydrostatic distribution of pressure on the interface. In most transient situations, the salt water is moving, and when that movement has a vertical component, the hydrostatic pressure assumption is violated. If you feel the hydrostatic salt water assumption is still reasonable, you may proceed with a transient simulation but Anaqsim will issue a warning. See Storage Parameter Details for more on how storage parameters apply to this domain type.

#### Storage Parameter Details

Storage parameters are defined differently for different domain types as explained below.

- In confined domains, the storage parameter is always S (storativity) regardless of head.
- In unconfined domains, the storage parameter Sy (specific yield) applies when h > the head at minimum saturated thickness (see Almost_dry_fraction under Solve Settings). When head is lower than the level at minimum saturated thickness, the storage parameter equals S * Almost_dry_fraction (usually a very small value). This scheme helps with convergence in cases where heads fall below the bottom of the domain, but makes storage changes small under these conditions.
- In confined/unconfined domains, storage is like a confined domain when h >= top elevation, and like an unconfined domain when h < top elevation.
- In confined interface domains, the storage parameter = S + (porosity / (DensityRatio - 1)) where an interface is present. Where the domain is confined with no interface present (higher heads), the storage parameter = S. Generally, storage contributed by interface shifts greatly exceed elastic storage; S << porosity / (DensityRatio - 1).
- In unconfined interface domains, the storage parameter = Sy + (porosity / (DensityRatio - 1)) where an interface is present. Where head is high enough that there is no interface (inland from the toe of the interface), the storage parameter = Sy. Generally the storage contributed by interface shifts is larger than water table storage; Sy < porosity / (DensityRatio - 1).

In all but confined domains, the storage parameter is a function of head. The head at the start of a time step is used to determine the storage parameter that applies for the time step, even though the head at the end of the time step may correspond to a different storage parameter. This approximation helps convergence and is minor if time steps are small enough.

### Pumping Wells

Pumping wells may be either discharge-specified or head-specified. The discharge-specified type may be screened in one domain or across multiple domains if the well screen spans multiple model levels. All well input data tables may be accessed through the main menu or by using a pop-up context menu when the cursor is over the plot.

#### Input Common to all Pumping Wells

With all types of pumping wells, the following parameters are required.

- Label is a text label that helps you keep track of multiple wells.
- X,Y defines the horizontal coordinates of the well. To graphically edit a well's coordinates, left click to select it. Once selected, the well will be enclosed in a purple square box as shown below

When highlighted in this way, the well can be moved by clicking on the purple box and dragging it. This will automatically alter the coordinates of the well in the model input table. To stop graphic editing, press Esc to de-select the well.

- Radius defines the radius of the well. If there is a high conductivity filter pack around the well screen, the radius should be the radius of the borehole, not the radius of the screen.

#### Discharge-Specified

With discharge-specified wells, negative rates are used for extraction from the aquifer and positive rates are used for injection into the aquifer. Additional parameters defined here are:

- Domain defines the domain that the well screen is in.
- Discharge is the discharge of the well in units of [L
^{3}/T]. In transient simulations, this parameter may vary from one time period to the next.

#### Discharge-Specified (Multi-Domain)

Use this type of well to simulate a well with a screen that spans multiple domains and levels in the vertical direction. Anaqsim computes the appropriate discharge from each domain spanned so that the total discharge equals the specified discharge, and the heads at the well radius in each domain match each other. With discharge-specified wells, negative rates are used for extraction from the aquifer and positive rates are used for injection into the aquifer.

- Domains defines the domains that the well screen spans.
- Discharge is the discharge of the well in units of [L
^{3}/T]. In transient simulations, this parameter may vary from one time period to the next.

#### Head-Specified

With head-specified wells, you specify a head that applies at the well radius and Anaqsim computes the discharge needed to achieve that head. The discharge of a head-specified well may be checked after solving from the Analysis menu.

- Domain defines the domain that the well screen is in.
- Head_at_well defines the head at the well radius. In transient simulations, this parameter may vary from one time period to the next.
- Off_Periods is used in transient simulations if you want the well discharge to be zero during certain periods. The periods you want the well off are delimited with comma(s). For example, the following input is for a transient model with five time periods. The well pumps at rates such that at the end of period 1 the head at the well is 80, the well is off during periods 2 and 3, and the well pumps so that the head at the well is 115 and 118, respectively, at the ends of periods 4 and 5.

### Line Boundaries

A variety of line boundary conditions are available in Anaqsim. Each line boundary is a multi-segmented line (polyline) and the user inputs a list of vertexes in sequence from one end of the polyline to the other. The line boundary condition is approximated using linesink elements similar to those described by Jankovic and Barnes (1999).

Most line boundaries have a parameter that varies from one value at the starting vertex to another value at the ending vertex. The interpolation scheme between the end points is described in the next topic.

Anaqsim approximates the specified boundary conditions along line boundaries, as discussed by Fitts (2010). You may check the accuracy of line boundary condition approximations under the Analysis menu.

For internal line boundaries, the coordinates of all polyline points must not be outside the subdomain boundary, otherwise numerical havoc will be wreaked! It is possible for the start or end point of an internal line boundary to coincide exactly with a corner point of an external line boundary.

All line boundary input data tables may be accessed through the main menu or by using a pop-up context menu when the cursor is over the plot.

#### Input Common to all Line Boundaries

The following input items are common to all of the line boundaries:

- Label is a text label that helps you keep track of multiple line boundaries. Please see River Line Boundary Discharges for special labeling of River line boundaries so that you may sum the discharges of groups of river boundaries.
- Each line segment has a line element with a certain number of unknown parameters that is defined in the Parameters_per_line column. If you choose 1 for this, the strength of the element is constant along the line, if you chose 2 for this, the strength of the element varies linearly along the line, if you choose 3 for this, the strength of the element varies parabolically along the line, etc. Using more parameters per line can increase the accuracy of the boundary condition approximation along the line, but at the cost of additional equations in the system of equations that is solved. You only need a high number of parameters per line if the heads or discharges along the element are expected to vary complexly. In many cases, 3 or fewer parameters per line is plenty. Experiment with this and reduce the number of parameters to the minimum that gives you reasonable boundary condition accuracy, which you can check using right-click / Check Line Boundary Conditions. In the case of a Discharge-Specified line boundary, the user does not define Parameters_per_line because it is always set to 1; the discharge/length of these line elements is constant and equal to the specified discharge of the line boundary divided by its total length.
- Coordinates defines the x,y coordinates of the polyline vertexes. When you click on a cell in this column, a small text box window appears. In this text box, enter/edit lines of coordinate data, one line per vertex. Each line should have x and y values separated by either a comma or a tab character. You may digitize the coordinates of a polyline in the plot view and then paste the coordinates into this text box. In the case of normal flux-specified external boundaries, the coordinates must be listed in counter-clockwise order with the domain to the left of the boundary as you proceed along it. Once input, coordinates can be edited graphically by selecting the line boundary and then moving the vertexes or inserting or deleting vertexes. To graphically edit a line boundary's coordinates, left click to select it. Once selected, the vertexes will be enclosed in purple square boxes as shown below

When highlighted in this way, the vertexes can be moved by clicking on the purple box and dragging it. This will automatically alter the coordinates of the line boundary in the model input table. To de-select a line boundary, press Esc. Procedures for graphic editing of line boundaries are covered in the tutorial videos on the website. To reverse the order of the vertexes (this can be handy if you digitized in the wrong direction), click the Reverse button.

Most line boundaries have additional parameters defined at the start and end points, such as heads for head-specified line boundaries. With all such parameters, the same algorithm is employed to interpolate the specified values along the line boundary:

- Apportion the intermediate values to the vertexes based on the number of line segments in the polyline. For example, if there are 4 segments and the end values are 100 and 110, the values at the vertexes would be 100, 102.5, 105, 107.5, and 110. If there are 5 segments, the values at the vertexes would be 100, 102, 104, 106, 108, and 110.
- Linearly interpolate values to the control points within a line segment, assuming a linear distribution from one end to the other.

The additional parameters specific to each type of line boundary are listed in the following topics.

#### Head-Specified

With head-specified line boundaries you specify these additional items:

- Domain defines the domain that the line boundary is in. Double-click on this cell to open a drop-down list and make a selection.
- Check the Domain_Boundary check box if this line boundary is on the external boundary of the domain.
- The h_start and h_end are the specified head values at the starting and ending vertexes. In transient simulations, these parameters may vary from one time period to the next.
- Off_Periods is used in transient simulations if you want the line boundary discharge to be zero during certain periods. This could be handy for a dewatering trench that is turned off and on. The periods you want off are delimited with comma(s). For example, the following input is for a transient model with three time periods. The line boundary discharges at rates such that at the end of period 1 the heads along it are 104, the line boundary is zero during periods 2, and the line boundary discharges at rates such that at the end of period 3 the heads along it are 106.

Boundary condition equations are written at each control point on each line segment. The equation specifies that the modeled head = specified head (interpolated between endpoints of the line boundary). The specified head condition is approximated between control points and may be checked graphically.

#### Normal Flux-Specified

With normal flux-specified line boundaries you specify these additional items:

- Domain defines the domain that the line boundary is in. Double-click on this cell to open a drop-down list and make a selection.
- Check the Domain_Boundary check box if this line boundary is on the external boundary of the domain.

When the boundary is external, it is necessary to list the coordinates of the polyline in counter-clockwise order with the domain to the left of the boundary as you proceed along it. If coordinates are specified in the wrong (clockwise) order, there is a check in the program that will detect and report this error. This error can occur if you mistakenly specified the coordinates in clockwise order around the outside of the domain. This message can also result if you have made errors in specifying additional external line boundaries either at these same coordinates (e.g. have two external line boundaries in the input that share the same vertex coordinates), or have erroneous external line boundaries to the right of this one (see discussion of left/right algorithm).

- The Normal_flux_start and Normal_flux _end are the specified normal flux values at the starting and ending vertexes. Normal flux is the component of domain discharge normal to the line segment, and has units of discharge per length [L
^{3}/T/L] = [L^{2}/T]. This may also be thought of as the normal component of specific discharge times saturated thickness. The normal flux is positive for flow across the boundary from left to right as you proceed from the start toward the end. Normal flux is negative for flow from right to left as you proceed from the start toward the end. In transient simulations, the normal flux parameters may vary from one time period to the next.

Boundary condition equations are written for sub-intervals in each line segment (e.g. three subintervals for 3 parameters/line). The equation specifies that the total discharge across the line over the subinterval equals the total to interpolated specified fluxes over the interval. The accuracy of this approximation may be checked graphically.

#### Head-Dependent Normal Flux (3rd type)

This allows head-dependent normal flux into or out of the model, depending on the modeled head at the boundary. Boundary conditions like this are sometimes called 3rd type, Robin, general head (GHB in MODFLOW), or mixed boundary conditions; they involve both head and flux. The boundary must be an external boundary of a domain. It is necessary to list the coordinates of the polyline in counter-clockwise order with the domain to the left of the boundary as you proceed along it. If coordinates are specified in the wrong order, there is a check in the program that will detect and report this error. This error can occur if you mistakenly specified the coordinates in clockwise order around the outside of the domain. This message can also result if you have made errors in specifying additional external line boundaries either at these same coordinates (e.g. have two external line boundaries in the input that share the same vertex coordinates), or have erroneous external line boundaries to the right of this one (see discussion of left/right algorithm).

This kind of boundary is illustrated conceptually in the vertical profile sketched below. It is as though there is a fictional domain beyond the boundary (orange) outside of the domain (blue) , and at a distance b outside the boundary, there is a fixed head h*. The head difference between h* and the head at the boundary (h) drives a component of discharge normal to the boundary.