Yamdb: Easily Accessible Thermophysical Properties of Liquid Metals and Molten Salts

Introduction

Knowledge of materials properties is a necessary prerequisite for a great number of scientific and engineering tasks, such as designing apparatuses, estimating heat fluxes, ohmic losses and other quantities and is indispensable for many numerical simulations, e.g., in computational fluid dynamics. Correspondingly many material databases exist, typically built to address the needs of a specific field. We concentrate here on liquid metals and fused salts mainly for their application in electrochemical energy storage, i.e., in liquid metal and molten salt batteries [35, 33]. Yamdb was written to offer rapid and easy access to a number of material properties in the liquid state at standard pressure. Typically, the substances useful in this field possess melting temperatures significantly above room temperature.

The scarcity of data on the thermophysical properties of liquid metals compared to, e.g., hydrocarbons is due to the experimental difficulties in obtaining accurate measurements at high temperatures [26]. The same holds true for fused salts. Nevertheless, there are several carefully edited compilations of thermophysical properties of liquid metals [48, 27, 26] available in text. Janz’s collection [31, 28] of molten salt properties from the literature published until about 1988 is a seminal work still held in high esteem [59] even if these data are no longer considered Standard Reference Data (SRD) by the National Institute of Standards and Technology (NIST) [32].

The challenges of building an up-to-date electronic molten salts database containing critically evaluated data are vividly described by Gaune-Escard and Fuller [17, 16]. Assessing data quality and accuracy of reporting is a task that should not be underestimated and that entails considerable resource requirements [6]. Even defining a standardized universal data format for thermophysical properties has proved to be a major undertaking [58].

Our aim with Yamdb is much more modest and focused on molten metals and fused salts: we collect correlations, based on experimental findings, describing temperature dependent thermophysical properties from the literature and make them easily accessible from (interactive) programming environments. So far, Yamdb does not contain any facilities to predict or interpolate material properties. Value judgments of the literature data were not attempted since we lack the necessary resources. Collecting clean data from the literature is thereby the main work. Though it is seemingly trivial, errors easily creep in or are already present in the original sources [53]. Using multiple sources for identical properties wherever possible helps to discover errors. Since such errors are unavoidable and often difficult to detect, correct numbers (or coefficients) are of greater value and have considerably longer lifetimes than the concrete implementation of equations. Both should therefore be stored separately. To keep this asset, an easily editable, flexible, well documented data format with a permissible license and widespread adoption is needed. Longevity is vital as well but difficult to assess.

We decided here for YAML [3, 22, 23] (YAML Ain’t Markup Language™) because it fulfills most of the aforementioned criteria and is a core component of a sufficient number of popular software packages which gives hope for sustained support. In our opinion, YAML strikes a good balance between the complexity of the database format and flexibility.

As mentioned above, over the years a whole series of databases and tools for using thermophysical data have been developed. For a small subset see Table 1. The table collects software and databases from different fields. Driven by demand from the chemical industry, several well established and comprehensive databases with a focus on hydrocarbons exist, e.g., the Dortmund Data Bank (DDB) [54], the ThermoData Engine (TDE) [13] and REFPROP [25] from NIST. They often contain sophisticated modeling capabilities for thermochemical and transport properties especially for mixtures. Cantera [18], PYroMat [40], Thermo [2], and ThermoFun [43] are examples of open source software belonging to this category. The NIST Molten Salts Database [29] is a DOS based program that offers easy access to the collection of correlation equations for the density, dynamic viscosity, electric conductivity, and surface tension of molten salts collected by Janz and co-workers [28]. Recently, NIST made the underlying coefficients and equations electronically available [32]. The Molten Salt Thermal Properties Database (MSTDB) [63] with a thermochemical (MSTDB-TC) and a thermophysical branch (MSTDB-TP) is being actively developed and focuses on the properties of molten salts suitable for the use in molten salt reactors. ThermoML is primarily a data description in Extensible Markup Language (XML) standardized by the International Union of Pure and Applied Chemistry (IUPAC) [14, 15]. NIST provides an archive of material property values stored in their ThermoML Archive [55] with the possibility to access the data in JavaScript Object Notation (JSON) as well. It includes several sets of measured molten salt property values. PyThermoML [19] wraps ThermoML data sets into Python data structures but does not yet – at the time of writing – implement the specification in its entirety. Material properties of molten metals and alloys are available as sets of experimental data from NIST [70] and in a somewhat smaller quantity from the Network Database System for Thermophysical Property Data (TPDS-web) developed by the Japanese National Institute of Advanced Industrial Science and Technology (AIST) [45, 72]. This database also contains data on molten salts. As already mentioned, Yamdb aims to address the specific needs of researchers working in the field of high-temperature electrochemical energy storage with its selection of material property data on molten salts and liquid metals.

