RELEASE INFORMATION

Version 8.10 (FEQ for USGS documentation report spun off here.)

March 20, 1995: Extracted subprogram units that are common to both FEQ and FEQUTL so that only one copy exists.
Version 8.50
March 31, 1995: The following series of changes have been made:

1. Blank lines are now discarded from all character input except for blank lines within a branch description.

2. Many messages that were in upper case have been converted to mixed upper and lower case.

3. Access to HECDSS time series(path names) is now supported for input of flow or elevation at a boundary node, for output of flow or elevation from any node, and for the unit-area runoff intensity used to compute lateral inflow from a tributary area. When the lateral inflow is defined using the HECDSS, FEQ operates as if DIFFUS=NO in past versions. That is, the special multiple event processing with DIFFUS=YES is not provided. In version 8.5 the use of DSS time series to supply lateral inflows is selected by using DIFFUS=DSS. Only a single event is run; the one given by the starting and ending times.

Changes have been made to the INPUT FILES and OUTPUT FILES block as well as to the TRIBUTARY AREA block.

To input description update


Version 8.51
 

April 21, 1995: Corrected problem with different lengths of character strings for file names. Also made minor changes to permit LF90 to compile properly at optimization level 2.


Version 8.53
 

April 28 1995: Modified Code 13 in Network Matrix Control Input to permit the explicit specification of one or two nodes for inflow. If the nodes are given explicitly, then the user must give the effective angle of entry of the flow into the main channel. The effective angle of entry is always less than the angle of entry of the channels themselves. If no inflow nodes, also called side nodes, are given, then FEQ assumes that there is no downstream component of momentum flux entering the junction from the side node. That is, FEQ assumes that the effective angle of entry is always 90 degrees. This assumption is appropriate if the water plunges into the mainstream from above as in a side-channel spillway on a small slope.

Currently the side nodes must be on branches so that FEQ can find an area of flow and a momentum-flux coefficient when it needs to compute the momentum flux. Currently free nodes have no way of indicating a momentum flux. This may be changed in the future.

To input description update
To update for section 8.1.2.1.2.7 Conservation of Momentum/Energy: Code 13


Version 8.54

May 10, 1995: Blank lines are now echoed to the output file.
Version 8.56
June 21, 1995: Modified formats in TRIBIN and TRBOUT to allow up to 12 land uses per gage.

Version 8.57
July 26, 1995: Suppressed some intermediate outputs that were overlooked earlier.


Version 8.58

July 27, 1995: Modified screen output of event elapsed time so that overwriting would not occur.
Version 8.59
August 1, 1995: Added code to detect missing water-surface elevation in the steady-flow computations when code=6 in the BACKWATER Block.


Version 8.60

September 1, 1995: FEQ was supposed to detect improper use of flow nodes. However, a case occurred in which the detection code failed. The detection code has been changed so that it counts relationships attached to a flow node and just not the available relationships attached to a flow node. This change will reduce the frequency of occurrence of the dreaded zero-pivot error message.


Version 8.61

September 14, 1995: The use of time-series tables, that is 1-D function tables of types 7, 8, or 9 was not possible when DIFFUS=YES because the conversion from the year/month/day:hour time argument was converted to the elapsed time from the start of the event in the time series file being computed. This meant that the internal argument began at 0.0 seconds at the start of each event. This is hardly what is wanted in any application. This was a hold-over from pre-TSF days when only a single event was computed. This has been changed so that the internal conversion changes to an argument that is the elapsed time from the start of the first event. This means that the time output field that appears when complete output at a time step is requested will have a value different than before for all events but the dummy event. The internal argument for all one-D tables is single precision. This entails that the argument will not be able to define a time point down to a few seconds when the time span of the TSF is significant. The relative precision for a floating point number in Fortran, at single precision, is no better than 1.e-7. In an elapsed time of 70 years, obtained if the dummy event is in 1925 and the TSF runs through 1995, there will be potential uncertainty of about 270 seconds or 4.5 minutes. This is probably suitable for most proposed applications. Time series tables would not be a good choice for flows or stages for this time span. Flows and stages are best stored in files when the time span of the TSF is large. However, time series tables are suitable for use in controlling capacity or elevation for the head datum in Code 5 type 6 using 2-D function tables of type 13.

Version 8.65
October 5, 1995: Special output has been modified to permit user specification of additional output variables. The new values are given in an OPTIONS line. The OPTIONS line must follow the UNIT line in the input. The OPTIONS line must begin with "OPTIONS=" where the double quote marks are used to delimit the string here but not in the input. The word, OPTIONS, must be in all upper case and must start in column 1. The equal sign must not have any spaces preceding it. The options must be in upper case and must have at least one blank ahead and one blank following each option. The current options are:
V - output the mean velocity for the cross section.
A - output the area for the cross section.
MCA - output the main channel area for the cross section. The main channel is defined by a user supplied cross-section function table given in the Special Output Block for this cross section. The table is given in the right-most five of the six columns following the 14 column heading for each output item.
MCQ - output the main channel flow.
MCV - output the velocity in the main channel.
FPA - output the area of flow in the flood plain. The flood plain is all area in excess of the area in the main-channel cross-section function table. Neither FEQ nor FEQUTL know anything about a flood plain. The user defines the flood plain by the main-channel cross-section function table. If the main channel proves to have larger values of top width, area, or conveyance, than does the cross section given in the Branch Description Block, FEQ will use the area as given in the cross-section function table in the Branch Description Block. The flood plain area will be taken as zero.
FPQ - output the flow in the flood plain.
FPV - output the velocity in the flood plain. If the main-channel cross-section function table is not given, FEQ can only output the V and A options. The other options will have blank values output. The Special Output file will always have the water-surface elevation and the flow output. The optional items follow with one line for each item. The order of the lines is in the order in which the options were given on the OPTIONS= line. The PAGE size used to control printing of headings in the Special Output file will be adjusted to be an integral multiple of the number of lines per time point. FEQ first deducts two to account for the heading lines. Then the remaining number of lines is rounded downward to be an integral multiple of the number of lines of output. Two is added back to obtain the adjusted value for PAGE. Note that this assumes that the PAGE value is always larger than the maximum number of lines that can be output. Currently that limit is 10. Thus PAGE should never be less than 10 + 2 = 12. The options are only output for nodes on a branch. Nodes not on a branch are skipped and only two lines of output are produced for them.

To input description update


Version 8.70
 

December 28, 1995: Added option for using difference in elevation between two exterior nodes as the argument for controlling structures in an Operation Control Block. Also changed the format of the flow type in the special output file so that all flow type codes are right justified in their columns. The specification of difference in elevation is given by placing the exterior node label, new style only, in the KEY column. The difference is computed as elevation at node in NODE minus the elevation at node in KEY.

