Avogadro version: latest nightly AppImage
Operating system and version: Ubintu 22.04
I have tried to read in different CIF files from ICSD or created by Vesta. Avogadro shows all the atoms at 0 0 0 coordinates. Openbabel converts CIF to CML with no problem. Then I tried to load to Avogadro CML files and it is the same thing: all the atoms are on top each other at 000 coordinates.
Is this a problem with the Flatpak?
I can test if someone can provide some example files
I’m also curious because the AppImage should be performing CIF => CJSON conversion instead of CML.
So it would help to get both some CIF examples to test, and to know why it’s going through CML.
I do not have FlatPak.
Openbabel does not do conversion to cjson but to cdjson or pcjson. If I try to load pcjson file to Avogadro, it does not recognize the format. If I load cdjson file, it looses crystal unit cell information.
Here is a simple CIF file to play around:
data_nanotube
_audit_creation_method '(3,3) Nanotube -- TubeGen 3.3, J T Frey'
_cell_length_a 7.4762
_cell_length_b 7.4762
_cell_length_c 2.4643
_cell_angle_alpha 90.00
_cell_angle_beta 90.00
_cell_angle_gamma 120.00
_symmetry_space_group_name_H-M 'P 1'
_symmetry_Int_Tables_number 1
loop_
_atom_site_label
_atom_site_fract_x
_atom_site_fract_y
_atom_site_fract_z
C 0.7762 0.5000 0.0000
C 0.8138 0.7061 0.0000
C 0.7762 0.7762 0.5000
C 0.6077 0.8138 0.5000
C 0.5000 0.7762 0.0000
C 0.2939 0.6077 0.0000
C 0.2238 0.5000 0.5000
C 0.1862 0.2939 0.5000
C 0.2238 0.2238 0.0000
C 0.3923 0.1862 0.0000
C 0.5000 0.2238 0.5000
C 0.7061 0.3923 0.5000
@sergbuto Please note there is an issue with the .cif file you share.
The lines about IT 1 / space group P1 are consistent with each other, both describe the lowest space group symmetry at all, even within the triclinic Bravais class generally described by a unit cell of a \ne b \ne c and \alpha \ne \beta \ne \gamma. On the other hand, earlier lines describe a = b \ne c and \alpha = \beta = 90^\circ and \gamma = 120^\circ which is characteristic for the hexagonal Bravais class of considerably higher symmetry than triclinic. Of course, technically you can describe a structure of hexagonal unit cell as a triclinic one, however for one this requires to maintain many more lines in the loop describing individual atoms by (fractional) unit cell coordinates, than necessary. Second, doing so obfuscates symmetry relationships between individual atoms / fragments of molecules, or whole molecules in the unit cell (think routines like ADDSYM in Platon, reference).
Somewhat related to this is a block missing, which explicitly acknowledges the symmetry operators in the unit cell specific to the particular space group (P1, P\bar{1}, P2_1, P2_1/c, etc.) or a space group’s particular setting (e.g., P2_1/c vs P2_1/a) by symmetry operations. These describe internal mirror and glide planes, centres of inversion, proper axes of rotation, rotoreflections, etc in way how to copy-paste the atoms in the loop of
loop_
_atom_site_label
_atom_site_fract_x
_atom_site_fract_y
_atom_site_fract_z
C 0.7762 0.5000 0.0000
C 0.8138 0.7061 0.0000
C 0.7762 0.7762 0.5000
...
to their then new positions. Some programs address this implicitly by reading the Hermann-Maguin symmetry symbol, or/and the IT number. The explicit way however is a block like
loop_
_symmetry_equiv_pos_site_id
_symmetry_equiv_pos_as_xyz
1 x,y,z
in case of triclinic P1. For \ce{ZnS} in the hexagonal wurtzite structure type, it is
loop_
_symmetry_equiv_pos_as_xyz
x,y,z
-y,x-y,z
y-x,-x,z
-y,-x,z
y-x,y,z
x,x-y,z
-x,-y,1/2+z
y,y-x,1/2+z
x-y,x,1/2+z
y,x,1/2+z
x-y,-y,1/2+z
-x,y-x,1/2+z
where e.g., the line -y,-x,z instructs to paste a copy of any atom at any (x,y,z) at the corresponding (-x, -y, z), etc. See as an example the attached .cif by record COD 1011195.
Contrasting to a .cif file about a model based on diffraction experiments, many fields in a «synthetic .cif file» naturally remain unfilled (sample size, wavelength of radiation, ranges of experimentally accessed (hkl), etc.) and in consequence, checkcif reports many more spots to work on. It still is good practice to fill these fields wherever reasonably possible (see IUCr’s cif dictionaries, or programs like encifer (already shipped with CCDC’s community edition of Mercury).
Setting aside @Thomas comments about the format, this converts fine for me on the most recent Mac build as well as 1.101.
While last release version of obabel does not support cjson the copy included in the AppImage, Flatpak, Windows and macOS releases does, and generally conversion goes through, e.g. .cif to .cjson
What would help more than the .cif is the .cml that you seem to get from the AppImage. For example, these are the files I get from the current macOS build. My guess is that both of these work for you in Avogadro?
nano.cjson (2.4 KB)
nano.cml (2.3 KB)
On my Fedora machine this example loads perfectly fine with the 1.101 release, and that goes for both the AppImage and the Flatpak. The nightly AppImage also opens it correctly. So I’m not sure what’s going wrong for you…
Do you by any chance have a separate copy of Open Babel installed on your system e.g. from the package manager?
As I said before I have tried CIF files created by different programs with different crystal structures including the ICSD database. The result is the same, therefore the error is not connected to the content/definitions of CIF files.
It seems that Open Babel was already included in the fresh install of Ubuntu 22.04 because I do not find any records of installing it with the package manager.
I tried to load to Avogadro2 the nano.cjson and nano.cml files. nano.cjson works fine, nano.cml does not work. The same thing as with any other cml file.
I converted the CIF file of the 3x3 nanotube (which I pasted in earlier in the thread) to VASP, loaded it to Avogadro2 and exported as a CIF file. The result is the following:
data_I
_chemical_name_common ‘nanotube’
_cell_length_a 7.4762
_cell_length_b 7.4762
_cell_length_c 2.4643
_cell_angle_alpha 90
_cell_angle_beta 90
_cell_angle_gamma 120
loop_
_atom_site_label
_atom_site_type_symbol
_atom_site_fract_x
_atom_site_fract_y
_atom_site_fract_z
_atom_site_occupancy
C0 C 0.77620 0.50000 0.00000 1.000
C1 C 0.81380 0.70610 0.00000 1.000
C2 C 0.77620 0.77620 0.50000 1.000
C3 C 0.60770 0.81380 0.50000 1.000
C4 C 0.50000 0.77620 0.00000 1.000
C5 C 0.29390 0.60770 0.00000 1.000
C6 C 0.22380 0.50000 0.50000 1.000
C7 C 0.18620 0.29390 0.50000 1.000
C8 C 0.22380 0.22380 0.00000 1.000
C9 C 0.39230 0.18620 0.00000 1.000
C10 C 0.50000 0.22380 0.50000 1.000
C11 C 0.70610 0.39230 0.50000 1.000
Then I open this CIF file created by Avogadro2 and exported it again as CIF file to show what is wrong. The results is the following:
data_I
_chemical_name_common ‘’
_cell_length_a 7
_cell_length_b 7
_cell_length_c 2
_cell_angle_alpha 90
_cell_angle_beta 90
_cell_angle_gamma 120
_space_group_name_H-M_alt ‘P 1’
_space_group_name_Hall ‘P 1’
loop_
_symmetry_equiv_pos_as_xyz
x,y,z
loop_
_atom_site_label
_atom_site_type_symbol
_atom_site_fract_x
_atom_site_fract_y
_atom_site_fract_z
_atom_site_occupancy
C0 C 0.00000 0.00000 0.00000 1.000
C1 C 0.00000 0.00000 0.00000 1.000
C2 C 0.00000 0.00000 0.00000 1.000
C3 C 0.00000 0.00000 0.00000 1.000
C4 C 0.00000 0.00000 0.00000 1.000
C5 C 0.00000 0.00000 0.00000 1.000
C6 C 0.00000 0.00000 0.00000 1.000
C7 C 0.00000 0.00000 0.00000 1.000
C8 C 0.00000 0.00000 0.00000 1.000
C9 C 0.00000 0.00000 0.00000 1.000
C10 C 0.00000 0.00000 0.00000 1.000
C11 C 0.00000 0.00000 0.00000 1.000
I vaguely remember having an issue with the AppImage in the past where it was using the system Open Babel instead of the one bundled with the AppImage. With that being an issue because a system copy generally doesn’t have the patches required to make current Avogadro work properly.
Can you uninstall Open Babel and see if Avogadro can load the files correctly then?
@sergbuto In an instance of Xubuntu 22.04.5 LTS with an AppImage fetched on Saturday, September 20th, I’m able to replicate your findings, i.e. all atoms displayed (0,0,0). This equally applies to .cif provided by the COD, too; indeed, reading this model and saving the molecule as .cml yields an atom array of
<atomArray>
<atom id="a1" elementType="Ir" xFract="0" yFract="0" zFract="0" />
<atom id="a2" elementType="Cl" xFract="0" yFract="0" zFract="0" />
<atom id="a3" elementType="N" xFract="0" yFract="0" zFract="0" />
...
For those in the know, the archive below documents a few tests.
Two additional notes (both unrelated to the bug):
_chemical_name_common ‘’ or _space_group_name_Hall ‘P 1’) use single quotes. Depending on the font used, the ease to discern them varies.2025-09-21_replication.tar.gz (287.2 KB)
Thanks.
Just to check if you use the DebiChem install of obabel I assume that CIF => CML works okay? (i.e., is this a bug with the AppImage or an older version of obabel?)
@ghutchis By check of the md5sum, in Xubuntu 22.04.5 LTS the conversion of the .cif to yield the .cml by the current nightly build of Avogadro2 is not affected by the presence or absence of openbabel. However, Avogadro2 yields a .cml file different to the one by openbabel, either 3.1.0 (in Xubuntu 22.04.5 LTS) or 3.1.1 (in Debian 14/forky, no Avogadro2 present). The output by obabel by version 3.1.0 and 3.1.1 did not change (cf. meta_log.txt and the sub folders’ individual logs).
conversions.tar.gz (41.8 KB)
My Ubuntu 22.04 (it was a fresh install but not an upgrade from 18.04) has Open babel v.3.1.1.
A conversion from VASP (converted from CIF shown in the beginning of the thread) => Open babel => cml produces the file which is the same as nano.cml from Avogadro2 on Mac.
A conversion from VASP => Avogadro2 (AppImage) => cml produces the file different from nano.cml.
Likely the selection of programs installed by default in Ubuntu xx.yy.z and Xubuntu xx.yy.z set to be light weight not only differs about libraries around the desktop environment, but applications.
Ok, and what happens if you uninstall that version of Open Babel and then try to open the files in Avogadro?
I prefer to avoid making this kind of changes in the system in order to find out why some function of the program does not work properly.
Well ok, but if that is the issue – that Avogadro in AppImage format finds and uses the Open Babel 3.1.1 on the system before the patched version included in the AppImage bundle, and therefore can’t convert correctly – then I can’t immediately think of another way to diagnose it. Maybe Geoff has an idea?
If you could take five minutes to check whether the Flatpak has the same problem on your system, that would give a partial answer. You can do that with nothing more than:
sudo apt install flatpak
flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
# Restart the system, then:
flatpak install --user org.openchemistry.Avogadro2
flatpak run org.openchemistry.Avogadro2
To remove the Flatpak and all its dependencies afterwards it’s as simple as running:
flatpak uninstall --all
You may launch e.g., package manager synaptic, search by keyword openbabel in Description and Name to check names and versions of the libraries installed. Example (though Debian 14/forky):
Take note and uninstall them, test again – no worries, openbabel is not an essential package to boot Ubuntu. If openbabel is a requirement in one of your workflows, reinstall the packages with synaptic.
If the packages’ versions differ from what corresponds to Ubuntu’s package index for the point release you got, timeshift can help to record a snapshot about your installation prior to the uninstallation, to which you later return/restore the OS after running the tests (like synaptic, running timeshift for this requires administrator privileges). This were an additional precaution to prevent either the need of dd copying of the partition, or bare re-installation of the OS from installation media should tests damage the setup.
