Our tools for computational materials simulation

For the purpose of performing computational materials simulations (CMS), one very essential factor is the availability of some highly specialised computational tools. Not only we need these tools, equally important is the know-how to use these tools. When I mention 'tools' I have in my mind hardware and software tools.

Hardware resources we have in the physics school are 'moderately abundant'. We have cluster PCs and workstations, totaling up to around 256 cores. The main purpose of these hardware is to provide processor cores for intensive computational purposes. For better performance, these computers have to also equipped with good amount of RAM. In the long term, when the group's size expands, the available hardware resources may become very tight. But at the moment we are quite comfortable with what we have.

Software tools can further be broken down into two levels of complexity: (1) running the software, and (2) performing post-processing on the data churned out by these software.

The software tools that are available to us include: ABINIT, Wien2k, DeMon, LAMMPS, DFTB+, HOTBIT. We also have licensed software VASP and Crystal, but we have not been very skillful in using these compared to the former. We also have experienced with Gaussian and Material Studio, but unfortunately we do not has full access to the licensed version of these. All these software mentioned above (except VASP and Crystal) have been fully installed in our hardware. Installation and running VASP and Crystal are not a priority for the moment as we have more software than we can digest.

There are basically three major categories of software code for the purpose of CMS. DFT software (ABINIT, Gaussian, VASP, Crystal, DeMon), tight-binding DFT (DFTB+, HOTBIT), and molecular dynamics software (LAMMPS). Basically we have installed these software in our computational resources (most are rendered to run in parallelised modes). And most importantly, we have (I mean our group members) gained enough experience to use them (except for VASP and Crystal).

However, when running CMS calculation, very often we need to know what are the ground state (GS) structures at zero temperature, i.e., configurations that correspond to the lowest energy. If a system is to be stable (hence corresponds to a state observable in the lab), it should be a GS, or a meta stable state (which is not as stable, and is subjected to transition to other nearby meta-stable states upon thermal perturbation). Finding GS structure by itself is a difficult task, since there are in principle almost infinitely many possible ways how a system can be configured in a finite 3D space. To this end, we need some intelligent ways to help us finding GS. This can be achieved via genetic algorithm (GA) and basin hoping (BH). Most often, one has to couple GA and/or BH into the above software to obtain the GS of a system. BH and GA programs for locating GS purposes are usually standalone codes developed by individual research group. However, GASP, a GA program has recently been developed by the Cornell materials engineering group, and implemented into LAMMPS. Although the GASP+LAMMPS have been configured to run in our computer nodes, we have yet to develop the know-how to use them for our GS-finding purpose. This is due to the reason that we have not had the time to explore the GASP codes and to tune the GA parameters.

A GA (or BH) coupled to LAMMPS, or DFTB+, allows one to search for the GS at zero temperature. Without GA or BH (or other global-minimisation search algorithms) one can not confidently claim a given configuration of atoms is in a stable state. A calculation for the total energy of such an arbitrary configuration at zero temperature cannot be convincingly claimed to be the global minimum. Having a workable GS-searching capability (which has to be coupled to the CMS software) is what we have been trying to acquire for sometimes. The good news is we have just acquired such an "upgrade" recently. Well, we did not do it ourselves. All credit goes to Prof. Lai's group in the NCU complex fluid research lab. Prof. Lai's group has developed a highly effective parallelised GA code that could be easily coupled to LAMMPS and DFTB+. On top of this, they also has a BH code that could also be used in place of GA as a stand-alone optimisation tool. We simply borrow their achievement which they developed with tears and blood. The next thing we want to develop is to couple the GA and BH with DFT software. Technically it is possible to implement such a software-coupling. But we also anticipate a  serious penalty on the speed which is hampered by the expensive calculation cost of the DFT codes.

In most cases, all output from the CMS calculations (be it DFT, DFTB+ or LAMMPS) have to be post-processed. And usually the post-processing of these data have to be manually done. The software packages usually provide very limited functionality for post-processing, except some very common ones. For example, plotting the electronic density from DFT calculation is a norm, hence can be easily done by using the post-processing packages come together with, say, Gaussians' gaussiview. However, for MD and DFTB+, almost no such post-processing tools exist. We have to write out own codes to perform post-processing. For example, we have to write our own Mathematica code to calculate the average bond length of certain selected atomic species in the LAMMPS output data. To calculate the point group of a bunch of Boron atoms in a cluster in a typical DFTB+ output, we have to manually do this using an independent software that calculate point group based on the coordinates of the atoms.

Of course, there are a lot of  potential technical issues that could hinder us from completing the intended calculation. The most serious hindrance comes in the form of the unavailability of force fields, or unsuitability of the force fields (in the case of LAMMPS), or SK files (in the case of DFTB). In DFT calculation, there is no issue of forcefields or SK files, but the problems in DFT are non-convergence, or simply taking too long hours to complete the calculation.

After the calculations have completed, then we have another kind of issue to address, namely, the reliability of the results, and the physical interpretation of these results. The former are usually easier than the later. We need to know a lot of physics in order to write a meaningful sentence to address the physical interpretation of the results. This is the part we have to keep improving and learning from Prof. Lai. In comparison, running calculation is relatively easier then assuring the correctness of the calculation, or interpreting the physics of the results. 

The point I wish to highlight is that, after an extended period of hard work, we have gained a lot of experience in installing, maintaining, using and manipulating these specialised software mentioned above. These technical know-how are by no means easy, but have to be earned via many hours of learning and effort. Once we have identified a problem to attack, we are now in a better position to go ahead confidently. In order for a new comer to perform a CMS, he/she will have to master all these software tools mentioned above, apart from knowing the physics and the theories. Even if she/he can't be a great CMS scientist, at least she/he will be a well-trained computer expert in Linux, post-processing, programming, and visualisation.