To input description update


Version 8.71
January 8, 1996: Corrected a bug in the output of the date/time when the computations fail to converge. This problem has apparently been present for some time but was not reported. It has no effect on results and only involved an error in the hour of the day when the iteration log for the failed time step was printed. The hour of the day remained at the time of the previous successful time step.

Version 8.72
February 1, 1996: Add checking of the station sequence for each branch to make sure that all stations are either increasing or decreasing. It was possible for the user to make a mistake and have the direction of stationing change within a branch. As long as the element length was non-zero, FEQ did not complain. However, the distribution of tributary area would be affected since the sum of the absolute values of the element lengths would be greater than the length of the branch.

Version 8.73
May 6, 1996: Fixed problem with zero array size when requesting special output with no control structures present.

Fixed problem of confusion between underflow and overflow gates under dynamic control.

Changed case of many error messages.


Version 8.74
May 24, 1996: Fixed problem with multiple control points for pumps introduced by work in progress on new options for dynamic control of gates and pumps.

Removed more old carriage control characters from output.


Version 8.76
July 25, 1996: Implemented new format for Network Matrix Control Input block. This format is optional and if you do nothing the old format is assumed. The new format is signaled by putting the characters: NEW with the N in column 1, on the line that initiates the Network Matrix Control Input block. This line is suggested to contain: NETWORK MATRIX CONTROL, in the input description for FEQ. In order to request the new input format this line becomes: NEW NETWORK MATRIX CONTROL.

In the process of making these changes the input processing routines were changed so that more than one trailing blank is not printed for comment lines. In earlier versions comment lines were output with extra trailing white space. The new format is column independent but still order dependent. All items must be in the same order as given in the input description but they do not have to be in the indicated columns. The new rules are as follows:
 

1. There must be at least one space or a single comma between successive items. No spaces or commas allowed within an item.

2. If an optional item is skipped in either the integer/identifier or the fixed/float group, then a place holder must appear for that item. This is required to keep the order of all items the same. The place holder is a single asterisk. It also must be separated from adjacent items by one or more spaces.

3. Continuation lines for Code 5 Type 6 are NO longer flagged in the input by placing a positive number in the N10 location. Instead the continuation is signaled by putting a space-slash sequence after the last item is entered on the line.

4. All values appearing in the fixed/float part of the input must contain a decimal point. FEQ uses the decimal point to distinguish the two groups. If a decimal point is omitted, FEQ will get confused and will probably report an error message.

5. Names for pumps or gates must start with an alphabetic character. They cannot start with a number and the only special character they should contain is the underline bar.

6. All of the size restrictions still apply. That is the branch number must not be larger than 999. Free nodes cannot be larger than 999 also. I plan to make these limits larger but this requires changing many formats and internal string sizes. That change will take some careful planning. Changing function table number limits is simpler but must also be done for FEQUTL at the same time in order to be useful. FEQUTL has the complication of containing special table numbers that also must be changed and this implies that TYPE5.TAB needs to be handled properly also.

7. All of the items for a given code must appear on a single line. All items must appear within 112 columns of text. This number was picked because there was already an input routine that supports it and because this should be long enough for now. It will become increasingly useful to have an editor that can support a window with more than 80 characters on a line. Support for at least 130 characters and preferably more like 150-160 characters should be sought. The following lines give a fragment of the Network-Matrix Control Input for an existing model. Note how the table numbers have no spaces between them. The node labels for branch numbers larger than 99 also have no white space to set them off. The input becomes a bit difficult to read. Also comments have been placed beyond column 80 where FEQ will not encounter them when processing the input. The code 5 type 2 entry has one fixed/float value that is skipped, F2.
 

-----------------------------------Fragment Start----------------------------------------------------------------
NETWORK-MATRIX CONTROL INPUT
 CODE  N1  N2  N3  N4  N5  N6  N7  N8  N9  N10     F1     F2     F3     F4     F5
    5  2  F8 U14  F81798  501798  50          748.16    5.0 743.80  745.5        SPECIAL ASSESSMENT POND
    1  14
    2   3  F8 U14 D13
    5   6 D14 U15 D1413181318                1 742.47                             INDUSTRIAL DRIVE
                     14221422                2 751.61
                     15221522                3 749.33
                     15231523                  752.05
    5   6D109U110D10923122312                1 750.73                             ABANDONED RR SPUR
                     24122412                  755.20
-----------------------------------Fragment End----------------------------------------------------------------

If the FEQ file for this model is processed by a new utility program, called NETUTL, the following fragment results.
-----------------------------------Fragment Start----------------------------------------------------------------
NEW NETWORK-MATRIX CONTROL INPUT
 CODE  N1  N2  N3  N4  N5  N6  N7  N8  N9 N10     F1     F2     F3     F4     F5
    5   2  F8 U14  F8 1798  50 1798  50         748.16 *   5.0 743.80  745.5  ? SPECIAL ASSESSMENT POND
    1  14
    2   3  F8 U14 D13
    5   6 D14   U15 D14 1318 1318              742.47 /?INDUSTRIAL DRIVE
                         1422 1422              751.61 /?
                         1522 1522              749.33 /?
                         1523 1523              752.05  ?
    5   6 D109 U110 D109 2312 2312              750.73 /? ABANDONED RR SPUR
                         2412 2412              755.20  ?
-----------------------------------Fragment End----------------------------------------------------------------
This utility takes the old input and adds a single space in front of each field except for the CODE field. It also changes the continuation option for Code 5 Type 6 and inserts any needed place holder values. Any following comments must be preceded by a single quote to prevent FEQ from viewing them as potential input. NETUTL places the single quote after the first fixed/float field unless more fixed/float fields are used. A comment can begin at any point after the last item in a line. If there is no comment following a line a quote need not be present but may be present as shown. Blank lines are permitted and will appear in the output.
Also in the fragment as shown, all of the fixed/float values appear in a given column. NETUTL does this in order to keep the input in column form but the columns are not used in processing the input. NETUTL cannot adjust comment lines.


Version 8.80
 
August 8, 1996:

--A problem when multiple references to a single type 15 function table were made has been corrected. Tables of type 15 contain the table numbers for function tables of type 13 in order to represent a 3-D table for representing underflow gates. In processing of these type 15 tables, FEQ converts the table numbers to the address of the table. In versions previous to this one, FEQ did not have a way of remembering that the conversion had been done. Thus if the table of type 15 was used again to describe an identical gate, the conversion from table number to table address was done again--but this time it failed since the table numbers were no longer present in the type 15 table. The work around this problem was to make a copy of the type 15 table and then change its table number. Each of the type 15 tables would refer to the same set of type 13 tables and FEQ worked fine.

