From sathishguru1 at gmail.com  Fri Jul 13 23:42:08 2007
From: sathishguru1 at gmail.com (sathish kumar gurupatham)
Date: Fri, 13 Jul 2007 23:42:08 -0500
Subject: [cluster-l] basic doubt
Message-ID: <8b2695150707132142t7b0bde9s25b76f13e5446843@mail.gmail.com>

hi all,
pls help understand why the sign of eletrostatic potential is negative and
ultimately the total enrgy is negative in ubiquitin(tutorial)?
thanks in advance.
sathish.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ks.uiuc.edu/pipermail/cluster-l/attachments/20070713/28da87e6/attachment.html 

From sathishguru1 at gmail.com  Sun Jul 15 23:51:44 2007
From: sathishguru1 at gmail.com (sathish kumar gurupatham)
Date: Sun, 15 Jul 2007 23:51:44 -0500
Subject: [cluster-l] basic doubt
Message-ID: <8b2695150707152151p1b16dab8w625941fe5d3ea4b7@mail.gmail.com>

hi,
can any one explain me why electrostatic potential is negative in sign where
as other potentials are positive(ubiquitin -tutorial)?
what the sign indicates?
thanks in advance.
sathish.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ks.uiuc.edu/pipermail/cluster-l/attachments/20070715/771c754d/attachment.html 

From tskirvin at ks.uiuc.edu  Thu Jul 19 15:54:46 2007
From: tskirvin at ks.uiuc.edu (Tim Skirvin)
Date: Thu, 19 Jul 2007 15:54:46 -0500
Subject: [cluster-l] basic doubt
In-Reply-To: <8b2695150707152151p1b16dab8w625941fe5d3ea4b7@mail.gmail.com>
References: <8b2695150707152151p1b16dab8w625941fe5d3ea4b7@mail.gmail.com>
Message-ID: <20070719205446.GA17017@ks.uiuc.edu>

sathish kumar gurupatham <sathishguru1 at gmail.com> writes:

>    can any one explain me why electrostatic potential is negative in sign
>    where as other potentials are positive(ubiquitin -tutorial)?
>    what the sign indicates?

        You probably want to direct this to tutorial-l.

        http://www.ks.uiuc.edu/Training/Tutorials/mailing_list/

                            - Tim Skirvin (tskirvin at ks.uiuc.edu)
-- 
   Theoretical and Computational    http://www.ks.uiuc.edu/~tskirvin/
Biophysics, Beckman Institute, UIUC    Senior Systems Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : http://www.ks.uiuc.edu/pipermail/cluster-l/attachments/20070719/14a5d364/attachment.bin 

From noberg at uiuc.edu  Mon Jul 30 09:27:01 2007
From: noberg at uiuc.edu (Nils Oberg)
Date: Mon, 30 Jul 2007 09:27:01 -0500
Subject: [cluster-l] Single- vs. Dual- vs. Quad-core CPUs
In-Reply-To: <20070330000117.GA4029@uiuc.edu>
References: <7.0.1.0.2.20070119172450.00ec8dd8@uiuc.edu>
	<Pine.LNX.4.63.0701221558280.333@paris.ks.uiuc.edu>
	<7.0.1.0.2.20070124095646.00ec0ec8@uiuc.edu>
	<Pine.LNX.4.63.0702221332140.24872@paris.ks.uiuc.edu>
	<7.0.1.0.2.20070328132512.028a4598@uiuc.edu>
	<20070328200735.GB17630@uiuc.edu>
	<7.0.1.0.2.20070329144510.00ebba90@uiuc.edu>
	<20070330000117.GA4029@uiuc.edu>
Message-ID: <7.0.1.0.2.20070730091138.028d4cd8@uiuc.edu>

Hello,

Thanks for all of the very helpful responses to my questions 
regarding CPUs, networking equipment, and compilers.