So far Yamdb has been used in a number of publications [52, 36, 11, 12, 44, 57, 67] on liquid metal and molten salt batteries as well as on interfacial instabilities [68, 47] in liquid metal systems with a miscibility gap.

Implementation and architecture

As mentioned above, the coefficients for the equations expressing the various properties depending on temperature (and concentration) are stored in YAML files. These files contain a nested structure of block mappings [3] so that the symbol of a substance (element or mixture, ‘Na’ in the example in Figure 1) constitutes the key of the root node ❶. This root node has a number of mandatory child nodes: melting temperature Tm ❷, boiling temperature Tb, and molar mass M. The temperatures are given in K, the molar mass in kg/mol. Thermophysical properties (density ❸, dynamic_viscosity ❼, and expansion_coefficient) are sibling nodes of the aforementioned ones and might or might not be present depending on data availability. The property node with the key density ❸ has two child nodes IidaGuthrie1988 ❹ and Ohse1985 ❻ the keys of which are named according to the references for the original coefficient data: [27, 48]. The child node with the key equation ❺ designates the equation used for the density calculations, in this case

Figure 1

derived from [61] and [27].¹ ρ is the density in kg/m³ at the temperature T in K, while ρ_m is the density at the melting point T_m and λ the temperature dependence of the liquid density in kg/(m³ K).

If the density equation to be used is not explicitly specified however, it would be calculated according to the data from Ohse1985 and the equation Shpilrain1985 because the Ohse1985 block ❻ contains the default key with the value true. A convenient feature of YAML are the ‘anchor’(&)-‘alias’(*) pairs that allow direct access to the coefficients of the density equation according to IidaGuthrie1988 ❹ by the corresponding equation for the expansion coefficient ❽ without duplicated input. The default: true key-value pair is added to the received coefficients.

The presence of several keys in the YAML databases is required: Tm, Tb, M for each substance, the necessary parameters for the respective equations, one and only one default per property, equation per equation record, and reference if the equation record’s key cannot be mapped to an entry in the references database. If available, ranges of temperature (Tmin, Tmax) or fraction in mol% (xmin, xmax) for which the correlations are valid are included as well as information about the accuracy (uncertainty) and a comment for remarks and explanations. Further keys can be added as needed. If necessary, additional methods can be implemented that make use of the content referenced by these keys.

As mentioned above, substances are addressed by their chemical symbols. Ordering of these symbols in compounds is alphabetical. In the case of salts, we follow the convention used by Janz [28] and start the formula with the cationic species, e.g., ‘NaCl’ and not ‘ClNa’ as often found in the newer literature, e.g., [21]. Components of mixtures are divided by a hyphen and ordered alphabetically by compound. The popular mixture of lithium chloride and potassium chloride would therefore be found under ‘KCl-LiCl’.

Alloys are treated in a similar manner, ordering the compounds alphabetically irrespective of their metallic or non-metallic nature and dividing the chemical symbols of the components by a hyphen.