--A change was made to the internal format of the type 15 table so that FEQ could remember that the conversion from table numbers to table addresses had been made. Thus on second and subsequent appearances the conversion would not be made.

--Corrected a problem with writing HECDSS time series when the time step became small. The routine for interpolation from FEQ?s irregular time step to the HECDSS regular time step became confused at the boundaries of an internal buffer. The boundary computations have been changed so that small time steps,less than 60 seconds do not cause problems.

--A major new option for the Network-Matrix Control Input has been completed. This was made possible by the column-free option introduced in version 8.76 (not released to anyone). Therefore, these new options only function when the first three characters of the heading for the block are: NEW. The option is the creation of what are called macro instructions. Each code number in the Network-Matrix Control Input is an instruction, that is, it instructs FEQ on what to do at a particular point in a network of channels. It turns out that many patterns of instructions in the input are the same. For example, many junctions are described by the same three instructions. A macro instruction is a name given to a particular group of instructions. The macro instruction name is followed by one or more arguments that supply the information that varies from instance to instance. The facility for supporting macro instructions also presents an opportunity to supply names for instructions instead of numbers.

An optional input block, DEFINE MACROS AND INSTRUCTIONS, has been added to FEQ. It appears just before the Network-Matrix Control Input block. If macros are to be defined, this block must be present. Also for any macro to come into play, the column-free input option for the Network-Matrix Control Input must be invoked as well. An example of a Define Macros block is:
1 DEFINE MACROS AND INSTRUCTIONS
2
3 ; Here are instruction definitions. The pattern is always
4 ; an identifier that becomes the instruction name followed
5 ; with one or more intervening spaces by the corresponding
6 ; FEQ Network-Matrix Control Input Code value. The following
7 ; line defines the identifier: EqZ to have the value of 3.
8
9 EqZ 3
10 CS_2D 5
11 CS_1D 4
12 qsum 2 3
13 FILE=TEST.MIF
14
15 JUNCTION n1 n2 n3
16 EqZ n1 n2
17 SumQ n1 n2 n3
18 EqZ n1 n3
19 END JUNCTION
20
21 Force_Q node table limit
22 6 1 node 1 table limit
23 END Force_Q
24
25
26 END MACROS

Note: the line numbers have been added to aid in referring to a particular line. They are not part of the input! The block is used to define what are called instructions and macro instructions. Both are instructions; a macro instruction is just a higher-level construct. Line 9 is an example of defining an instruction. This associates the identifier, EqZ, with the number 3. Code 3 is the equal-water-surface elevation instruction in FEQ. Line 16 is an example of the use of the instruction defined in line 9. Line 17 is an example of the use of a special instruction to force the sum of flows at the exterior nodes at a junction to zero. Notice that line 17 does not contain the number of nodes involved. The instruction, SumQ, counts the number of arguments that it has and then supplies the number of nodes to FEQ. Line 12 shows how to define an instruction name that does the same thing as SumQ. The difference is that the instruction name is followed by two numbers instead of one number like the other instructions. The first number is the Code value to be used, 2. The second number is always 3. This defines the proper internal value so that the command being defined will place the number of nodes in the proper place for FEQ.

An example of a definition of a macro instruction appears in lines 15 through 19. It represents a junction involving three nodes. There are then three arguments following the macro instruction name. Each of these arguments appears one or more times in the body of the macro instruction, lines 16-18.

The macro instruction definition is completed by the END statement in line 19. Line 13 shows that the definitions can also appear in a file. The key word FILE is reserved. You should not try to name an instruction using this word. Neither should you try using the word END. The contents of the file, TEST.MIF, follows: (note: MIF or mif is the suggesting extension for a file containing macro instructions--Macro Instruction File.)
1 Bran A1
2 1 A1
3 END Bran
4
5 Rating node table datum width
6 4 1 node -1 node table datum width
7 END Rating

Lines 1-3 define a name for the branch code option. Lines 5-7 define a name for the rating table option for a one-node control structure.

Here is an example input that uses some of the above definitions:
1 NEW NETWORK-MATRIX CONTROL INPUT
2 CODE N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 F1 F2 F3 F4 F5
3 Force_Q U1 100 *
4 Bran 1
5 Bran 2
6 Force_Q U2 102 *
7 JUNCTION D1 D2 U3
9 Bran 3
10 Rating D3 110 103.0 32.0
11 -1

The first thing to notice is that the old headings don?t work anymore. We will need to develop new methods for structuring the input. With a careful choice of names and macros, the input should be much easier to develop and read. Notice also that the place-holder, the asterisk, is required for the Force_Q macro if we want to leave a blank for the F1 value. If a F1 value is supplied it must have a decimal point in it. Otherwise FEQ will treat it as if it were a N5 value which is not what we want! A place holder is required because FEQ requires that the number of actual arguments, the items given after the macro name in the Network-Matrix Control Input, must be the same as the number of dummy arguments, the identifiers given after the macro name in the Define Macros Block.

Here are the current general rules for defining instruction and using them:

1. All names and dummy arguments must be identifiers. A dummy argument is an argument following the macro name in the Define Macros block. For example line 1, Bran A1, in file TEST.MIF has one dummy argument, A1. The macro instruction in line 5, Rating, has four dummy arguments: node, table, datum, and width. An identifier in FEQ is a sequence of alphabetic and numeric characters with the first character being an alphabetic character. The following characters are added to the alphabet and are considered to be alphabetic: underline, _, slash, /, and the back slash, \. The colon, :, and period, ., are considered to be numeric. This means that an identifier must have a first character taken from the letters a through z, underline, slash, or back slash. After the first character the digits 0 through 9 and the colon and period plus any of the extended alphabet can appear. Using this definition, a file name in either DOS or UNIX format can be treated as an identifier.

Here are some examples of valid identifiers for FEQ:

d: \usf\feq\test\test.mif BRANCH Branch CS CS_2D

Note that case is important. BRANCH and Branch are NOT the same.
Here are some examples of invalid identifiers:

1234 (Invalid because first character is a digit. This is a valid file name in DOS.)

CS-2D (Invalid because the special character, -, is used.)

:a45 (Invalid because the first character is non-alphabetic.)

2. The current maximum length of an identifier used as a macro instruction name, an instruction name, or a dummy argument is 16 characters.

3. An identifier used as a file name can be up to 64 characters counting all characters, that is the drive letter, colon, and slashes and the period are counted as part of the limit of 64.

4. The actual arguments can be anything required by FEQ. They can be table numbers, node labels, etc. However, any number that is a measurement and not a counting value or label should have a decimal point. This is needed so that the column-free input can be processed properly.

5. The number of actual arguments and dummy arguments must match. If an actual argument in the sequence is to be passed over, use the place-holder, the asterisk, for that argument.

6. Comments can appear in a macro definition but they will not be transferred to the usage of the macro.

