Montag, 10. August 2015

Gamess - Multi Core Single CPU computation

Consider this blog post as an update to the last post where I talked about building Gamess. Gamess, if built like I demonstrated does not support distributed parallel computing on multiple nodes. However you can easily distribute your computation over several cores on your multicore single socket CPU, i.e. multiple CPUs on one local node (in Gamess terminology). This is unfortunately not enabled by default but you can easily get this feature by simply editing a few lines in your /gamess/rungms file. Here are the lines you need to comment or add to your rungms script:

#   if ($NCPUS == 1) then
#      set NNODES=1
#      set HOSTLIST=(`hostname`)
#   endif

      set HOSTLIST=(`hostname`:cpus=$NCPUS)
      set NNODES=1

#    echo I do not know how to run this node in parallel.
#    exit 20

(I strongly recommend to make the "rungms" script globally available by creating a link to /usr/local/bin/ like in "sudo ln -s /home/user/gamess/rungms /usr/local/bin" this way you can adress the rungms script from within every directory without providing the full path.)

After editing, you can invoke multiple cores by typing "rungms job.inp 00 7 > job.log &" where "00" is the current build you are using and "7" is the number of cores among which the computation shall be distributed. "job.inp" is your input file in this case.

Samstag, 8. August 2015

Build Gamess on Fedora 22 Linux

I've decided to write a little how-to for the not quite trivial process of compiling and running Gamess on newer versions of Fedora Linux. This is exclusively for people who work with or have some experience with Gamess itself or with ab-initio quantum chemical suites in general. Further I expect the reader not to be new to Linux nor a Fedora newcomer. You need some fundamental understanding of the cli, package management and package building to get this done. No fancy skills but... know what you are doing, do not just copy and paste.

The introduction of gcc5 in Fedora 22 brought along a merging of some build libraries which causes some linking issues. The remainder of the procedure is self explanatory. Nevertheless some rare and rather counter-intuitive tweaks must be performed to get everything up and running.

Gamess output file header in cli
0) Getting Gamess

You can request a copy of Gamess from the GAMESS source code distribution of the Gordon's Quantum Theory Group. The academic license is provided free of charge if you register with your university Email contact. Although this tutorial may be valid for other packages on various systems, I can only confirm this to be viable with GAMESS version December 5, 2014 R1 for 64 bit (x86_64 compatible) under Linux with gnu compilers and on a fully up-to-date Fedora Workstation 2 (64bit) with Gnome 3.16. Further this treats only the sequential, single socket version without CUDA support. Multiple CPU cores are however supported. If you need to run the parallel version you must follow a different approach.

All the steps can basically be found in the gamess/machines/readme.unix file once you have unpacked it. This is merely a condensed rundown with some vital amendments for gcc5.  

1) Unpack Gamess package

You might want to mkdir a working directory in your /home/user directory. I merely moved the extracted gamess folder to /home/user. You need root access only to create the appropriate symlinks in /usr/lib64/atlas and to edit /etc/sysctl.conf. Please contact your system administrator if you do not have root access.

Unpack and extract the downloaded file like "gunzip gamess-current.tar.gz  && tar xf gamess-current.tar" or any other way you feel comfortable with. As mentioned I just moved the folder gamess to /home/user directory to work with. 

2) Preparations

Make sure you have the following packages installed and updated before you start building Gamess:
  • tcsh (a C shell for C source code compilation)
  • atlas (fundamental build package, installed by default in Fedora 22)
  • gcc (gnu-C compiler, version 5 by default on Fedora 22)
  • gcc-gfortran (gnu-fortran compiler)
You need to allow the system to assign appropriate amounts of shared memory to the gamess application. We do this via adjusting the kernel.shmmax parameter. This parameter defines the maximum size in bytes of a single shared memory segment that a Linux process can allocate in its virtual address space. Please do read section five of gamess/ddi/readme.ddi to get the correct value for your system and for further information about this step.

For now just edit /etc/sysctl.conf as root and append "kernel.shmmax = 17179869184" without quotes but only if you have 16 GB of memory. If you have more or less RAM please check gamess/ddi/readme.ddi and punch in the correct value. In any case we want to allow Gamess to use the maximal available amount of shared memory i.e. the total installed RAM. Reboot the system for this to take effect.

3) Run config script

From the cli, cd into your gamess root directory and execute the config script like "./config". This sets up the configurations for the compiler and prompts you for some crucial system information. Go thoroughly through it, step by step and keep another instance of the terminal open to collect some information about your system.

Provide the full path to the gamess root directory as in /home/usr/gamess

We use gfortran from gcc version 5. If prompted for version numbers just set it to "4.8". At the time of release, 4.8 was state of the art and any higher version numbers are not supported in the config script but will work just fine in the actual build process. 