Since YAML is a human-friendly text format, the database files can be conveniently edited in a number of editors and integrated development environments (IDEs) with YAML support, e.g., Emacs with yaml-imenu and yafolding, Geany, PyCharm, and Vim.

Python was chosen for the primary implementation because of its well established role as today’s lingua franca of scientific programming and the truly excellent REPL (Read-Eval-Print Loop) IPython. IPython enables interactive, exploratory work [51] and thus easy and rapid access to the available property methods of the dynamical generated substance objects of Yamdb.

There are of course valid reasons to prefer other languages, e.g., escaping frequent deprecation and breaking changes (even in the core language and libraries) [24, 66] or the desire to use less electricity when performing computations [74].

We chose the Go programming language [10] as a case in point for an alternative implementation of a subset of the Yamdb features in the standalone command-line program Goma (Go materials database). Go has a focus on simplicity and long term maintenance and promises compatibility [8, 7] at the source level for the lifetime of the language. In addition, Go offers, among other things, easy portability by supporting a variety of operating systems and processor architectures via native as well as cross compiling. However, the discussion below will mainly focus on the Python implementation Yamdb.

To minimize maintenance effort and increase the longevity of software, it is crucial to reduce dependencies as much as possible and to select components with proven track records [24]. We have tried to heed this advice and aimed for minimal dependencies besides the essential one on a YAML parser. Other than that, only NumPy and an (optional) BibTeX parser are required third party libraries. The remaining external modules are part of the Python Standard library. There is a long-lasting discussion in the Python community [5] on the right place for a YAML parser with voices [73] calling it “Python’s missing battery”. NumPy is used in the equations for the simple reason that it allows evaluation of thermophysical properties for a vector of temperature values with one function call. NumPy [65, 20] is a fundamental package for scientific computing in Python and therefore not likely to disappear anytime soon. In case of emergency, all calls to NumPy should be replaceable by those to the Python Math Library at the expense of loosing the array computing capabilities. To retain the focus and keep the library at a manageable size, other functionality like plotting via Matplotlib is deliberately excluded.

The overall program flow is shown in Figure 2. The listing below demonstrates how to obtain the value of the density of sodium at its melting point.

Figure 2

After loading Yamdb first, a database object has to be generated from a supplied YAML file (line 5). The main component of this object is a dictionary (sdb.materials; internal use only, not present in the listing) of dictionaries corresponding to the structure of the loaded YAML file. The next step on line 6 is the selection of a sub-dictionary Na_dict whose key ‘Na’ in sdb.materials corresponds to the symbol of the substance to be investigated. In this case it is the element sodium. From this sub-dictionary, the property object Na is dynamically built by a call to yamdb.Properties. This is done by assigning values from the sub-dictionary to the three required constant properties melting and boiling point and molar mass (Tm, Tb, M). Furthermore, for the properties that are implemented in the sub-modules of yamdb.properties and that are present in the sub-dictionary Na_dict, methods are dynamically generated. They select a default equation per property and allow the user to address the non-default equations by the keyword-argument source. If one would like to know the density of sodium according to IidaGuthrie1988 instead of the default Ohse1985 (see Figure 1), one would call rho = Na.density(T, source='IidaGuthrie1988') instead of the simpler line 9. The property object Na now allows one to conveniently access all available property methods by tab-completion at the command line of IPython and recent Python interpreters with access to the readline library. A number of additional methods exist that allow one to extract different kinds of information from the properties object such as listing all available sources for one property (get_source_list) or getting the reference key for a certain source (get_reference).

A more convenient variant of the procedure described above is offered by the function get_from_metals in line 2 of the listing below.

It directly accesses the metals.yml database included in the Yamdb distribution and directly returns the corresponding Property object. The first call to get_from_metals parses the YAML file, and all subsequent calls for other substances use a cached version of the corresponding dictionary.