7. Currently the special instruction, SumQ also has the following aliases: SUMQ, SQ, QSUM, and sumq. These are coded within FEQ. If you do not like any of these names, you can define your own as outlined above. Note: The update for the input description is given below after additional features have been added to the macro instruction facility.

Version 8.86
 
January 30, 1997
--Further extensions have been made to macro instruction processing. Four operators have been defined for the construction of identifiers and numbers to use as arguments. The operators are:

addition:        denoted by +
subtraction:     denoted by -
replication:     denoted by *
concatenation:   denoted by |

Here is an example of using some of these operators. Again the numbers for each line are not part of the input to FEQ-they have been added for reference.
1 ; Macro for a gravity connection via one path to a LPR
2
3 SWCG_1 nup ndn swcid lprtab hdatum
4 13 D|nup U|ndn
5 SumQ D|nup U|ndn F|lprtab-7000
6 LPR lprtab
7 6 1 F|lprtab-6900 1 0 0.0
8 5 6 F|lprtab-7000 D|nup F|lprtab-7000 2*swcid+4200 hdatum
9 END SWCG_1

This macro has five dummy arguments. They have the following meaning:
 

nup - branch number upstream of the two-branch junction

ndn - branch number downstream of the junction

swcid - surface water connection identification number. Is in the range of 1001 through 1099. Identifies a culvert

lprtab - table number for a level-pool reservoir that will be connected to the two-branch junction using the culvert defined by the swcid number.

hdatum - datum for head for the 2-D table describing the flow


Line 4 shows the use of the concatenation operator where we construct the labels for the nodes on the branches in this junction. Notice that the concatenation operator appears with no spaces. The concatenation operator must always be next to the items that are to be concatenated.

Line 5 shows an example of using the subtraction operator. We need the downstream node on the level-pool reservoir. The node ids have been selected so that we can compute them from the capacity table number of the level-pool reservoir. In the current case all of the reservoir capacity tables have table numbers in the range 7200-7299. This means that all level pool reservoirs to be used with this macro instruction will have downstream nodes in the range of F200 through F299. The argument: F|lprtab-7000 is evaluated in the following

1. lprtab is replaced by its numeric value from the actual argument.

2. The subtraction is done to yield the value in the range 200 through 299.

3. The concatenation operation is done last to form the free node id in the range of F200 through F299.

Line 8 shows an example of all four of the operators. The replication operator repeats an item. The order of operation must be kept in mind. The replication operator has the lowest precedence. That is, it is always done last. Thus the argument: 2*swcid+4200 is evaluated as follows:

1. swcid is replaced by its numeric value from the actual argument.

2. The subtraction is done to yield a number in the range of 5201 through 5299.

3. The replication operator is done to produce two instances of the argument. Line 7 creates the upstream free node id for the level pool reservoir. In this case the upstream free node id has a numeric portion that exceeds the numeric portion of the downstream node id by 100. The rules for evaluation of the operators, including the implied operator of value replacement is as follows:

1. Replace all identifiers with the proper numeric value. If an identifier has an unknown value it is retained and a warning message is issued indicating that the value is unknown and it may cause later errors.

2. Do the addition and subtraction operations. Note that these must take place on numbers NOT on identifiers.

3. Do the concatenation operation.

4. Do the replication operation. There can be no spaces next to any of the four operators. Also these operators are always binary; that is, they are between two items. (Note: Input changes given below.)
--The output of the tributary area has been changed so that the format is varied to produce the maximum precision value that will fit in the available space.
--An additional option for controlling output of the iteration log has been added. A value of 2 for MINPRT will output the iteration log whenever the non-convergence condition arises.
--Two-way pumps have been added to FEQ. A two-way pump is a pump designed such that the water can be moved in either direction. This does not mean that the pump is reversible but that it has extra gates or valves near it that allow the water to flow through the pump in a single direction while directing the water in either direction, depending on the gate setting.
The following assumptions are made to make implementation simple:

1. The losses in conduits/channels used to connect the pump to the flow system are assumed to be such that they are the same for both directions. That is, FEQ assumes that the pump, whatever its means for changing the direction of the flow, is symmetrical with regard to the losses.

2. The pump rating is the same in both directions.
The direction given in the Code 5 type 3 instruction for the pump defines the default direction. That is, if the speed of the pump is > 0, then it is pumping in the default direction. If the speed of the pump is < 0, then it is pumps opposite to the default direction.

The input for a two-way pump is the same as for a one-way pump. This was the reason for the simplifying assumptions: to keep the changes to a minimum. The major changes were made to permit user control of two-way pumps.

Recall that a one-way pump is controlled by using tables that give its speed as a function of the control value: flow or elevation of water surface. Let SPD be the value of found in these functions. The following rules govern the speed setting for one-way pumps:

1. If SPD > 0, then if the pump is off, it is turned on at the given speed, SPD. If the pump is on, its speed is set to SPD.

2. If SPD=0, then the speed of the pump is unchanged.

3. If SPD < 0, then the pump is turned off if it was on and remains off if it was off.

These rules remain the same for one-way pumps. However, control functions like this will no longer suffice for two-way pumps because the rules for speed of the pump must now define the direction of pumping as well. Therefore, the rules for the control tables for two-way pumps have been changed. This means there are now two kinds of control tables for pumps: those for one-way pumps and those for two-way pumps.

In order to control two-way pumps a tolerance value at near zero speed was defined. This value is 0.01. No pump will likely operate at 0.01 of its maximum speed and therefore this value has been taken as a special value for the control of two-way pumps. This value is called PUMP_EPS and is used in a pump-control table to define pump speed as well as direction.

A pump control table for a two-way pump can have speeds that are negative as well as positive, always limited so that -1 <= SPD <=+1. However, we need a value that defines a null zone for both positive and negative speeds. For a one-way pump the null zone is defined by SPD=0.0 but that is not adequate for two-way pumps because we have no way for turning the pump off and on. The following rules for the meaning of a value from the pump control table (function) for a two-way pump is as follows:

1. When SPD > PUMP_EPS the direction is the same as given by the user in the pump instruction. The pump speed is set to SPD.

2. When SPD < -PUMP_EPS the direction is opposite to that given by the user and the pump speed is the absolute value of SPD.

3. If SPD = -PUMP_EPS or SPD = +PUMP_EPS then the pump direction and speed remains unchanged. This is the null zone value for control of a two-way pump.

4. If -PUMP_EPS < SPD < PUMP_EPS, that is, if SPF is within the tolerance interval about zero defined by PUMP_EPS, then the pump is turned off.

An additional block type for two-way pumps has been added to the existing block types of PUMP and GATE. The following input fragment from an existing model shows examples of a control block for a one-way pump and a two-way pump.

