ABINIT for Chemists
The single largest group of users on high-performance computing clusters has to be the chemists. Their CPU-year count is definitely at the very top of the list. Because of this heavy use, several different packages have become standard tools that most computational chemistry researchers use. So in this article, I take an introductory look at one called ABINIT (http://www.abinit.org).
ABINIT calculates the energy and structure of groups of nuclei and electrons. The method used to make these calculations is Density Functional Theory (DFT, https://en.wikipedia.org/wiki/Density_functional_theory). If you want to know more about the underlying theory, feel free to go talk to your nearest computational chemist.
Although my exposure has been with people running ABINIT on scores of machines in parallel, at least in a learning environment or for small systems, nothing is stopping you from running it on your own desktop. The first step, of course, is to install it on your machine. You may have packages within your distribution to make installation easier. For example, on Debian-based systems, you can install it with:
sudo apt-get install abinit abinit-data abinit-doc
The only issue with that method is you probably will get an older version of ABINIT. At the time of this writing, the Ubuntu package installs version 7.8.2, while on the Web site, you can download version 7.10.5.
If you need the latest available code, you always can get the source code from the main home page and compile it yourself on your local machine. In order to build it yourself, you need the usual utilities to build other packages, such as make, libtool and autoconf. Because the majority of the code is written in FORTRAN, you also need a compiler capable of compiling F90 code. This will allow you to build a basic version of ABINIT. You can include extra functionality, such as MPI or NetCDF, if you have them available on your system.
The main executable to run these calculations is called
abinit. It takes
a number of input files in order to do the actual calculation. One of these
input files is actually a file of files. It is a file that contains a list
of other input files that abinit needs to read in. The usual filename
ending is ".files". If you have this input file, you can run your
abinit < my_input.files >& log
This tells abinit to read the input data from standard input (attached to the file my_input.files) and to write its results to standard output (attached to the file log). The log file only captures output that gets written out to the standard output stream. There is a lot more output that is written out. These other output files are defined in the my_input.files file. The following list is a more-detailed description of the contents:
ab_in — main input file.
ab_out — main output file.
abi — root filename for other input files.
abo — root filename for other output files.
tmp — root filename for temporary files.
my.psp — the pseudopotential used for this run.
The root names "abi", "abo" and "tmp" are used to create the multiple files for each of those sections.
There are a few rules around the input files that may cause problems if you don't follow them. The first is that you can't have tab characters in your input file. So, be sure that your editor uses space characters when you press the tab key. The second rule has to do with using negative numbers. There can't be any spaces between the negative sign and the first digit of the number. The last formatting rule is that no line can be more than 132 characters. If any lines end up longer than that, ABINIT simply will ignore the extra content. If you get errors when trying to run your own jobs, those are the first few places you should check.
There are a massive number of input variables that allow you to
control parameters around file handling, geometry, structure optimization
and response functions, among many others. These input variables can be in
any order. The entire file gets parsed before the calculations start. When
you start creating your own input files, you probably will want to be able
to check them somehow. Luckily, you can use ABINIT itself to do this. The
abinit executable includes an option
--dry-run) to take your input
files and validate them without starting the calculations. This allows you
at least to catch major typos before wasting the time involved in doing a
partial run and having it fail.
Along with your own input files, describing the geometry and other descriptive variables, ABINIT needs input files that describe something called the pseudopotential for your system. There are different types, such as Troullier-Martins or Hartwigsen-Goedecker-Hutter pseudopotentials, that can be used for different situations. Luckily, ABINIT includes pseudopotentials for the entire periodic table. This means you simply can build up your molecule by including the pseudopotentials for each of the different types of atoms in your system. Although it isn't necessary in most cases, you can create your own for some very specialized system if needed.
The other thing to be aware of is that ABINIT is released under a GPL license. This means you have access to all of the source code and can investigate exactly how the calculations are being done. When doing fundamental scientific research, that can be very important. You may be trying to do calculations in a region where the available algorithm is no longer valid. All of these calculations make assumptions to try to simplify the calculations so that they are actually doable, and it is very important to keep that in mind. But, with access to the code, you have the opportunity to make changes to those algorithms to fit the assumptions better that are valid for your problem. This open-source code gives you the ability to build on all of the past work and push it into new areas of research. Just remember to pass these extensions and improvements on to the next group of researchers to keep pushing our understanding forward.
Interpreting the output from ABINIT can be a bit of a job. There is a lot of output describing how the calculated values progressed until they reached the requested accuracy to the actual answer. For example, if you are calculating the energy for a molecular configuration, you probably are interested in when the energy is at its lowest value. This will be the most stable configuration for these nuclei and electrons. But, how do you interpret this output? Several tools are available to take the geometric portion of this output and plot it so that you can see what the configuration actually looks like. There also will be output describing how strong the various connections are between the nuclei, which you can use to see how reactive your molecule may be.
This is just a very basic introduction to what is involved when using ABINIT. Hopefully, you now feel a bit more comfortable digging in to the massive documentation and using ABINIT to solve whatever molecular problem you have. When you are ready, you can move on to much larger problems by using the MPI capabilities in ABINIT to use as many machines as you have available.
Joey Bernard has a background in both physics and computer science. This serves him well in his day job as a computational research consultant at the University of New Brunswick. He also teaches computational physics and parallel programming.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide