📜 ⬆️ ⬇️

Visualization of crystal 3d-structures in the browser without plug-ins

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.

Water adsorption on perovskite surface


')
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:



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.

Source: https://habr.com/ru/post/265673/


All Articles