The format of the block is the same for both but the contents of the control tables will differ.
BLK=00001
BLKTYPE=PUMP ____SPEEDS= 4
MINDT=3600.
PINIT=0.0
BRAN NODE _KEY MNRATE RISE FALL ONPR OFPR _C24T LPR 7224
___0 D215 ELEV __0.10 _101 _101 __4 __1
___0 F324 ELEV __0.10 4224 4224 __3 __2
-1
BLK=00002
BLKTYPE=PUMP2WAY SPEEDS= 4
MINDT=3600.
PINIT=0.0
BRAN NODE _KEY MNRATE RISE FALL ONPR OFPR C24F LPR 7207
   0 D311 ELEV   0.10  102 102  5  2
   0 F207 ELEV   0.10 4207 4207   3   4
   0 F207 ELEV   0.10 6207 6207   1   6
  -1

The SPEEDS option has been added to the pump control blocks also. It gives the number of speeds that are allowed and only those speeds will be used. In these two examples, the number of speeds is 4. Thus the only non-zero speeds used will be 0.25, 0.50, 0.75, and 1.0. If a control table requests a speed of 0.05, it will be rounded up to 0.25. Thus the minimum non-zero speed is 0.25. Other speeds will be rounded to the nearest valid speed. This avoids having the pump be set at some small value that represents only a trickle of water compared to its actual operation.

--Multiple control blocks can now be used for one control structure. Here-to-fore only one control block per structure was permitted. Thus seasonally varying rules for structure operation were cumbersome and required multiple runs of the model, each with the proper operation rule for the season being run. There is still the restriction that only one control block is active at any given time.
Support for this option was added as follows:

1. The block numbers for the control blocks to be used for the structure are placed in a time series table of type 7. The block numbers are integers but function tables will treat these numbers as having a decimal point. To obtain a block number from these tables FEQ rounds the value obtained from table lookup to the nearest integer. This insures that block numbers in the time series table will be integers before they are used as a block number in the operation of the control structure.

The block numbers are repeated in order to represent seasonal variation of operation rules. FEQ implements the more general case where the operation rule may also change over time. Thus the special case of seasonal repetition of operation rules requires a small increment of effort in creating the table.

The following table gives an example for control of a sluice gate with two different rules: one for the dry season and the other for the wet season. Notice that each rule appears twice in succession in the central part of the table body. The transition between rules takes place over a one-day period. The division point is then at noon in that day, since the interpolated value from the table will have a fractional value. For example, on May 15, 1980, the day will begin with block number 32 active. At noon the interpolated valuefrom the table will be 31.5 with some small roundoff noise. If that noise is such that the number is 31.5 or slightly greater, then the rounded value will become 32. On the other hand, if the number is slightly less than 31.5, the rounded value will become 31.
 
TABLE#= 200
TYPE= -7
REFL=0.0
YEAR MN DY HOUR OperBlk Select operation block for S-49
1979 10 14       0.0     31.
     10 15       0.0     32.
1980 05 15       0.0     32.
        16       0.0     31.
1980 10 14       0.0     31.
     10 15       0.0     32.
1981 05 15       0.0     32.
        16       0.0     31.
1981 10 14       0.0     31.
     10 15       0.0     32.
1982 05 15       0.0     32.
        16       0.0     31.
1982 10 14       0.0     31.
     10 15       0.0     32.
1983 05 15       0.0     32.
        16       0.0     31.
1983 10 14       0.0     31.
     10 15       0.0     32.
1984 05 15       0.0     32.
        14

The control block selection table must cover the entire time span of the period being simulated. If a new rule is introduced at some time during the simulation its number is added at the proper point in the selection table.

In the instruction for the control structure in the Network-Matrix Control Input (NMCI) the table number for the selection table is given instead of the block number for the control block. The table number must be larger than any valid control block number. Otherwise, FEQ will assume that you are providing the number of the control block and not a control-block selection table. This number is given by the parameter, MNBLK, in the INCLUDE file ARSIZE.PRM. Its current default value is 50. Thus with this default for the maximum number of control blocks, any table number larger than 50 will signal FEQ that a control-block selection table is being referenced instead of just a control-block number.

An example is given here, taken with comments from an existing model. This example is of a sluice gate, not subject to tailwater influence, so that it could be represented by the Code 4 type 5 instruction in the NMCI. This example makes use of the column-independent input for the NMCI.
 
; Downstream boundary for C-24 at S-49. This has a special
; operation control block option that refers to time-series
; table, id number 200, that gives the operation control block
; as a function of time.
4 5 D362 -1 D362 420 200 0 0 0 S_49 4.4 ?

--I/O unit numbers are no longer used in FEQ. They were an artifact of Fortran on mainframes. No user of FEQ is known to be on a mainframe at this time. However, old inputs can be left as they are. FEQ will detect the unit number and issue a warning message that they are no longer used and that the number given will be ignored. FEQ assigns unit numbers internally as needed and they should not be of concern to the user. The file name is all that is now required for input. It can be moved to the left as desired.

--The conversion of all upper case error and warning messages to
mixed case messages is essentially complete. However, the documentation of these messages will still have some of them in all upper case. Over a period of time these too will take on mixed case.
 

Version 8.87
 
February 21, 1997:
--Added argument scale factor to the input of function tables of type 2, 3, and 4. This can be useful when building a model in a region that has two differing unit systems, such as a watershed bridging the boundary between the United States and Canada.

An example of using this option is taken from the metric version of the standard embankment-shaped weir coefficient table for paved low-head flow. In this case the value of head is in feet and the weir coefficient is in the unit-dependent form commonly used in the US.

TABLE#= 9994
TYPE= -2
REFL=0.00000000 FAC= 0.5520869 AFAC= 0.3048000
     HEAD WEIR COEF PAVED LOW HEAD WEIR COEFFICIENT
      0.0     2.82
      0.1     2.925
      0.2     2.967
      0.3     2.992
      0.4     3.007
      0.5     3.017
      0.7     3.029
      0.9     3.036
      1.1     3.037
      1.5     3.039
      3.3     3.045
      4.0     3.048
      10.0    3.048
   -1.0
The value of AFAC converts the argument for the table, in this case the head, from feet to meters. There are 0.3048 exactly meters for each US foot. The value of FAC in this case is selected so that when the weir length is in meters and the head is in meters the dimensional weir equation as used in FEQUTL will give the flow in cubic meters per second. FAC is the inverse of the square root of the number of feet per meter.
As with FAC if AFAC is omitted from the input it will be assumed to have the value 1.0. There are 10 columns allocated to the value of FAC and AFAC and columns must be honored.

