Skip to content

SECONDARY_SPECIES

Example

SECONDARY_SPECIES
OH-
HCO3-
H2CO3
END

Explanation

The SECONDARY_SPECIES keyword block gives the user's choice of secondary species for a particular problem. Secondary or "non-component" species are those for which an equilibrium reaction relationship is assumed with the primary species in the problem. In other words, the secondary species can be written in terms of the set of primary species. While the secondary species could be viewed as any species for which there is a reaction relationship with the primary species, whether the reaction is at equilibrium or kinetically controlled, in this code the secondary species are used to imply on species where the reaction is assumed to be at equilibrium. When a particular reaction is at equilibrium, a secondary species can be written algebraically in terms of the primary species concentrations and the equilibrium constant for the reaction using a mass action expression. Thus, the species can be mathematically eliminated as an independent unknown from the conservation equations. In contrast, where the reaction is kinetically controlled, a differential (as opposed to algebraic) equation is needed to relate the species to the other species in the problem. Database Format As with the primary species described above, a distinction must be made between secondary species in the database versus secondary species specified by the user in the input file. The "database secondary species" block follows the primary species block and is initiated with the line marking the end of the "database primary species" block:

The secondary species list provides the additional aqueous species used in a reactive transport problem. If the user selects the database_sweep option in the RUNTIME keyword block, however, the code will automatically load all possible secondary species, ignoring the user's list. However, when this option is selected, the code will stop after speciating the geochemical conditions. To use the set of secondary species generated by the database_sweep option, the user needs to formally copy and paste the secondary species list into the SECONDARY_SPECIES keyword block and turn off the database_sweep option. The list of secondary species generated by the database sweep are found in the output file "'input filename prefix'.out" which is generated every time a run with CrunchFlow is carried out. This is done because of the large number of potentially extraneous species which may be loaded for a particular problem, especially in the case of organics. The disadvantage of the approach is that the user may potentially neglect some important secondary species (i.e., those which have non-trivial concentrations in a particular problem). The recommended procedure is to begin a problem by running the code in database_sweep mode and then winnowing the list of secondary species if necessary. In most one-dimensional problems, the full list of secondary species may be used (with the exception of problems where a huge list of organic species may be loaded).
The format for listing secondary species in the input file is the same as the format for primary species. Secondary species to be included are listed on separate lines within the SECONDARY_SPECIES keyword block. If the database sweep option has been chosen previously, secondary species written to the file "'input filename prefix'.out" may be copied and then pasted into the input file. As with primary species, the input is case-sensitive-the species listed must be found in the database or an error message will result.