Mixtures are handled slightly differently because they are not only defined by their components but also by their mole-fractions. Therefore objects of the MixtureProperties class shown below are (transparently) generated by the function get_from_salts if a hyphen is detected in the substance name.

The same is true for alloys and the corresponding function get_from_alloys. Properties are now methods of substance and composition as shown in line 4 of the listing above. Compositions in the dictionary keys are quoted in mol%, the first value (20) is for the first component (CaCl₂), the second (80) for the second (NaCl) and so forth. Composition keys are kept as short as possible, trailing zeroes are removed and values are rounded to one digit after the decimal point. If correlation equations for a continuous range of compositions are available, the composition dictionary key is ‘range’ as in line 7. The property function (density in this case) requires then the fraction in mol% as a second argument. As can be seen from the comment lines 8 and 10 containing the density values corresponding to the method calls in lines 7 and 9 respectively, the results of the two different correlation functions are quite close.

Please note that for the time being, only substance data for the mixture compositions available in the literature can be retrieved from Yamdb. It is planned to add interpolation functions to future versions.

It is essential to check the original sources before using material properties derived from Yamdb in calculations, and publications should cite the original sources. To facilitate these tasks, Yamdb contains a module yamref and a BibTeX database with all references references.bib. BibTeX was chosen because it can be considered a standard format in scientific publishing, interacts readily with LaTeX and has a long history without breaking changes. A number of BibTeX parsers are available as third party Python packages. Yamdb currently uses BibtexParser [69] that depends on PyParsing [41]. At the time of writing, BibtexParser undergoes a major version upgrade that entails breaking changes to the application programming interface (API). In future, Yamref might switch to an alternative solution for parsing BibTeX files but without changes to the user interface. For now, a simple backup solution is provided in form of a YAML file mirroring the content of the BibTeX file. Access to the YAML file with references is provided by functions implemented in Yamdb’s yamdb module. Identity of the information content of both versions (BibTeX and YAML) is covered by an integration test, see section ‘Quality control’.

A simple case of looking up the reference for a density value is demonstrated in the listing below:

get_default_source(’density’) returns the source key of the default source (❻ in Figure 1). It is IidaGuthrie1988 for Ga that gets expanded to the full citation by the call to yamref.get_from_references. The commented lines 6–8 and 11, 12 contain the output of the method calls in lines 5 and 10 respectively. If different sources from the same reference are present, the sources’ keys, e.g., Ohse1985Rec and Ohse1985Exp, are derived from but do not directly correspond to the reference. In such a case, an intermediate call to yamdb.get_reference is necessary.

In contrast to the module Yamdb, Goma is a single program whose output is controlled by command-line switches. The source code is divided into a library of material property functions and the main program. It basically evaluates the arguments passed to Goma and directs them to the proper functions for property evaluation in a switch statement. Goma depends on the Go Standard library and go-yaml v.2 [46]. Thanks to the versatile dependency management tools present in the Go-ecosystem, Goma includes the go-yaml v.2 source via

Goma calling conventions are described by a help screen (goma -h or goma -help, command line flags follow Plan9 standards [4]) and a man page. To get the density of Ca at 1130 K enter the following at the command line:

The available information is returned as a table that is shown in the commented lines below the call to goma. Resolving references is not done internally, only the citation keys are provided in the column ‘source’. Should the user have access to LaTeX and pandoc [39], a shell script gen_report.bash supplied with Goma in the contrib sub-directory can be used to generate an overview of all thermophysical properties available for a substance at a given temperature. A (shortened) example of the script’s output for Li at 800 K is shown in Figure 3.

Figure 3

In addition, the contrib sub-directory contains a couple of small programs that simplify the use of Goma. An Emacs Lisp [38] function allows to call Goma with tab completion from the GNU Emacs editor [60]. Gomatk written in Tcl/Tk [50] provides a graphical user interface (GUI) for Goma that facilitates lookup of material properties and integrates complete references to the literature. Wrappers for Gomatk written in Python and Go are available as well, making its deployment easier.