--Changed the error reporting when function tables of type 3 are checked to make sure that the value of the function agrees with the derivative. In previous versions discrepancies larger than 2 per cent for the function value as computed from the derivative by the trapezoidal rule caused a warning message to be issued. If the function value is given as zero or left blank, NO warning is issued. FEQ computes the value for the function from the derivatives and places the result in the table. The first value of the function, that is the one for the smallest argument, is taken to be correct. If left blank its value is zero. This is probably the preferred option and avoids computing the function value.

--Added single line option to Special output. Selected by using a heading that begins with the word "special" given as "Special" and not as "SPECIAL". Optional output is not supported in single-line output because it conflicts intrinsically with it. Two columns are produced for each output point to report the flow and elevation at the node.

Version 8.88
 
April 23, 1997:

--Added initial support for output to GENSCN and other similar programs. See Kittle and others (1998) for more information.


Version 8.89
 
May 5, 1997:

--Added checks for missing FREE nodes input block based on problems at the introductory short course.

--Added checking for premature end of a function table to try to make error reporting more intelligible. Again based on problems found at the DuPage introductory short course.

--Corrected error in one invocation of ERR:207 that caused a runtime Lahey error message. Proved to be most disconcerting to new students!


Version 8.90
 
May 23, 1997:

--Adjusted various output formats to better display the results when the metric system of units is used. May affect programs that read the ASCII output for plotting or other actions.

--Changed the initialization for tracking the extreme values. The minimum value was being missed because previous versions did not check the results at time zero but at the end of the first time step. This should have a minor effect on any existing results since minimum flows are often of no interest.

--Checked a simple model using one LPR and using both metric and US standard unit systems. Values are equivalent at the points checked. The metric option appears to function in FEQ. Comparison between unit systems must be made with some care. Here are the points to remember:

1. FEQ selects the unit system based on the value of GRAV in the input. The metric value is approximately 9.8 meters/second/second and the US value is approximately 32.2 feet/second/second. However, in making a comparison between outputs the full single precision conversion of one unit to the other MUST be used in order to minimize annoying differences in results. Thus if the value of gravitational acceleration in the US system is given as 32.2 then the value in the metric system should be 32.2/3.2808399 which is about 9.814560. These differences will be small if this is not done but there is no sense in adding noise to the comparison.

2. Make sure that all unit conversions are made to the maximum precision that the input field will allow. For example if a conduit is 3 feet in diameter, the diameter in metric becomes 0.9144 not just 0.91 or 0.9 even though these later two values are probably just as accurate as the exact conversion.
Note that this conversion is exact in this case. The US inch has been defined as exactly 0.0254 meter for some time now. This means that the US foot is exactly 12*0.0254 = 0.3048 meter.

3. A more subtle problem is the constant used in Manning?s equation in FEQUTL. Apparently the equation was originally formulated in the metric system with the value of roughness selected such that the factor was 1.0 exactly. When this equation was converted to the so-called English system of units, the value for the roughness was left unchanged but a non-unit valued multiplying factor was added. The conversion factor was the cube root of the number of feet in a meter often given as 1.486 or 1.49. A more exact value is 1.485918577. FEQUTL has used the value 1.49 since its creation because that is within 0.3 per cent of the exact value. The value of the Manning?s n in any case is uncertain by at least an order of magnitude more. However, in making comparisons, this small error in relative terms can cause the flows to differ by more than one would expect from roundoff alone. FEQUTL has the option to
request that a more exact value of the conversion coefficient in Manning?s equation be used. This should be done when making comparisons between unit systems to verify that all is functioning as expected.

Back to section 13.1 Run Control Block-- Run Control Table, Franz and Melching (1997a), p. 148


Version 8.91
 
June 4, 1997:

--Output of the order of equations in the network matrix encountered a runtime error if more than 7 nodes were involved with a Code 2 instruction. Increased support to 8 nodes by making the output string longer.


Version 8.92
 
June 18, 1997:

--Added a common block, version.com, to permit tracking and printing the FEQ version at more than one place. Currently used to place the current version into the GenScn files.


Version 8.93
 
July 8, 1997:

--Metric units and HECDSS for diffuse runoff values will not function properly because no unit conversion is done the HECDSS unit-area runoff intensity values. Currently FEQ assumes that the units for the diffuse runoff values in the HECDSS are inches per time interval and the interval is of fixed length for all files involved. The DTSF files, on the other hand, are assumed to have the runoff intensity in feet per second for the customary US set and meters per second for the metric set of units.


Version 9.00
 
October 1, 1997:

--Fixed bug in subroutine OPER that may have affected resetting of variable geometry structures when the time step was reduced after failure of convergence.

The internal representation of tributary area was reorganized to make support of detention and delay reservoirs possible. Externally the input remains essentially unchanged. The order and nature of the internal computations is different. Limited testing has shown that the differences in results are generally small with extreme values showing occasional variation of one or two units out of 10,000. The output of tributary area has been changed to reflect the internal change. In previous versions, tributary area assigned to a branch in the branch mode of input was allocated among the computational elements based on the length of the element relative to the length of the branch. The tributary output showed the areas allocated to each element. The internal computations also were done element by element. In the current version, the tributary area is not allocated to the elements on the branch, and only the fraction of the runoff is allocated to each element. Thus the runoff total for the branch is computed and then the runoff is allocated to the elements on the same basis as the tributary area was allocated in early versions. This obtains the same result within roundoff but reduces the number of computations. In general the current version retains the tributary area internally as it was given in the input.

A side effect of reorganizing the tributary area representation is that the allocation of space for tributary area was modified. The allocation may prove to be inadequate for some models and only time and experience will yield improved methods for allocating space.

It is no longer required that every branch in the model appear in the tributary area input. Only the branches that have tributary area need appear in the input; other branches may be omitted. This only works if the EXACT spelling and capitalization of the block heading names as given in the manual are used. If they are not used, FEQ will become confused in processing the model description.


Version 9.01
 
October 15, 1997:

--Corrected problem with detection of DEFINE MACROS block to terminate tributary input when one or more branches without tributary area were left out of the input.

Modified summary output of tributary area so that negative tributary area is not included in the basin totals. It is included in the summary for each gage and the total for the basin. Thus the total tributary area given for each gage and the basin will be the total of all positive area given in the input.

Removed some overlooked debugging output in processing macro instructions.


Version 9.02
 
October 17, 1997:

--Found cases in which NEW NETWORK option would not process the terminating -1 at the end of the Network-Matrix-Control Input properly. An incorrect count would sometimes pick up garbage and generate an error message that should not have occurred.


Version 9.03
 
October 20, 1997:

--Changed XSECIN, in COMPROG.FOR, to read both the old and new formats for interpolated cross-section function tables.


Version 9.05
 
December 10, 1997:

--Corrected several format statements that contained a backslash instead of a forward slash. Found in compiling FEQ for a UNIX workstation.

--Updated version string for HECDSS files to report correct version in future when version changes.

