PDFjam is a small collection of shell scripts which provide a simple interface to much of the functionality of the excellent pdfpages PDF file package (by Andreas Matthias) for pdfLaTeX. These scripts take one or more PDF files (and/or JPG/PNG graphics files) as input, and produce one or more PDF files as output. They are useful for joining files together, selecting pages, reducing several source pages onto one output page, etc., etc.

Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

E233: cannot open display Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

This can happen when xhost isn’t configured to allow local, non-network connections. As the user who started the xwindows session (not root) run:

$ xhost
access control enabled, only authorized clients can connect
INET:localhost.localdomain
SI:localuser:cfinch

This shows that network connections to X are only allowed from localhost, and from a local user called cfinch (who started the X server). To fix the problem, run the following command to allow local user “root” to connect to the X server:

$ xhost local:root
non-network local connections being added to access control list

To see what this did, run xhost without any arguments:

$ xhost
access control enabled, only authorized clients can connect
LOCAL:
INET:localhost.localdomain
SI:localuser:cfinch

Now root can run GUI applications, such as the system-config-* tools.

init: Id "co" respawning too fast: disabled for 5 minutes

This caught my attention, because this OS image on this particular node should be identical to the image that is deployed on the rest of the nodes in the cluster. Why was it the only one producing this strange warning message? I searched the web and learned that the following line in /etc/inittab is causing the warning:

co:2345:respawn:/sbin/agetty ttyS1 19200 vt100-nav

However, this line is also found in the inittab file on every other node, so there is no error in inittab. Many solutions suggest commenting out this line. That is not a real solution, since this line is actually correct. After reading this post about co respawning too fast, I realized that the problem with my server is that one of the physical serial ports was not working. The output from dmesg showed:

Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:02: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
brd: module loaded

This node should have TWO serial ports!  I rebooted the node and confirmed that the second serial port was not configured in the UEFI.  I suspect that this node “lost” a serial port when the battery on the motherboard had to be replace a few months back. Surprisingly, I had to reconfigure the serial ports twice before it worked.  Now dmesg shows:

Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
00:02: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:03: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A

…and the annoying warning is no longer filling my log files with noise! I suspect that this points to the root problem experienced by other admins, such as these disgruntled Amazon Web Services users. I suspect that Amazon made a change in their virtual machine that eliminated one or more virtual serial ports, wreaking havoc with some users whose instances depended on them.

xmgrace my_file.xvg

If you aren’t using Linux, plotting .xvg files is quite a bit more difficult. Gnuplot is the only free plotting program that I have found that can handle .xvg files. Gnuplot is available for Windows (there is a direct download link near the top of the download page), but I will caution you that Gnuplot is not easy to learn. It has a command-line interface, and there are no point-and-click options to do basic operations such as labeling the axes of the plot. If you are using Gnuplot, you can plot the contents of an .xvg file with the command:

plot "my_filename.xvg" u 1:2 w lines

If you are more comfortable with Microsoft Office, you can also plot the contents of .xvg files using Excel. Start Excel, choose File->Open, and select “All Files (*.*) in the lower right corner of the dialog.  Select a .xvg file and press Open.  The text import wizard should start.  Choose Fixed width, Enter 14 where it says, “Start import at row: “ and press Next. A screenshot is shown below.

 In the next window, remove one of the black vertical lines, and move the other one to Column 15 as shown below. Press Finish.

If your import was successful, your spreadsheet should look like this:

Now, highlight the first two columns and insert a scatter plot (with lines) as shown below:

Although I generally don’t recommend using Excel for making publication-quality plots, it can be useful if you don’t have better tools available.

]]> http://www.shocksolution.com/2013/03/how-to-plot-xvg-files-from-gromacs-on-windows/feed/ 0 http://www.shocksolution.com/2013/03/opportunity-for-postdoctoral-research-associate-in-high-performance-computing/ http://www.shocksolution.com/2013/03/opportunity-for-postdoctoral-research-associate-in-high-performance-computing/#comments Mon, 04 Mar 2013 22:51:12 +0000 Craig http://www.shocksolution.com/?p=1188 My current employer, the STOKES Advanced Research Computing Center (STOKES ARCC), is hiring a postdoctoral research associate to conduct research in high performance computing with an emphasis on next-generation networking technologies. The ARCC has internal funding that will be used to upgrade our research network to the Internet2 Innovation Platform standard. We are also seeking external funding to extend the research network across the UCF campus. We are looking for a candidate with an interest in topics such as defining a “Science DMZ,” Internet2, GENI, perfSONAR, software-defined networks, etc. Please use the link above to apply for the position. Feel free to contact me if you have questions-my contact information is on the about page.

