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.
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:
- gcc
- 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.)
- Intel Fortran (gfortran, g95 also work, but ifort is better)
- Intel Math Kernel
- openmpi-devel
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
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
Subscribe to:
Comments (Atom)