For use of directory or file names longer than the DOS value of 8 characters:

Extended-DOS executables fail to interpret long file names properly.
The filename and all directory names must not be longer than 8 characters.

Windows NT executables do interpret long file names properly. However, these executables continue to run more slowly than extended-DOS executables when both are run using Windows NT. In some cases the extra run time approaches 50 per cent of the extended-DOS run time.


Version 9.06
 
February 3, 1998:

--An analysis of non-convergence events is now appended to the output. FEQ counts the number of times that each node appears as the location of maximum relative error in the last iteration of a time step that fails to converge. Thus if all time steps converge no analysis is given.

The following example shows what is reported. The location is given for each occurrence as well as the number and fraction of the total number for each location. This example shows that only 6 time steps failed to converge with the selected time step.

Analysis of Non-Convergence Events
 Exterior nodes appearing as last location of maximum relative correction.
 Node Count Fraction

 Branch nodes appearing as last location of maximum relative correction.
 Branch Node Count Fraction
     93 9333 1 0.17
     90 9010 1 0.17
     89 8909 1 0.17
     79 7913 1 0.17
     79 7914 1 0.17
     79 7915 1 0.17

The analysis is useful in trouble shooting large models with hundreds or even thousands of convergence failures. Nodes that have a larger proportion of a large number of failures should be the focus of trouble-shooting efforts, because there is probably something at or near the node in question that requires closer examination.


Version 9.07
 
February 27, 1998:

--Added additional checking for tributary-area input. Heading lines for the definition of the distribution of tributary area must now have their first non-blank information be NODE or USTAT. Any deviation from these two standard labels will cause an error and the processing will stop. This has been done because omitting a heading line in past versions did not cause an error. This was true of reservoir input and the station-range input. FEQ would merely treat the first line of numerical input as a label and continue processing as if everything were in order. The only signal of trouble would be in the results or in a short fall in the total tributary area.


Version 9.08
 
March 8, 1998:

--Warning 22, discontinuous flow at a flow boundary, was issued in error. Changes to flow boundary handling when the detention and delay reservoirs were added caused this bug. The code has been corrected so that the proper boundary-flow value is used in the checking.


Version 9.09
 
April 2, 1998:

--Added an additional option to the generic underflow gate Code 5 Type 9 command for the Network Matrix Control Input. The addition is an optional gate-efficiency factor table and the flow node used for the lookup in the table. This was added for the weir-gate on the Elmhurst Quarry diversion weir in order to vary the gate capacity in keeping with the physical model test results. When water flows over the diversion weir, apparently the approach flow to the gate is distorted such that the flow through the gate is reduced significantly. The efficiency of the gate decreases as the flow over the weir increase. Eventually, at close to maximum flow over the weir, the gate allows water to flow back into Salt Creek.

The added input is in integer position 9 and 10. The fragment below shows the format
                                     This is integer position 9 and it
                                     contains the table number of the
                                     gate-efficiency factor function table.
                                     |
     5 9 F56 F95 F56 001ELMG 550 550 40 F96 660.00 7.0
                                        |
                                        This is integer position 10 and
                                        it contains the exterior node
                                        id that defines the flow used
                                        to lookup the gate-efficiency factor.

A gate-efficiency factor table example is: 

TABLE#= 40
TYPE= -2
REFL=0.0
 DivertedQ Gatfactor Gate-efficiency factor for Quarry weir-gate
   -100.0        1.0
      0.0        1.0
    350.0        1.0
    560.0       0.37
   1420.0       0.26
   1490.        0.24
   1660.        0.0
   5000.        0.0
  -1.0

In this case the argument is the total diverted flow, including both the flow over the weirs and the flow through the gate. The gate can discharge a maximum of about 350 cfs before water flows over the weirs. Notice the sharp decline in gate efficiency when flow over the weirs begins. The negative argument is used to make sure that a small negative flow which could arise via roundoff, does not cause an error condition. Also the high flow of 5000 is also present to prevent table overflow.

The gate factor is fixed during a time step at the value of the diverted flow that existed at the start of the time step. This avoids feedback onto the gate during the solution process. Given the time steps normally used and the flow variation normally encountered, this assumption should not distort the results significantly.


Version 9.10
 
April 15, 1998:

--Added additional check for cross-section table numbers to detect a missing table at the last node on a branch. Existing checks did not flag this as an error and the program later failed with a subscript out of range system error.


Version 9.11
 
June 5, 1998:

--Added new item to the Run Control Block, TAUFAC, a tributary-area unit factor, to allow FAC in the Tributary-Area Block to be used for purposes other than unit conversion. Many users have already used it in such a role. TAUFAC follows immediately after SFAC. If not present FEQ will assign a value of 1.0 to it. It need not be present. However, if it is present it must be spelled exactly as given here. Errors in spelling will result in a failed run or some other incorrect result. An input fragment follows:

.
.
.
MAXIT= 30
SFAC=1.0
TAUFAC=5280.0
QSMALL=10.0
IFRZ=00009
.
.
.

The rule for setting the value of TAUFAC is as follows:

  1. Determine the linear factor for tributary area required to convert it to the internal units used by FEQ: square feet if GRAV is in the range of 32.2 and square meters if GRAV is in the range of 9.8. For example, if the tributary area is in square miles, then the linear factor is 5280. 5280^2 then gives the conversion factor. If the tributary area is in acres, then the linear factor is 208.71033, that is, the square root of 43,560.

  2. Divide the linear factor for tributary area by SFAC. This gives the value of TAUFAC.

Here are some typical examples:
  Trib     Trib     SFAC      TAUFAC
  Area     Area
  Unit     Linear
           Factor
------- --------  ------ -----------
  mi^2    5280.0   1.0      5280.
  mi^2    5280.0  5280.       1.0
  mi^2    5280.0  100.      52.80
  mi^2    5280.0  1000.     5.280

  acres  208.71+  5280.     0.03953
  acres  208.71+  1000.     0.2087+
  acres  208.71+  100.      2.0871+
  acres  208.71+  1.        208.71+

The above values assume that FAC is 1.0 or has a value unrelated to the conversion of units.

The logic for these values is as follows:

  1. FEQ ALWAYS multiplies the tributary area values given by the user by the square of SFAC. The default assumption is that the area unit for tributary area is given by a square that is SFAC by SFAC feet (meters) in size. Thus if SFAC is 10 the area units are assumed to be 100 ft^2.

  2. The internal value of tributary area used by FEQ is

      (user input value)*SFAC^2*TAUFAC^2*FAC. This number 

should be the area in square feet (square meters).

This addition permits a free choice of the values of FAC, SFAC, and the units for tributary area. This gives considerable power but must be done correctly. Be sure you have the correct values for SFAC, TAUFAC, and FAC for your application.