I ended up purchasing a 5-node disk-less cluster comprised of 
dual-socket, quad-core Xeon processors (2.33 Ghz) with 8 GB RAM.  The 
head is a dual-socket, quad-core Xeon (1.86 Ghz) with 8 GB RAM and 
1.5 TB of RAID-5 storage.  The O/S is CentOS 5, the provisioning 
system is Perceus (http://www.perceus.org/portal/), the cluster 
queuing software is Sun Grid Engine, the network hardware is a SMC 
SMC8024L2 24-port gigabit managed switch, the UPS is a Tripp-Lite 
Smart UPS SU3000RTXL3U (120V, 30A) for power conditioning, and a APC 
Netshelter 4 Post open frame rack.  The vendor was Champaign 
Computer, and the hardware cost was $26,549.  Electrical installation 
costs for three 120V, 30A circuits was $1,135.  The software, 
including the Intel C++ and Fortran compilers, Intel Cluster OpenMP 
extensions for those compilers, and the Intel Cluster Toolkit, cost 
an additional $1,431.95.  The labor for research, purchasing, and 
setup cost approximately $4,000.

Thanks!

Nils



--
Nils Oberg, Research Programmer
Civil & Environmental Engineering, University of Illinois at U-C
phone: 217-333-8365, web: http://vtchl.uiuc.edu


From sathishguru1 at gmail.com  Mon Jul 30 12:24:21 2007
From: sathishguru1 at gmail.com (sathish kumar gurupatham)
Date: Mon, 30 Jul 2007 13:24:21 -0400
Subject: [cluster-l] water files
Message-ID: <8b2695150707301024o486ab313xc5f657015b1897dd@mail.gmail.com>

hi all,
am simulating water molecule in namd.can anyone guide me from where to
get parameter and conf files?i have got some output which is not correct i
guess.where can i get the correct output from?
pls help me,
thanks in advance.
sathish.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ks.uiuc.edu/pipermail/cluster-l/attachments/20070730/0af43000/attachment.html 

From rdrobert at uiuc.edu  Tue Jul 31 13:08:07 2007
From: rdrobert at uiuc.edu (Ricky Robertson)
Date: Tue, 31 Jul 2007 13:08:07 -0500 (CDT)
Subject: [cluster-l] another system summary
Message-ID: <20070731130807.ASZ14129@expms5.cites.uiuc.edu>

In the spirit of Nils's passing along information about his new cluster...

Jerry Nelson and I have been putting together a cluster in the Agricultural and Consumer Economics department here at UIUC. We are doing statistical / econometric / empirical / data-driven models (pick whichever adjective you like best) of land use. Specifically, we are trying to fit multinomial-logit and feed-forward neural network models for (predictively) classifying land use based on the attributes of the land. Since we like to do this at a reasonably fine resolution (think 30 meter squares), this adds up to a lot of data. For example, storing everything as 4-byte floats, data for the island of Sumatra in Indonesia takes up about 13GB. The problem is an "embarrassingly parallelizable" one and does not involve passing around much information other than the initial distribution of data to work on. We have written up our algorithms in java (for various minor reasons) which is handy for running them on different platforms.

At various junctures in the past and present, we have also had allocations on NCSA's tungsten, but have always been frustrated by the over-allocation and subsequent difficulty of getting jobs through the queues. That provided the primary motivation for putting together a mini-cluster of our own.

We have been going the basement bargain route. In general, we expect to be processor bound rather than memory or hard-drive bound. Hence, the strategy is to maximize the number of processors while minimizing memory and hard-drive space. Indeed, it seems that it will be better to get more, slower processors for the same money than fewer, faster processors. After fooling around testing various combinations, this is what we have ended up with.

Cluster Level Costs:
~$100 * 2 = $200 -> A couple shelving "racks" to put the nodes on

? ~$100 -> several power strips

~$60 * 2 = $120 -> A couple unmanaged network switches

sub-TOTAL = $420

Node Level Costs (prices from newegg.com):
$43 -> motherboard [JetWay JP4M9MP LGA 775 VIA P4M890 Micro ATX Intel Motherboard - Retail]

$40 -> 1GB memory (Transcend 1GB 240-Pin DDR2 SDRAM DDR2 533 (PC2 4200) Desktop Memory Model JM533QLJ-1G - Retail)

$117 -> Core 2 Duo CPU (Intel Core 2 Duo E4300 Allendale 1.8GHz LGA 775 Processor Model BX80557E4300 - Retail)

$35 -> box and power supply

$37 -> 80GB hard drive (EXCELSTOR Jupiter Series ESJ8080S 80GB 7200 RPM SATA 3.0Gb/s Hard Drive - OEM)

sub-TOTAL = $272

So far, we have 10 nodes like those described above, 2 more that are very similar (from the testing phase), and 2 more scavenged computers that are half as fast, but still useful.

Assuming the 12 nodes, the cost is roughly: $420 + 12 * $272 = $3684 so far. We plan to pick up roughly 10 more nodes for a total cost of around $6000.

For software, we have been using exclusively free stuff. We run a minimal ROCKS installation (kernel, os, base, ganglia, hpc, webserver). We manually install java on the head-node and all compute-nodes. Then all the other software and scripts are written in house. At the moment, we are not using any queue-ing software. We have a very small number of users (at most 2) and thus find it easier just to be civil at this point.

Our extra "scavenged" computers happen to be Celerons which are 32-bit. So far, we have been too lazy to figure out how to "cross-kickstart" them as ROCKS nodes. The simple solution is to just install some version of Linux (we have used Fedora 7) and then just create all the directories that ROCKS normally puts on the compute nodes for the main local partition (/state/partition1/), set up NFS to share all the goodies that we normally share between the front-end and the compute nodes, put a symbolic link for the .ssh directory so that you can do password-less logins, and install the ganglia monitor (stealing the configuration file from a "real" compute node). It's kinda ugly, but it works like a dandy. (Oh, and you have to have "insert-ethers" running on the front-end the first time you boot up the fake nodes so that they will be assigned an ip-address and name via dhcp. insert-ethers will complain that it was unable to kickstart the new nodes, but no harm done...) As long as!
  t!
he .ssh directories are linked up, even cluster-fork will still work.

As a performance comparison, we have made a little benchmark program that just runs a few iterations of a neural network solver on a bit of real data. It turns out that the nodes in our mini-cluster run roughly 2.2 times as fast as the nodes on tungsten. Part of the difference is naturally newer hardware. The other possible source of disparity is that the tungsten nodes are 64-bit Xeon processors, but for some reason their operating system won't let you install 64-bit java. So, we are left running 32-bit java on a 64-bit OS and CPU. Furthermore the tungsten nodes are dual processor, but we get much less than perfect parallelism: 2 identical tasks run 74.9% as fast running only one at a time. In contrast, the nodes in our mini-cluster (dual core on one chip) seem to run right around perfect parallelism (sometimes better than perfect, sometimes worse: probably just the noise in the system).

Overall, we now have a computing capacity that is on the same order as the amount we were ever able to consistently obtain from tungsten. When we add more nodes, we will have more power than we were able to get our hands on. Additionally, we do not have to fight through the queue and control of the cluster is only bounded by our competence (or lack thereof).

Hope you enjoyed the blurb.

peace,

Ricky Robertson
Post-Doc, Agricultural and Consumer Economics

From jim at ks.uiuc.edu  Tue Jul 31 14:53:44 2007
From: jim at ks.uiuc.edu (Jim Phillips)
Date: Tue, 31 Jul 2007 14:53:44 -0500 (CDT)
Subject: [cluster-l] another system summary
In-Reply-To: <20070731130807.ASZ14129@expms5.cites.uiuc.edu>
References: <20070731130807.ASZ14129@expms5.cites.uiuc.edu>
Message-ID: <Pine.LNX.4.63.0707311445520.12768@paris.ks.uiuc.edu>

Hi,

Thanks for the great summary.  I just wanted to point out that the 
Tungsten processors are actually 32-bit (and three years old).  I'm not 
surprised you're seeing much greater throughput on your own cluster.  I'm 
sure you'll make your money back in human time alone!

I think you'll find that adding a queueing system makes life easier even 
if you only have one user, since it monitors your jobs for you and keeps 
the nodes busy.  I like Grid Engine, but whatever Rocks supports best is 
probably fine.  Please also let us know in a couple of months how reliable 
your system turns out to be.

-Jim