I deleted this because I decided that I don't want to deal with it

H -> 1s^1, He -> 1s^2, and so on.

Can be looked up here for example: https://www.ptable.com/

Dear developers,

I happen to find that you may have some misinterpreted atomic masses raw data.

I know that the data is from this repo. Maybe I should also address an issue there. But let me speak here first, as we have Measurements.jl by the same Organization.

Atomic weights provided by IUPAC, which is the data source of Wikipedia, are given in two formats. The first one is [x, y], means the measured value is between x and y, the second one is d.dd(e), means the measured value is d.dd, with standard deviation of 0.0e, or in short, measurement("d.dd(e)") if we use the Measurements.jl package.

However, PeriodicTable.jl gives

julia> elements[:He].atomic_mass
4.0026022 u

While the raw data from IUPAC is 4.002602(2). Apparently, when compile the data for PeriodicTable.jl, the error between parentheses is taken as the last decimal of the mean value, which means the value given by this package is always greater than that by IUPAC.

Hope we can fix it.

Cheers,
Yu

color is missing for everything but Cobalt

Attempting to use PeriodicTable to color scatter points in a plot from imported computational chemistry charge density grid data, I noticed that all colors returned an empty string.

Looking into it, color is only set for Cobalt:

Workaround and proposed solution

As a workaround, I'm using the following list of hex rgb colors (that I got from https://sciencenotes.org/molecule-atom-colors-cpk-colors/) that can be used when plotting.

Conceptually, the color field should IMO return the conventional color used to represent the element. This list of colors should be used to set the color of each element, since the colors are missing from https://github.com/Bowserinator/Periodic-Table-JSON/blob/master/PeriodicTableJSON.json

I'd be happy to PR this.

atom_colors = ("#FFFFFF","#D9FFFF","#CC80FF","#C2FF00","#FFB5B5","#909090","#3050F8",
               "#FF0D0D","#90E050","#B3E3F5","#AB5CF2","#8AFF00","#BFA6A6","#F0C8A0",
               "#FF8000","#FFFF30","#1FF01F","#80D1E3","#8F40D4","#3DFF00","#E6E6E6",
               "#BFC2C7","#A6A6AB","#8A99C7","#9C7AC7","#E06633","#F090A0","#50D050",
               "#C88033","#7D80B0","#C28F8F","#668F8F","#BD80E3","#FFA100","#A62929",
               "#5CB8D1","#702EB0","#00FF00","#94FFFF","#94E0E0","#73C2C9","#54B5B5",
               "#3B9E9E","#248F8F","#0A7D8C","#006985","#C0C0C0","#FFD98F","#A67573",
               "#668080","#9E63B5","#D47A00","#940094","#429EB0","#57178F","#00C900",
               "#70D4FF","#FFFFC7","#D9FFC7","#C7FFC7","#A3FFC7","#8FFFC7","#61FFC7",
               "#45FFC7","#30FFC7","#1FFFC7","#00FF9C","#00E675","#00D452","#00BF38",
               "#00AB24","#4DC2FF","#4DA6FF","#2194D6","#267DAB","#266696","#175487",
               "#D0D0E0","#FFD123","#B8B8D0","#A6544D","#575961","#9E4FB5","#AB5C00",
               "#754F45","#428296","#420066","#007D00","#70ABFA","#00BAFF","#00A1FF",
               "#008FFF","#0080FF","#006BFF","#545CF2","#785CE3","#8A4FE3","#A136D4",
               "#B31FD4","#B31FBA","#B30DA6","#BD0D87","#C70066","#CC0059","#D1004F",
               "#D90045","#E00038","#E6002E","#EB0026","#FF00A0","#FF00A0","#FF00A0",
               "#FF00A0","#FF00A0","#FF00A0","#FF00A0","#FF00A0","#FF00A0")

Partial demonstration of workaround

In my case this looks like this:

