[ANN] Mendeleev.jl - accessing chemical elements data

I am excited to announce Mendeleev - a database of chemical elements. The package is API compatible with the venerable PeriodicTable, but contains data on much more properties (about 100), including e.g. atomic and ionic radii, ionization energies, isotopic composition etc. The data are mostly taken over from the Python mendeleev package, and the data sources are documented therein.

For more information see the package documentation. The package has already been registered a while ago, but by now I’ve implemented all initially planned features. The API stems from PeriodicTable, which has been stable for long time now, and is not going to change in a breaking way. The current package version is 0.3.0, but the plan is to wait a couple of months and then set it to 1.0.0.


Can’t this effort be merged with PeriodicTable.jl to help the lives of existing users?

1 Like

In principle it can - meaning the PeriodicTable.jl source must be completely replaced by the Mendeleev.jl source. At the start of the project I asked the PeriodicTable contributors, just got no answer. I’m still open to it, however now Mendeleev is so much more extensive as compared to PeriodicTable, I’d prefer it keeps it’s identity and PeriodicTable docs point to Mendeleev as a successor.

As for lives of existing users: just write
using Mendeleev: elements, Element instead of
using PeriodicTable, and you are fine


@Eben60 I found the exact issue in PeriodicTable.jl where you mentioned the new Mendeleev.jl package:

From your comment it wasn’t clear that you intended to merge the package or join efforts, maybe you should state it more clearly or open a new issue with maintainers to do so?

It would be super helpful for the community of users, the more maintainers and collaborators in a big initiative like this the better. It is annoying to maintain so much data alone.

It takes at least two to tango.


You mean that you are not interested in putting your work in PeriodicTable.jl? Because from your comment in that issue there was no explicit sentence saying that you were willing to submit a PR to the package.

Firstly I mean it makes little sense to discuss my intentions without the other side taking part in the discussion at all - I have reached out several times for them. Also, I am not sure the current state of the PeriodicTable.jl can be really described as “maintained”.


I am just trying to avoid yet another split in the tiny community we are already. I am not involved with PeriodicTable.jl but was planning to use it in a project. Now that I know it is not maintained, I will take a look into the alternative.

I do not maintain it is “not maintained”. A couple of PRs I’ve made in the process of re-checking the data were merged. A couple of open issues just stay open. On the other side, the software itself is not going to break on Julia updates, and the data just reflect the physical world - so presumably PeriodicTable will stay just as usable for the years to come as it is now.

Now - may I ask you in which way do you plan to use PeriodicTable? There are some packages using it, but they just use the interface and maybe the atomic weights, and I have difficulties imagining any other serious use. To be honest I don’t see why the physical properties of elemental substances are in any way special.

I will probably need PeriodicTable.jl for basic stoichiometry, nothing sophisticated.

Atomic weights (maybe with an exception or two) are stable over the years. You will be equally well served by any of the both packages.


Actually that’s apparently the only (visible, i.e in a registered package) use of the PeriodicTable: Stoichiometry and the fancy indexing. As these functionalities are the most used, I’ve decided to split out a separate minimalistic package from Mendeleev, with these functionalities only, no dependencies, no extra data etc… Then however I couldn’t resist a temptation to add some sugar onto these bare-bones. The package is already fully functional and to be registered after adding tests, documentation etc.

using ChemElementsBB

K = chem_els["potassium"]
Ca = chem_els[:Ca]
P = chem_els[15] # three ways of indexing similar to PeriodicTable
O = chem_els.O # one more (Mendeleev)

julia> O
Oxygen (O) - element 8, m=15.999

julia> K / (K + Ca + P + 4*O)

Macro to create element-named-variables (doing in effect the same as the code above).

using ChemElementsBB
@import_els K Ca P O

julia> K
Potassium (K) - element 19, m=39.0983

@import_els O:Ca

julia> F
Fluorine (F) - element 9, m=18.998403163

On this basis another separate package for chemical formulas is feasible, along the lines of ChemEquations.jl. The usage then could be like

julia> K/cf"KCaPO4"

Now an off-topic quiz question. With an “an exception or two” I have really meant it, and not on the geological scale. The atomic weight of an element from an old container in lab may deviate substantially from one of a freshly bought sample. Which, why?

Radioactive decay? My first thought was other sorts of decomposition, or if something is hygroscopic, but that’s not exactly the same thing as the atomic weight changing.

no, nothing that dangerous :slightly_smiling_face:

Can any of these packages be used to parse a string like "NaPb2(CO3)2(OH)" into a vector of chemical elements [:Na, :Pb, :C, :O, :H] and a vector of counts [1, 2, 2, 7, 1]?

Appreciate if someone can share some code snippet to achieve this result. Let me know if there is a package to parse formulas like the above.

Not yet, but that is exactly what I was thinking of:

In the meanwhile I’ve just discovered another related package - UnitfulMoles.jl by @Raf

UnitfulMoles parses @compound H2O , but unfortunately fails on @compound NaPb2(CO3)2(OH)

julia> using ChemEquations

julia> c = cc"NaPb2(CO3)2(OH)"

julia> c.tuples
5-element Vector{Tuple{String, Int64}}:
 ("Na", 1)
 ("Pb", 2)
 ("C", 2)
 ("O", 7)
 ("H", 1)

That is great. Do you know if it also works with subscript? _2 I’m far from my computer at the moment, will check when I get acess to it.