Hi, Habr! In this article I will compare the four open engines for visualization of crystal structures in the CIF (Crystallographic Information File) format, which is popular in crystal chemistry and materials science. It will be about modern JavaScript (including Java and C transcompilation in JavaScript), crystal chemistry and solid state physics. We are teleporting from the world of Schrödinger and Landau to the world of Berners-Lee and Jobs, and then back. So let's go.

')
It is known from the school course of physics that atoms in a solid are ordered into periodically repeating structural units of the size of the order of a nanometer, forming a crystal lattice. Physics of a rigid body
in the spirit of reductionism studies the relationship between the properties of these structural units (unit cells) and the properties of macrocosm objects. For example, by controlling the adsorption of water molecules on the surface of oxides of transition metals, one can reduce the cost of
hydrogen and oxygen synthesis , improve the
performance of fuel cells and
sensor devices , and optimize
drug delivery in pharmacology . In short, the physics of a solid body somehow describes any laboratory or technological process, and here the importance of molecular visualization is extremely difficult to overestimate. De facto in materials science, the most common computer format for exchanging data about crystal structures is CIF. An important difference between CIF and many
other chemical formats is the support of 3d-broadcasts, in other words, to define an infinite 3d-crystal, we repeat its elementary cell in three directions.
CIF was created in the 90s by the International Union of Crystallography (IUCR). The CIF is based on a text container called STAR (Self-Defining Text Archive and Retrieval), where physical properties resulting from diffractometry or theoretical calculations are labeled with standard tags. Standard tags determine the parameters of the unit cell, its symmetry, its constituent atoms, the metadata of the relevant scientific publication, and so on. These tags are defined in external CIF dictionaries, similar to XSD schemas of XML documents, so that a CIF document can be validated using a CIF dictionary and even new physical properties can be derived based on the available ones. The differences are that CIF allows arbitrary tags that are ignored by the CIF parser (of course, they can later become part of the standard and be included in new dictionaries as decided by the IUCR union). In addition, CIF supports the relational data model, when, for example, you can refer to certain atoms in a crystal structure by their identifiers. The disadvantage is the lack of convenient support for multi-level hierarchies, here the STAR container loses XML. By the way, this is why CIF has an XML competitor called CML (Chemical Markup Language).
Traditionally, CIF files open in desktop applications (Vesta, Accelrys / BIOVIA, RasMol, and many others), however, in this area, about four years ago, browsers began their crusade against desktop applications. The open source fruits of this campaign known to me are collected below, and their code as a single web application can be found
in the repository . The code has been tested in several popular browsers, including IE 11 and mobile Safari. The repository structure is as follows: the
data folder contains examples of CIF models (if you have ever dealt with crystal chemistry or materials science, you probably have your own), the
engines folder contains JavaScript code for all engines,
utils contains auxiliary code, for example, browser file downloader for local processing of CIF-models. Thus, to launch a web application, it is enough to open its folder for the web server and enter the corresponding address in the browser (or simply
go to the repository ). All files are static, no server processing is provided.
Briefly about the four models from the
data folder:
- adsorption.cif - model of the aforementioned adsorption of water in perovskite (see picture), unit cell, by default is loaded into each of the engines,
- fullerene.cif - fullerene C 60 ,
- lfp.cif - lithium-iron phosphate LiFePO 4 , the cathode material of a lithium-ion battery. Pay attention to the lithium ion: it is very light and mobile (and all because lithium is the third in the periodic table). The third lithium electron comes or goes to the external circuit as a result of discharging or charging the battery, while the lithium ion travels through the electrolyte.
- mdma.cif - 3,4-methylenedioxy-N-methamphetamine hydrochloride. Its functional groups can be replaced with preservation of the corresponding effect, thus a new and therefore legal substance is formed. This is precisely the problem of synthetic analogs.
Now, in fact, the results of the comparison engines.
Engine
| Version
| Total code size (in GZip brackets)
| Drawing technology
| Customization
| License
|
---|
Jsmol
| 14.2.15
| 2.1 MB (700 KB)
| canvas
| rich, programmatically and in the UI
| LGPL
|
ChemDoodle Web Components
| 7.0.1
| 354 KB (121 KB)
| Webgl
| rich, programmatically
| GPL v3
|
Rasmoljs
| -
| 1.1 MB (462 KB)
| canvas, sdl, asm.js
| rich, programmatically
| GPL
|
Player.html
| 0.10
| 265 KB (83 KB)
| canvas, Three.js
| limited in UI
| MIT
|
Decisions based on Java applets, Flash and other plug-ins did not consider
as a dead-end branch of evolution , only pure (as they say, “vanilla”) JavaScript. However, pure JavaScript can be
synthesized from a variety of other languages , the first and third solutions are just such cases.
JSmol is derived from Java
Jmol code using a
Java2Script tool. The total amount of JSmol code is 12.7 MB, parts of which are loaded as needed. The table above shows the volume required to start. Functionally, this engine completely repeats its more well-known Java-fellow, providing the richest set of features. The comparison could be completed here if it were not for the gigantic size (and the slowest start) and the costs of porting the foreign stack, in particular, the ugly and unreadable JavaScript.
ChemDoodle Web Components is based on a proprietary product. This has advantages (excellent documentation, high quality of both the code and the product as a whole) and disadvantages (restrictions on use, non-switchable sending of information about users). The disadvantages also include the lack of support for canvas in favor of WebGL, and therefore, the inoperability of slightly outdated equipment. If flaws do not represent a problem, this engine can be called a winner.
RasmolJS is obtained from its older C-brother
RasMol using
Emscripten . British
chemo-informatist Noel O'Boyle ported the original graphical functionality to the SDL library supported by Emscripten, as a result, the trans-compiled JavaScript code performs 3d rendering in the canvas element. In addition, the code is generated according to the asm.js standard, which in theory should provide a performance boost. In practice, it turned out to be a rather ponderous and slow engine, besides, devoid of a number of functions of previous participants.
Player.html is written by me using
Three.js and
Math.js. The emphasis is on minimalism and speed, as well as support for the widest possible range of equipment, so that the engine even works on ancient laptops. Development started relatively recently, and the functionality is still not very rich. Any criticism is therefore appreciated and thirsty.