atoms = [Dict("data" => elements[atom_num], 
                  "color" => atom_colors[atom_num],
                  "r" => atom_xyz)

then

r = invert([a["r"] for a in sys["atoms"]])
plot(scatter(x=r[1], y=r[2], z=r[3], 
                mode="markers", type="scatter3d", legend=false,
                marker=attr(color=[a["color"] for a in sys["atoms"]]), 
                line=attr(color="black", width=3))
                )

Instead of a Dict{String,Any}, it seems like it would be better to return a custom Element type with typed fields like number, name, and so on.

The basic reason for this is that defining an Element type will provide the information about the fields and their types to the Julia compiler. Otherwise you are forcing any computation that uses element data to be type-unstable.

There are a couple of open issues regarding adding of additional information, which have no progress in part due to laziness of the authors of these issues (myself included).

On the other hand, it seems to me that the internal organization of the information in the package might play a part in it (of course it is totally subjective). Let's say you want to add additional information to existing element type. Then, you have to create a new type with additional fields. Then, you have to go over all the lines where elements are defined and add the data in new fields. Sounds a bit complicated. When you start thinking about adding isotopic information, it gets even more complicated.

The counterpart of PeriodicTable.jl in python community is mendeleev. It is interesting that they store all the data as an sqlite database with several interconnected tables. May be we can take inspiration from that?

In Julia case, I think we might not need the whole database, but we can store the data in a dataframe (or several linked dataframes instead). Overall, it should make working with the information rather convenient. For example, one can add additional fields to the elements by appending a column with the relevant data. One can also leverage dataframe utilities and do all kinds of querying on the information.

This approach also lends itself nice for the purpose of introduction of isotopic information: we can create an additional dataframe which will store isotope-dependent information, and the proton number can be used to establish foreign key relationship with the main dataframe storing the elements.

We can also simply copy the database from mendeleev, provided that its maintainers are ok with that.

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

It would be very helpful to implement isequal and hash in a fast efficient manner since in many uses Element instances are used as keys.

For example:
Base.hash(elm::Element) = hash(elm.number)
Base.isequal(elm1::Element,elm2::Element) = elm1.number==elm2.number

and maybe also

Base.isless(elm1::Element, elm2::Element) = elm1.number < elm2.number

If you just define a

export elements
const elements = ...load elements into a Dict{Int,Element} or similar....

then the contents of your element dictionary can be precompiled in, and you won't need to load the JSON data at runtime.

Then you can just do

using PeriodicTable
elements[8]

to get e.g. the element with atomic number 8.

No need for a get_element function, either, then.

Replace Travis and Appveyor by GitHub CI.

It would be nice to have some data on atomic radii. There are actually many different ways of defining atomic radii (covalent, van der Waals, etc.); check out how the Python package mendeleev organizes this type of data. This is an important addition, as calculations employing atomic radii show up in many molecule manipulations.

It seems appropriate to use Unitful.jl for the dimensionful quantities in the Element data.

I just realized, that Element is a mutable struct. This seems strange, is it intended?

It is very difficult to trace the provenance of the data in PeriodicTable.jl to the primary source. This ambiguity hinders its use for serious scientific work. PT.jl should be able to reference the primary source of all data (publication reference preferably) . It is an important part of the reproducibility and traceability of scientific results. When the data changes, the semantic version number should be updated to reflect this is, from the perspective of a scientific user, a breaking change that I'd need to evaluate to decide whether I want to accept this change.

Currently, PeriodicTable.jl "sort of" addresses this question by referencing Wikipedia. However, this only passes the problem along. For one, since websites change, you need to reference the date the data was downloaded. Second, it makes tracing the provenance of a collection of values tedious and makes updating them difficult. PT.jl shouldn't be using Wikipedia. It should go directly to reference-able primary sources.

First off, this is an awesome package 💯 !

I would like to report that elements[:P].density returns NaN and this is breaking some scripts we are writing in our institute.

Appreciate if you can fix this in your free time. I can also submit a PR if you provide directions.

Measured quantities, like melting points an boiling points, always come (and should be presented) with an uncertainty. What about including these, e.g. by using Measurements.jl?

julia> elements[:Uue].discovered_by
"GSI Helmholtz Centre for Heavy Ion Research"

While the GSI did attempt to synthesize Ununennium they did not succeed according to wikipedia. They also do not claim to have synthesized it. As it seems, no experiment has managed to discover it and it is only a hypothetical element.

Ununennium is the only hypothetical element in PeriodicTable.jl and that is kind of inconsistent. Possible solutions I would see would be:

• Remove it due to being undiscovered
• Add other hypothetical elements and mark them as such
• Change the discovered_by to Undiscovered

Would make sense IMHO. What do you think @rahulkp220, @giordano?

https://github.com/lancebeet/julia-scripts#periodictabletoyjl has a nice interactive visualization of the periodic table based on PeriodicTable.jl.

Maybe we should mention it in the README?

It'd be really nice to have built in constructors/convenience functions that query available atoms for a given property.

IE:

PeriodicTable.Elements("H") == PeriodicTable.Elements(Hydrogen)

or

lookitup(symbol) = [ e for e in PeriodicTable.elements if e.symbol == symbol][1]
e = lookitup("H")

I'm kicking around a package that might benefit from this...

@carstenbauer It's good to have Base.show(io::IO, ::MIME"text/html", e::Elements) method similar to Base.show(io::IO, ::MIME"text/html", e::Element) to display rich periodic table in pluto.jl directly.
I have created Base.show(io::IO, ::MIME"text/html", e::Elements) method for demo purpose.

_clrs = Dict(
	"diatomic nonmetal" => ("#e2eeff", "#0060f0"),
	"noble gas" => ("#ffe7eb", "#cd1d5e"),
	"alkali metal" => ("#d8f8ff", "#00758c"),
	"alkaline earth metal" => ("#ffe7e7", "#d60024"),
	"metalloid" => ("#fef7e0", "#945700"),
	"polyatomic nonmetal" =>  ("#e2eeff", "#0060f0"),
	"post-transition metal" => ("#d6f9e8", "#227754"),
	"transition metal" => ("#f3e8fd", "#6232ec"),
	"lanthanide" => ("#dff3ff", "#003355"),
	"actinide" => ( "#ffe6d4", "#c73200"),
	"unknown, probably transition metal" => ("#e7e7ea", "#3f374f"),
	"unknown, probably post-transition metal" => ("#e7e7ea", "#3f374f"),
	"unknown, probably metalloid" => ("#e7e7ea", "#3f374f"),
	"unknown, predicted to be noble gas" => ("#e7e7ea", "#3f374f"),
	"unknown, but predicted to be an alkali metal" => ("#e7e7ea", "#3f374f"),
)

function _fill_element_data(el::Element)
	clr = _clrs[el.category]
	return """
	<td class="element" style="background-color:$(clr[1]);color:$(clr[2]);">
		<div class="top">
			<div>$(el.number)</div>
			<div>$(round(el.atomic_mass.val; digits=3))</div>
		</div>
		<div class="symbol">$(el.symbol)</div>
		<div>$(el.name)</div>
	</td>
	"""
end

function Base.show(io::IO, ::MIME"text/html", e::PeriodicTable.Elements)
	table = fill("<td></td>\n", 10, 18)
	for el in e
		table[el.ypos, el.xpos] = _fill_element_data(el)
	end
	ht = """
	<table style="width:100%;empty-cells:hide;border:0px;background-color:#ffffff">
			<style>
				.element {
					border: 5px solid #ffffff;
					min-width: 100px;
					height: 100%;
					text-align: center;
					font-size: 10px;
					border-radius: 10px;
					border-collapse: collapse;
				}
				.top {
					display: flex;
					justify-content: space-between;
				}
	
				.symbol {
					text-align: center;
					font-weight: bold;
					# font-size: 5px;
				}
			</style>
	"""
	s = size(table)
	for i = 1:s[1]
		ht *= "\n<tr>\n"
		for j = 1:s[2]
			ht *= table[i,j]
		end
		ht *= "</tr>"
	end
	ht *= "\n</table>"
	print(io, ht)
end

Preview:

Heavily inspired by google preview of periodic table. If you are ok with it, I will create pr.

julia> elements[:N].density
1.251 g cm^-3

that is wrong, it schould be in g/L (1.2506 g/L at STP according to Wikipedia)

The same for all 12 gases

You probably want to overload Base.show for Element in order to display it in a nicer way.

I found in the PeriodicTable.jl thread on discourse that there was already the idea to add the individual isotopes to the elements. Has this idea been followed up at some point?

I believe the source of the atomic weight data is the IUPAC 2021 tabulation. However, there is a subtle misinterpretation of the data in this table that plays through to the values of the atomic weights in PeriodicTable.jl.

The reported uncertainty in the atomic weight column is being interpreted incorrectly.

In PeriodicTable.jl, the atomic weight of Ne is reported as 20.17976u. In the IUPAC table, it is listed as 20.1797(6). 20.1797(6) does not mean 20.17976. It means $20.1797 \pm 0.0006$.
Similarly, Yb has an atomic weight of 173.045(10) or $173.045 \pm 0.010$.

The correct interpretation of the parenthesis at the end is to assume this amount of uncertainty in the final digits of the preceding number.

This error is repeated for all elements with reported uncertainties on the atomic weights.