Showing posts with label Software. Show all posts
Showing posts with label Software. Show all posts

Friday, December 17, 2010

amber11 pmemd + LAM-7,1,4/torque

The default optimization flag for pmemd.MPI is -fast, which causes some trouble in our cluster since the torque library doesn't like -static at all. You might already know that -fast is equivalent to "-xHOST -O3 -ipo -no-prec-div -static". My suggestion is to use "-axSTP -O3 -ipo -no-prec-div" instead. The reason for that is compatibility, -xHost also isn't a good optimization flag either. All processors in our cluster are not exactly the same, -xHost is just adding a possibility to mess with.

Wednesday, November 10, 2010

lack of ppmtompeg from netpbm package disrupts VMD tutorials

There is no ppmtompeg in current netpbm binary rpm distribution at least for fedora due to legal issue(?). This is going to be very annoying for administrator to deploy workstation for computer lab for molecular simulation. REF: http://www.ks.uiuc.edu/Research/vmd/mailing_list/vmd-l/14091.html

Friday, March 12, 2010

Rotating and exporting PDB inside VMD

set mymol [atomselect top "all"]
$mymol move [transaxis x -45 deg]
$mymol move [transaxis y 70 deg]
$mymol move [transaxis z -15 deg]
cd ~/Downloads/
$mymol writepdb test.pdb

Thursday, March 11, 2010

An extremely simple load watchdog script.

#!/bin/bash
for myscript in run*.bash; do
    sleep 15
    myload=$(uptime | sed -e 's/,//g;s/\.//g'|awk '{print $(NF-2)}')
    while [ $myload -gt 320 ]; do
        sleep 5
        myload=$(uptime | sed -e 's/,//g;s/\.//g'|awk '{print $(NF-2)}')
    done
    bash $myscript &
done

Tuesday, May 26, 2009

trajectory movie generation sucks

I just wanted to generate a movie for my box simulation, in the end I tried vmd and pymol for numerous times and still can get a satisfying result. (yeah and flickr video sucks.)

Please remember to click HQ icon, or you see some blurred crap.

Monday, March 30, 2009

Fedora 9, OpenMPI, Amber11, oh mine!

Prerequisites for Amber11 on Fedora:
  1. gcc
  2. libXt-devel libX11-devel libICE-devel libSM-devel libXext-devel (on some configuration, you might not have the right version of architecture for the *-devel package, please make sure that's correct.)
  3. Intel Fortran (gfortran, g95 also work, but ifort is better)
  4. Intel Math Kernel
  5. openmpi-devel
(To be continue)

Thursday, October 16, 2008

Change logs of MODELLER (Ε ali et al.)

To keep track on many versions of MODELLER program, having a change list helps a lot.

Prior to MODELLER 4: check modeller6v2/doc_INT/modeller4-changes of mod6v2 windows distribution.
MODELLER 4-6v2: changes since MODELLER-4
MODELLER 7v7: Changes since release 6v2
MODELLER 8v0: Changes since release 7v7
MODELLER 8v1: Changes since release 8v0
MODELLER 9v1: Changes since release 8v1
MODELLER 9v2: Changes since release 9v1
MODELLER 9v3: Changes since release 9v2
MODELLER 9v4: Changes since release 9v3
MODELLER 9v5: Changes since release 9v4
MODELLER 9v6: Changes since release 9v5
MODELLER 9v7: Changes since release 9v6

Monday, September 29, 2008

Some testing result on pmemd scaling and parallel computation

Message-ID: <6003f3300809291827p13fcdeew94133ee69f206f1b@mail.gmail.com>
Date: Mon, 29 Sep 2008 18:27:37 -0700
From: "Mengjuei Hsieh"
To: developers
Subject: Some testing result on pmemd scaling and parallel computation

Here is some recap on the JAC benchmark performance on different
parallel options I did this weekend.

We were trying to explore the options for network connection with
jumbo frame (also known as large MTU, mtu=9000 in linux) gigabit
ethernet local network to see if we can replace the previous parallel
computing solution of connecting two machines directly with an
ethernet cable (we called it sub-pairs to reflect the fact that by
doing so, the machines will be grouped in pairs). The reason is
obvious, grouping computing nodes in pairs is not an efficient way to
work with nor to manage the nodes.

We tested with the NetPipe benchmark to measure the performance of a
gigabit ethernet with or without jumbo frame, the benchmark is
consistent with general wisdom and references on the internet or on
the literature. I thought we could utilize more bandwidth with jumbo
frame ethernet.

First, I tested the scaling of amber 9 pmemd with lam/mpi or mpich on
jumbo frame ethernet. The configurations of the testing environment
look like this:

Two identical dell poweredge 1950, each comes with 2 intel xeon 5140
woodcrest duo-core processors, 4MB cache, 2GB RAM. Shared memory
interconnect / MPICH-1.2.6 / LAM-MPI 7.1.4  Intel Fortran 90 compiler,
Intel MKL

The results of the parallel performance are:
*******************************************************************************
JAC - NVE ensemble, PME, 23,558 atoms

#procs         nsec/day       scaling, %

  1          0.329           --
  2          0.628           95        (SMP)
  4          1.094           83        (SMP)
  4          0.965           73        (TCP, 1+1+1+1)
  4          0.819           62        (SMP/TCP, 2+2)
  8          0.987           37        (SMP/TCP, 4+4)

This does not meet the definition of "scaling" therefore the network
traffic was also measured and I found that in the case of the network
communication, only 30% of the bandwidth is recorded. For some
sidenotes, these are under the parameter of at least
P4_SOCKBUFSIZE=131072 (mpich) and net.core.rmem_max=131072
net.core.wmem_max=131072, similar results have been observed under
lam-mpi  rpi_tcp_short=131072.

Further test on direct connection pairs shows that the measurement is similar.

Therefore the benchmark fell back to amber 8 pmemd, which is the
original program we had in the sub-pair configuration.

the results of the parallel performance with amber 8 pmemd are:
*******************************************************************************
JAC - NVE ensemble, PME, 23,558 atoms

#procs         nsec/day       scaling, %

  1          0.203           --
  2          0.391           96        (SMP)
  4          0.465           57        (SMP)
  4          0.457           56        (SMP/TCP, 2+2)
  8          0.680           42        (SMP/TCP, 4+4)

Less efficient amber 8 pmemd makes the scaling factor of 4+4cpus
parallel computation look better, but the performance is definitely
not better. Similar results were observed on directly connected pairs.

The interest of this exploration then turns to the scaling of the
AMBER 10 pmemd, and the results are:
*******************************************************************************
JAC - NVE ensemble, PME, 23,558 atoms

#procs         nsec/day       scaling, %

  1          0.411           --
  4          1.329           80        (SMP)
  8          1.137           35        (SMP/TCP, 4+4)

At this point, I can say is don't expect anything too interesting from
gigabit ethernet performance. This conclusion is consistent with
observation from Dr. Duke and Dr. Walker.

A further benchmark has been done for Amber10 pmemd on a dual
quad-cores intel xeon E5410 machine (dell PE1950, 2.3GMhz, 6MB cache,
2G RAM):
*******************************************************************************
JAC - NVE ensemble, PME, 23,558 atoms (on the same machine, SMP mode)

#procs         nsec/day       scaling, %

  1          0.434           --
  2          0.815           94
  4          1.464           84
  6          1.964           75
  8          2.274           65

That's all. AMBER 10 pmemd rocks.

Bests,
--
Mengjuei