The speptide directory has two subdirectories: one for MDP files (which control the simulations) and one for simulation files. I have found this to be an efficient setup because many MD experiments involve simulating multiple variants of a molecule (such as mutants of a protein) and comparing the results. All variants should be run with the same parameters, so the same MDP files are used for each simulation. Keeping the MDP files in their own directory and creating symbolic links from the run directory to the MDP files ensures that all simulations are run with identical parameters.

In the run directory, there is a Bash script called setup_GROMACS_job.sh. At the top of the script, the user sets variables to set simulation parameters such as the box size. The script can be run with the command

./setup_GROMACS_job.sh speptide

Running this script creates the symbolic links to the MDP files and prompts the user for other parameters, such as the number of ions required to neutralize charge in the simulation domain. Note that this script is a simple tool to automate some common setup steps; running the script is not a substitute for understanding what it does at each step!

run_GROMACS_MD.bat is a Torque submit script. You will have to edit the Torque parameters so that you are using an account and queue that are appropriate for your cluster. This script assumes that setup_GROMACS_job.sh has already run successfully.  It performs an energy minimization run, an NVT run with constraints on the positions of protein atoms, an NPT run with the same constraints, and an unconstrained NPT run. Not every MD simulation requires all of these runs, but they are all included for demonstration purposes. If you have already run an unconstrained NPT simulation but want to extend the trajectory in time, the Torque submit script run_GROMACS_MD_unconstrained.bat will run only the unconstrained NPT simulation.

The script called analysis.sh is another simple way to automate many of the standard analysis operations that are performed on MD trajectories. Once again, it is not wise to run this script without studying it and understanding every line. For example, running the DSSP analysis program requires downloading and installing DSSP, and having a version of GROMACS that is compatible with DSSP.

Finally, the script called cleanup.sh will reset the simulation directory to its original condition, DELETING YOUR RESULTS. If you think you might screw this up, delete this script now so you don’t accidentally delete precious data!

• You don’t have root permissions on a system such as a shared cluster
• You are an administrator on a shared cluster and you can’t risk having a package over-write system-critical files

One approach is to extract the files from the RPM package and install them manually. I used this method to install FDTD Solutions from Lumerical on the STOKES Linux cluster. The application is distributed as an RPM package. I never install a third-party RPM as root, because a badly constructed package might over-write a system-critical file that some user is depending on. I downloaded the appropriate TAR file from Lumerical, uncompressed it, and looked at the contents. There is a simple script called install.sh which checks to make sure the user is root and then tries to install a hardware key driver and an RPM that contains the FDTD software. Here are my recommendations for installing Lumerical products on a cluster:

1. Instructions on the Lumerical web site say to install the hardware USB key driver on every compute node. This is a bad idea unless you have a small, single-user cluster. Those instructions fail to mention that Lumerical also offers FlexLM-based network licenses. If you are installing Lumerical products on a production cluster, get them to give you a FlexLM-based license!
2. Use the following command to extract the files from the RPM:

rpm2cpio FDTD-8.5.3-1.rhel5.x86_64.rpm | cpio -idmv

This could get messy, but fortunately, the FDTD Solutions app is self-contained within the /opt directory. I copied the application directory to our apps directory, and it runs fine from there.

$ mpicc hello_world_mpi.c -o hello_world
/usr/bin/ld: cannot find -lnuma

This was rather surprising, since this node mounts a directory via NFS that contains OpenMPI and Intel Composer 2013, and these applications are known to work on other nodes. To find the source of the problem, I used the showme option to see the command that is actually run by mpicc:

$ mpicc hello_world_mpi.c -o hello_world --showme
icc hello_world_mpi.c -o hello_world -I/apps/openmpi/openmpi-1.6.2-intel-composer-2013/include -pthread -L/apps/openmpi/openmpi-1.6.2-intel-composer-2013/lib -lmpi -ldl -lm -lnuma -Wl,--export-dynamic -lrt -lnsl -lutil

The output was identical to the output on the other nodes…so why was this node failing to find libnuma? It turned out that OpenMPI looks for a library called libnuma.so, while RHEL only includes a library called libnuma.so.1, and it is missing a symbolic link that points libnuma.so to libnuma.so.1. The solution is to create the symbolic link:

$ ln -s /usr/lib64/libnuma.so.1 /usr/lib64/libnuma.so
$ ls -l /usr/lib64/libnuma*
lrwxrwxrwx 1 root root    23 Feb 20 17:37 /usr/lib64/libnuma.so -> /usr/lib64/libnuma.so.1
-rwxr-xr-x 1 root root 22032 May 17  2011 /usr/lib64/libnuma.so.1

The hickle developers have made a good start, and they have a long way to go before hickle will be useful to a wider audience. Right now, hickle can only store NumPy ndarrays and Python list objects. If you only need to store lists and arrays, you might as well use HDF5 bindings for Python such as PyTables or h5py. The power of the pickle module is that you can immediately serialize almost any Python object of arbitrary complexity, store it on disk, and retrieve it. hickle will only achieve its full potential once it replicates this functionality, and I’m not sure how difficult this will be. Ideally, you might be able to derive a class from Pickler that uses Picker’s methods to serialize an object, and then add your own method to write the serialized object to an HDF5 file.

In a future post, I’ll describe some of the practical problems with using pickle files to store data, and try to organize some thoughts about how they might be solved.

/apps/python/python/-2.7.3-intel-composer-2013

and set

PYTHONPATH=/apps/python/python-2.7.3-intel-composer-2013
LD_LIBRARY_PATH=/apps/python/python-2.7.3-intel-composer-2013/lib:$LD_LIBRARY_PATH

NumPy

The Intel guide is a good starting point for building NumPy. The modifications that Intel suggests for the file site.cfg also with Composer 2013. However, you also have to modify several Python files in the distribution, and this is where the guide gets confusing. You need to edit the class of the file that corresponds to the command-line flags you will use to build NumPy. For example, if you have a 64-bit system (not an Itanium), you should modify the class IntelEM64TCCompiler to look like this:

# File numpy-1.6.2/numpy/distutils/intelccompiler.py
class IntelEM64TCCompiler(UnixCCompiler):
    """ A modified Intel x86_64 compiler compatible with a 64bit gcc built Python.
    """
    compiler_type = 'intelem'
    cc_exe = 'icc -m64 -fPIC'
    cc_args = "-fPIC"
    def __init__ (self, verbose=0, dry_run=0, force=0):
        UnixCCompiler.__init__ (self, verbose,dry_run, force)
        self.cc_exe = 'icc -m64 -O3 -g -fPIC -fp-model strict -fomit-frame-pointer -openmp -xhost'
        compiler = self.cc_exe
        self.set_executables(compiler=compiler,
                             compiler_so=compiler,
                             compiler_cxx=compiler,
                             linker_exe=compiler,
                             linker_so=compiler + ' -shared')

You also need to modify the compiler script for Intel Fortran. Once again, the modifications below are for a 64-bit system.

# numpy-1.6.2/numpy/distutils/fcompiler/intel.py
class IntelEM64TFCompiler(IntelFCompiler):
    compiler_type = 'intelem'
    compiler_aliases = ()
    description = 'Intel Fortran Compiler for 64-bit apps'
 
    version_match = intel_version_match('EM64T-based|Intel\\(R\\) 64|64|IA-64|64-bit')
 
    possible_executables = ['ifort', 'efort', 'efc']
 
    executables = {
        'version_cmd'  : None,
        'compiler_f77' : [None, "-FI", "-w90", "-w95"],
        'compiler_fix' : [None, "-FI"],
        'compiler_f90' : [None],
        'linker_so'    : ['<F90>', "-shared"],
        'archiver'     : ["ar", "-cr"],
        'ranlib'       : ["ranlib"]
        }
    def get_flags_arch(self):
        opt = ['-O3', '-openmp', '-fp-model strict', '-fPIC']
        if cpu.is_PentiumIV() or cpu.is_Xeon():
            opt.extend(['-tpp7', '-xW'])
        return opt

After making these modifications, run the commands:

python setup.py config --compiler=intelem --fcompiler=intelem
python setup.py build --compiler=intelem --fcompiler=intelem
python setup.py install

The way I have my system configured, the packages were automatically installed into

/apps/python/python-2.7.3-intel-composer-2013/lib/python2.7/site-packages

SciPy

Once you have built NumPy, SciPy is easily built because it uses the site.cfg file from NumPy:

python setup.py config --compiler=intelem --fcompiler=intelem
python setup.py build --compiler=intelem --fcompiler=intelem
python setup.py install

Warnings about umfpack can be safely ignored if you don’t have umfpack installed.