IT IS THE USER'S RESPONSIBILITY TO UNDERSTAND WHAT THESE THREE FACTORS DO AND TO PICK THE CORRECT VALUES.


Version 9.15
 
June 18, 1998:

--A number of changes were made in the way the various source files are arranged:

1. The COMPROG directory was changed to SHARE

2. COMPROG.FOR was broken into many smaller units

3. ARSIZE.PRM for FEQ and FEQUTL were combined into one file

4. Several .COM files between FEQ and FEQUTL were the same or nearly so. These were adjusted to be the same and moved to the SHARE directory to be used by both FEQ and FEQUTL.

5. One bug was found in FEQ that occurred on a SG computer. All other compilers did not encounter the problem.

These tasks were done by RS Regan, USGS, Reston. I have made check runs of the modified code and have found no differences. However, there may be options not tested that could cause problems.

April 7, 1999: Bug fixes

--Found that the negative constant-flow boundary condition was incorrectly applied as zero flow for versions released after October 1, 1997. This condition is sometimes used to remove a constant positive base flow elsewhere in the system. The necessary code changes in INPUTUF.FOR have been made. Withdrawing flow by positive constant flow out of a dummy branch works in either case.

--Found an undefined variable in TDLK15. The undefined variable was used in the interpolation between tables of type 13 that define the flow for various gate openings in the flow regime between weir and orifice flow. This slightly affects models using underflow gates.

--Found that SYSGN was undefined in TDTCHK for side-weir tables. This only affected checking for overflow on a two-D table used in Code 14 at the end of the run. Added the proper sign for this case.

--Argument TIME to SET_INITIAL_OPER_BLK when called in FEQ was of the wrong precision. Added SNGL to the TIME argument at this call.

--Found that HECDMY.FOR needed changes to permit null calls. Some program units are called even if the HECDSS is not being used. Added FULL = 0 to UPDATE_DSSOUT_JTIME in HECDMY.FOR. FULL was undefined if HECDMY.FOR was linked into the files.

********************************************************************************
FEQ--User notices and pending bug fixes since Version 8.92
Version 8.92 has been renumbered to Version 9.15 and contains all fixes to 9.15.

The versions below have not been distributed by the USGS.
(FEQUTL notices follow)

********************************************************************************

Version 9.19
 

11 August 1998:

--GENSCN related routine has an error that places the incorrect station and invert elevation for exterior nodes on branches into the FEO file.


Version 9.52
 
November 9, 1999:

--Factor on value in HECDSS files in the INPUT FILES block has a default of zero when it should have a default of 1.0.


Version 9.65
 
March 7, 2000:

--Significant errors found in the STDCX governing-equation option. The error is in the computation of some of the derivatives of the residual function as well as an error in one part of one function- table lookup routine. The governing-equation options other than STDX has little use and therefore some errors have been present for some time. Recommend that users use only STDX until further notice.


Version 9.68
 
April 26, 2000:

--Found case where only a single node was given on a branch and FEQ did not issue any warnings. The model appeared to compute with out error.


Version 9.71
 
August 15, 2000:

--Subtle problem found in the two-D table checking that sometimes omits a table from the list. Also found a bug in that code for multiple tables in one instruction.

Used new feature of the latest Fortran compiler from Lahey to check for undefined variables and subroutine interfaces. Found several undefined variables that are not initialized. Most of them are values that are not used in the computations but are transferred from one variable set to another at the end of a time step. The internal details of the pattern of storage is often ignored at these points to make the transfer faster and simpler.


Version 9.76
 
November 2, 2000:

--Bug exists in TAB option for code 5 type 6 when multiple flow paths are involved. Only the TAB option for the first path was done.


Version 9.80
 
March 15, 2001:

--An error has been discovered in the computation of the Hager side-weir correction factor that has been present in the side-weir routine (Code 14) of FEQ for at least 10 years. The factor is in the correct range (<= 1.0) but has been coded in FEQ to return larger values than are referenced in the FEQ documentation in section 8.1.2.1.3.2 (p. 83) to Hager (1987).

Testing indicates that the effect of the error is most dominant at low heads in the range of 0.2 to 0.4 feet where simulated flows may exceed the correct Hager computation by about 25 percent. At heads near one foot the simulated flows exceed the Hager computation by about 5 percent and at 2 feet or above, the error is approximately 2 percent. Therefore, the effect of the error on existing models depends on the operational head. Because the computed flow approximations over side weirs at low heads have large uncertainties, results from physical model testing are often implemented as a rating in the model instead of using the side-weir routines.

The above error will be fixed in a future FEQ update. To obtain a copy of the fixed code now, send e-mail to h2osoft@usgs.gov or alishii@usgs.gov.

Problem exists in interpolation of cross sections when a bottom slot is present. Recommend that users do not interpolate cross sections when a bottom slot is present.

Problems in code 13 are revealed in a model with highly detailed cross sections. Situations can arise in which there was no inflow or outflow but the solution converges with a noticable difference in water-surface elevation. This was caused by there being a solution with such a difference due to variation of alpha in the energy equation. Further it has been found that the rate of change with depth of alpha and beta were often greatly in error so that the derivatives in the Newton linear system were in error. This caused convergence failure or slow convergence. Most of the time there will be no inflow or outflow and the equal-elevation option avoids any need for table lookup and involves minimal computation. The cross section function table at a code 13 junction should be of table type 22 or 25.

The weighting factor (WT) for the velocity-heard derivative in Code 13 for the conservation of energy option is not applied. When the outflow is large, this error can become large enough to prevent convergence.

The weighting factor (WT) is not applied to the partial derivatives of eddy losses (KA and KD) properly. This can cause convergence failure when there are large changes in velocity. Setting KA and KD to zero allows successful convergence.

Very large models (on the order of 450 branches) may require a double- precision solution in order to converge successfully. Send e-mail to h2osoft@usgs.gov or alishii@usgs.gov if this is suspected.


Version 9.81
 
April 3, 2001:

--There is an error in a format in the end-of-run report on 2-D tables. If the final extreme flow used as an argument to a 2-D table of type 14 is greater than the maximum flow in the table of type 14, then a system message is issued and the run terminated because of an improper format in the process of printing the end-of-run report.


Version 9.84
 
October 1, 2001:

--The point flows block is no longer supported. Point flows should be connected to the model at a junction created for each point flow with a dummy branch added to provide the boundary node to reference the point flow.


Version 9.91
 
May 17, 2002:

--Subtle bug exists in the computation of one derivative in the side-weir code. This appears only if the weight factor on head in the source channel differs from 0.5.

The multiplying factor for the forced-boundary instruction, code 6, is applied to both the base value and the time-series value. The base value serves as a constant lower limit on the flow or elevation at that location.