Working today with databases - alkalides. These are some very curious molecules, in which an alkali metal atom (Li, NA, K, Rb, Cs, Fr) gains an electron, becoming an anion. This is quite strange as usually these atoms just have 1 valence electron, thus the "easier" thing for them is to lose that electron. That's why alkali metals make up most ionic salts (i.e. NaCl). To make these compounds they usually get paired with halogens, which are the atoms who gain an extra eletron (i.e. Na+ and Cl-).

I have yet to check the calculations from monday, here are some of the commands to check them:

database check g16 00*/*uhf*/*.log
# uhf calculations were run successfully!

database check g16 00*/*ub3lyp*/*.log
# ub3lyp calculations were run successfully!

database check g16 00*/*uwb97xd*/*.log
# ub3lyp calculations were run successfully!

While gathering the geometries for issue #34 (alkalides), after some molecules I quickly noticed that the structures provided in most articles are in CIF format or a quite strange C3D (binary) file. I went through IOData's documentation and found that these file formats are currently not supported. Also, most of these molecules don't have a CID, CAS registry number or documented InChI (or at least I have not been able to find them), therefore the CIF or C3D are the available sources for geometries.

After having some discussions with Leila, Prof. Ayers and Farnaz, different solutions werer founded. The first one was that using VESTA it was possible to convert these files to other formats, which could be processed by IOData. The remaining issue is that just converting them to crystallographic information doesn't extracts the molecular portion, which is the one we are interested to take for calculations. It seems that the easiest way to treat them will be to convert them to XYZ format and then manually take the molecular portion. It will be a little bit of trial and error but it doesn't seems very problematic after all.