Set the math library to atlas and provide the path, most likely /usr/lib64/atlas.

4) Compilation A

cd to the gamess/ddi/ directory and from there run the compddi script and make it create a log file for your convenience like in "./compddi >& compddi.log &".

After the script has finished, move the ddikick.x one directory up into the gamess root directory. Type "mv ddikick.x .."

5) Compilation B

cd to the gamess root directory and run "./compall >& compall.log". The compilation of Gamess may take about 20-60 minutes.

6) Linking

Now as I said gcc5 merged some libraries. To tend to some issues in the linking process we need to create two symlinks so that the linker can find them anyway. -> and -> We do this by typing

"sudo ln -s /usr/lib64/atlas/ /usr/lib64/atlas/" and 

"sudo ln -s /usr/lib64/atlas/ /usr/lib64/atlas/"

The output of "ls -rtlh /usr/lib64/atlas/" should" now look something like this screenshot.

Output of "ls -rtlh /usr/lib64/atlas/" with correct symlinks pointing to

Only now we can start linking the package by typing "./lked gamess 00 >& lked.log". The 00 represents the build version. Since this is the first build stick with 00. "Gotta be consistent".

7) Editing rungms and create scratch directory

Create a directory on a drive with fast access like a local hdd for temporary calculation dump. I've decided to put it in my /home/usr directory. "mkdir /home/usr/scr" and name it "scr". But call it whatever you like. Just refer to it appropriately in the following step.

Backup the rungms file "cp rungms rungms.backup" and edit rungms with your editor of choice. In this file we need to modify at least the following:

set SCR=/home/usr/scr
set USERSCR=/home/usr/scr
set GMSPATH=/home/usr/gamess
setenv ERICFMT /home/usr/gamess/auxdata/ericfmt.dat
setenv MCPATH /home/usr/gamess/mcpdata

8) Run example inputs

Type "./runall 00 >& runall.log" to go compute 47 example systems. These serve as a basis for evaluation of the compilation upon comparison with pre-computed values. I made a directory called gamess/exams/ and moved all 47 example outputs there to keep my gamess root directory clean. Then descend into the "exams" directory and run  the test like "~/gamess/tests/standard/checktest >& checktest.log" to compare your computed outputs with the targets provided by Gamess. If everything went well then you will be notified with the satisfying line "All 47 test results are correct!".

Congratulations you've just successfully compiled and linked Gamess.

9) Acknowledgement

This Tutorial was inspired to a large extent by the already very good post by Jan Jensen, who is a capacity on this matter. You can find the original post here. Please also visit his blog molecularmodelingbasics if you are interested.  

I merely added some minor changes that are mandatory since the introduction of gcc5. 
This tutorial is in essence a condensed version of the gamess/machines/readme.unix file which contains all the necessary steps.

If you run into problems or have unexpected issues with the building process of Gamess please feel free to leave a comment.

+++ UPDATE (24/11/2015) +++

The above method is also tested and verified on Fedora 23 Workstation (Linux 4.2.6-300.fc23.x86_64) with gcc 5.1.1


Sonntag, 2. August 2015

High DPI on Gnome Shell 3.16

High DPI as acronym for high dots per inch ratio is still quite a troublemaker on modern operating systems. The reason is that most graphical user interfaces do not yet support high resolutions to the full extent resulting in a user interface that is not to scale. The outcome are some obnoxiously tiny fonts and a completely messed up GUI for most applications.

I currently use Gnome Shell 3.16 on my Fedora 22 Workstation with a 24 inch 4K IPS panel at 3840 by 2160 pixel. The reason is not only because I honestly think Gnome shell is very refined, allows for a great workflow, is modern and aesthetically pleasing but most of all for its high DPI support. While this is still not great on Linux, Gnome shell offers the best experience and least trouble with the setup. In the following I will show you what worked for me and how I tweaked my system to look pleasing.

Google Chrome - Fix Dock Issues with Multiple Instances

Google-chrome has an issue with gnome-shell dock. The default behavior is to provide an application launcher, grouping active instances which can be accessed via the very same launcher icon. In essence a combination of launcher and taskbar. The screenshot below shows correct behavior with dots to the left of the icon indicating three active instances of the google-chrome application.

Montag, 6. Juli 2015

Mechanical Keyboard: The CM Storm quickfire rapid i

The most fundamental way in which we interact with a computer is by providing input in a way, a machine understands and by receiving the computed output. We do so by providing text based commands through an interface which we call a keyboard. So in essence, when actively working with a computer we spend 100% of the time in contact with a piece of equipment that mostly receives little attention at best.