Databases, Definitions and Models
Three main types of
database/datafile are used in MTDATA. The foundation is provided by the
database source files which are ascii text files identifiable by the
preferred extensions .loa. or .dbl. They are used as the source for
generating the databases themselves each of which comprises a binary
database and an index designed for fast retrieval of data. These have
the extensions .dbs and .inx respectively. Finally, when data are
retrieved for a system they are transferred to another ascii file which
by default is given the extension .mpi. With limited exceptions only
the source files are of interest to the user, since it is to these
files that all calculations are ultimately traceable. Full details are
given elsewhere. It is possible to edit the
.mpi files but this is not recommended. Users can amend and add to
their own databases (.inx and .dbs files) for pure substances using the
THERMOTAB module. For other purposes the UTILITY module must be used.
MTDATA generates a
substantial number of output and working files. Information on these
relevant to their use and management is given elsewhere.
Elements, charge and vacancies
Elements are represented by their normal chemical symbols using upper and lower case.
The electron is
represented by /- and positive charge by /+. The use of two different
symbols for charge avoids the need for negative stoichiometry numbers.
Vacancies are represented by Va. They do not need to be included in lists of components when systems are defined.
Substances of fixed composition
For the purpose of
developing new data substances must conform to the following rules. The
following explanations should be read in detail particularly by those
concerned with the data storage or amendment.
Up to eight elements are allowed in one substance.
Normal chemical conventions are observed for the representations of symbols and formulae.
The phase of each substance is described by appending at least one
symbol to the formula inside pointed brackets <>. The allowed
state symbols are:
<c> condensed, ie liquid or solid, the default option and normally omitted,
<aq> aqueous species,
<g> gaseous species (<g> is expanded to <gas> by ACCESS, MULTIPHASE etc but not by THERMOTAB).
All constituents of
solution phases and some pure substances need to be further defined by
a more definite phase label, for example:
Carbon C<graphite>, C<diamond>
Iron Fe<FCC_A1>, Fe<BCC_A2>
If a pure substance
other than a gaseous or aqueous species has no phase label one is
generated by capitalisation of the formula name on data retrieval, eg
MnO2 becomes MNO2. This does not apply to THERMOTAB.
distinguished by a different convention in which an isomer identifier
is tagged to the formula by an underscore, eg: C2H2Cl2_1,1<gas>,
C2H2Cl2_trans<gas>, C2H2Cl2_cis<gas>. In THERMOTAB or in
files for loading data in to databases a different convention is used
in which the isomer name is contained in the phase label,
Charged species may
be represented by using the symbols for negative and positive charge
exactly as if they were element symbols, ie symbol before stoichiometry
Examples of substance names are:
In general, use of
generic names for phases is recommended. Thus in the last of these
examples ’melilite’ is preferred to
’gehlenite’. On the other hand, if no solution data are
available for mixtures with other melilites, ’gehlenite’ is
the better name to use.
Unary data are
required for end members of solution phases. For this reason it is
convenient to use the word unary as a noun to describe a constituent of
a solution phase. A unary may be a normal stoichiometric substance that
is stable in the pure state: Fe<bcc> and SiO2<alpha_quartz>
are examples. In other cases it may be essentially equivalent but
unstable in the pure state, for example Cr<fcc>. In addition to
these self-evidently necessary unariesit is sometimes necessary to add
hypothetical associated species that are invoked in order to model the
properties of solution phases in which there is strong interaction
between the components. Phases for which there is explicit recognition
of sublattice structure also need to be considered and these require an
extension of the formalism.
Colons are used to separate the sublattices. The formula for normal spinel MgAl2O4<spinel> is written:
Mg/+2:Al/+3:O/-2<spinel:1:2:4> normal spinel
but because real spinel is partly inverse data will also be required for the notional substances:
A combination of the
last two gives inverse spinel. The four substances are the
stoichiometric formulae for the end member constituents, unaries, of a
real spinel of overal lstoichiometric composition. In order to model
the properties of spinels containing more or less MgO or Al2O3 than the
1:2 ratio a third sublattice for cations and the possibility of
vacancies on cation sublattices may be introduced. These are also
required for oxygen deficient or oxygen excessspinels.
In the above
examples the species Mg/+2 on the second sublattice is identified in
MULTIPHASE as Mg/+2:2<spinel>.This symbolism is used in the data
files generated by ACCESS. There is no facility for identifying the
individual sublattices by their structural position in the crystal
lattice so care needs to be taken to maintain consistency in the order
of assigning data to the various combinations.
As seen from the
examples above the unaries necessary to model certain phases may carry
a net charge and may have vacancies on one or more sublattices. The
user should refer to ACCESS and UTILITY pages for further
Interactions in solution
The user does
not normally have to write down "formulae" identifying particular
interactions in solution. The solution data are retrieved automatically
by ACCESS. Unlike the unaries they are not identified in the list of substances and of course they are not assigned any mass in the results of calculation.
Thus the user needs to be aware of the existence of
interactions only in the development of new binary or higher order
interaction data. Reference should be made to the UTILITY and ACCESS pages for further information. Following normal convention, mixing in a phase as
a whole or on an individual sublattice is indicated by commas
separating the species that are mixing. Sublattices are separated by
colons in the same way as for unaries. Mixing generally occurson only
one sublattice at a time. Examples are:
The first example is a simple solution between Fe and Ni in the liquid phase. The second relates to mixing between the last two of the unaries of spinel given above. The third example refers to interactions between ferrous ions and vacancies in wüstite, which is given the generic phase name ’halite’. It would also be necessary to consider interactions between ferrous and ferric ions and between ferric ions and vacancies.
The generation of data for loading in to a database
needs more detailed information than is given here. Reference should be
made to the UTILITY pages. More general information on terminology is given in the Glossary.
Thermodynamic models used in MTDATA
The temperature and pressure dependence of the Gibbs
energy and interactions between the constituents of solution phases are
described by mathematical models. Those used in MTDATA are well
established in the scientific literature and are supported to varying
degrees by a body of data. They are incorporated in a modular way into
the software anddata structures. The models include:
The Murnaghan model for the thermodynamic data as a function of pressure.
The Inden model formagnetic contributions.
The compound energy model allowing solution on the individual sublattices of crystalline compounds.
The associated solution model for liquids in which there is strong bonding between the components, the bonding having a significant covalent character.
The two-sublattice ionic liquid model used for molten salts and other mainly ionic systems.
The extended Redlich-Kister model for predicting the multicomponent thermodynamic data of non-ideal solutions including those on individual sublattices.
An extended Kapoor-Frohberg model for slags.
The Quasi-chemical model
The Pitzer model for aqueous solutions
Updated 26 May 2010