Quality control

Yamdb uses pytest for quality control. The single property equations are fully covered by unit tests. They check the correct implementation of the equations by calculating a property value for a predetermined temperature with a defined set of coefficients.

Completeness of the references and instantiation of objects are examined by integration tests. This includes ensuring that all citation keys of references.bib are present in references.yml.

Plausibility of the temperature dependency of the properties is tested by comparing (if available) different equations for the same property in one plot. Figure 4 shows an example for the density values of sodium in the temperature range between its melting and boiling points. As can be seen, all correlation equations available from Yamdb collapse fairly well and are in the range of the error margins of the most recent measurements by Khairulin et al. [34]. Measured values included in Figure 4 were taken from the NIST alloy data [70].

Figure 4

The complete script to generate Figure 4 can be found in the examples sub-directory of the Yamdb distribution. The snippet below contains only the essential two loops that plot all density equations available for Na by using Na.get_source_list(’density’) in the first for-loop. The second for-loop iterates through the data downloaded from the NIST alloy database and plots these data points with error bars:

The metals.yml database can be checked by a script check_metals.py delivered with Yamdb in the examples sub-directory that produces a large number of plots comparing the temperature dependent thermophysical properties for each metal between different sources.

An example of molten salt mixture properties is given in Figure 5 adapted from [1]. It shows the surface tension of liquid CaCl₂-NaCl mixtures for different temperatures over the whole range of compositions in the liquid state. In the white areas designated ‘solid’, the mixture is not a pure liquid. Measured values provided by Addison and Coldrey [1] (dots and solid lines) are compared to equations reported by Janz et al. [30] and Janz [28]. Temperature is encoded by color. It is apparent that the earlier reported equations by Janz et al. [30] (dotted lines) miss the measured values by a difference in surface tension γ corresponding to a temperature difference of about 50 K. The newer equations from Janz [28] (dashed lines) fit much better, especially for the lower and higher temperatures. The values computed with the coefficients from the database by Janz [32] are identical to the ones from Janz [28] (dashed lines).

Figure 5

The Yamdb distribution contains the complete script to generate Figure 5 in the examples sub-directory. The excerpt presented below – slightly edited for brevity – contains only the essential program parts for iterating over the CaCl₂-concentrations. Purpose of the get_concentration_surface_tension-function is to return a list of the CaCl₂-concentrations available from the database for the mixture object mix and another list for the corresponding surface tension values at the temperature temp provided by the data source src. The function is then used in the for-loop in line 14 to iterate over the Celsius-temperature values for which experimental data are provided by Addison and Coldrey [1]. The method get_compositions_with_property_source returns the compositions for that information about the requested property (surface tension) is available from the selected source.

It should be emphasized that measurements of the thermophysical properties of reactive liquid media at elevated temperatures are far from trivial and very demanding [42]. Certain differences in the reported and calculated values are therefore expected and simply reflect the experimental challenges.

The YAML databases are checked for correct syntax by using yamllint.

For the time being, Goma’s results for predefined sets of temperature values are simply compared to Yamdb’s output.

Operating system

Programming language

Additional system requirements

No specific requirements.

Dependencies

List of contributors

Tanja Klopper (Helmholtz-Zentrum Dresden Rossendorf) – Development and testing

William Nash (Helmholtz-Zentrum Dresden Rossendorf) – Microsoft Windows port, testing, and language editing

Hirav Patel (Helmholtz-Zentrum Dresden Rossendorf) – Development and testing

Paolo Personnettaz (Helmholtz-Zentrum Dresden Rossendorf) – Development and testing

Norbert Weber (Helmholtz-Zentrum Dresden Rossendorf) – Material property collection and evaluation

Tom Weier (Helmholtz-Zentrum Dresden Rossendorf) – Design, development and testing, data collection

Software location

Archive Yamdb

Archive Goma

Code repository Yamdb

Code repository Goma

Language

English.