Scalability of CHARMM on various architectures

[axelsen at axe1.med.upenn.edu]

We are designing a cluster for which the most important code will be the
computational chemistry program, CHARMM.  In our preliminary tests on
an existing cluster, we have confirmed our expectation that interthread 
communications will be our first bottleneck.  A test run on a typical 
problem did not scale beyond 4 nodes on a cluster composed of P2-450
processors and fast ethernet interconnections.  In contrast, the same
code scales almost perfectly up to at least 12 processors on an SGI-Unix 
SMP machine.  CHARMM uses PVM.

I would appreciate contact from anyone who has run CHARMM on a cluster
and has considered the best way to make this code scale better.  From 
anyone, I would appreciate general guidance on several issues:

 * If we go with pentium II/III processors, how far is Myrinet likely to
   permit us to scale these calculations?

 * With Myrinet, would alpha nodes tend to scale any better than pentium nodes?

   (a single 500 MHz alpha processor is about 1.6-fold faster than a 
    single 450 MHz P2 on a typical problem, but it is about 3-fold the
    cost.  With this question, I am looking for any additional advantages 
    of alpha to justify this cost)

 * Are there differences between different pentium chip sets that will impact
   this problem?

 * Is there any advantage to buying dual-processor machines, either alpha
   or pentium, with respect to scaling?  Any advantage to dedicating one 
   processor in each dual-box to communications?  If we dedicate processors
   in this way, would both processors have to have the same clock speed?




------------- axe at pharm.med.upenn.edu -----------------
                                                       
Paul H. Axelsen               ....   ....  .   .  .   .
Department of Pharmacology    .   .  .     ..  .  ..  .
University of Pennsylvania    ....   ...   . . .  . . .
3620 Hamilton Walk            .      .     .  ..  .  ..
Philadelphia, PA 19104-6084   .      ....  .   .  .   .

-------------------------------------------------------