From chemistry-request@server.ccl.net Fri Mar 31 15:58:56 2000 Received: from lrz.uni-muenchen.de (root@lsanca1-ar99-078-042.biz.dsl.gtei.net [4.3.78.42]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id PAA29716 for ; Fri, 31 Mar 2000 15:58:55 -0500 Received: (from eugene.leitl@localhost) by lrz.uni-muenchen.de (8.8.8/8.8.8) id MAA24271 for ; Fri, 31 Mar 2000 12:59:16 -0800 Resent-From: Eugene Leitl Resent-Message-ID: <14565.4516.583979.791661@lrz.uni-muenchen.de> Resent-Date: Fri, 31 Mar 2000 12:59:16 -0800 (PST) Resent-To: Message-Id: <200003311552.KAA27337@jazz.ncren.net> Organization: Queens College - Charlotte, NC MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Priority: normal In-reply-to: <14564.3211.928734.38138@lrz.uni-muenchen.de> X-mailer: Pegasus Mail for Win32 (v3.12b) From: "Andy Tucker" To: Eugene Leitl CC: beowulf@beowulf.gsfc.nasa.gov Subject: Re: CCL:Scaling of G98 on Clusters Date: Fri, 31 Mar 2000 10:54:57 EST Warning: Onageristic Estimate follows... > this question goes to those who use Gaussian 98 (or maybe also other > versions) on workstations clusters. > > Now, I ran the jobs with a-pinene and abietic acid (a mono- and a > diterpene) with 1, 4, 8, 12 and 16 nodes to see how the setup scales. > What I see is an almost linear scaling up to 4 nodes. With eight nodes > the effective speedup is still nice with 6.41 where perfect behaviour > obviously would be 8.00. But then it gets worse as you see and when > going from 12 to 16 nodes the calculation even slows down. Here are the > numbers. > > Is this bad scaling to be expected? The graph on the gaussian web site > shows the speedup of the calculations up to six nodes and I begin to > understand why that is :-) I'm just getting started with some parallel molecular dynamics calculations, so I can't claim to be an expert. However, upon reading about the Gaussian scaling problem, it seems that this could be a general problem in computational chemistry calculations. The program "GROMACS" does molecular dynamics on large systems, and scales pretty well up to 8 nodes, and performance starts to slack off after that point. (see http://rugmd0.chem.rug.nl/~gmx/gmxbench.html ) My guess is that there is a similar cause for the problems observed in Gaussian and GROMACS. GROMACS splits molecular systems into several pieces(slabs), one for each node. Each node does a calculation on its piece of the molecule, then passes on information to neigboring pieces of the molecule for subsequent calculations. As you increase the number of nodes, the size of the system treated by each node becomes smaller. Depending on the size of the whole system, there will naturally be a point at which the calculations on each node take a short period of time relative to the time required for communication between nodes. At that point the cluster begins to need more time for IO rather than calculations, and the scaling drops. I would expect larger systems to scale better than smaller ones, and one can imagine having a system so small that it's not even worthwhile to use 2 processors. I don't have any experience with ab initio calculations on clusters, but I would guess that the parallel implementation would be similar, splitting up the system into smaller pieces, with frequent correlation between nodes, so one would expect the same behavior. Again, I'm making this up as I go along, but it seems reasonable, and I'd love to hear from someone who has more experience. andy Dr. W. Andrew Tucker Queens College Chem. Dept. tuckera@queens.edu 1900 Selwyn Ave. (704)337-2317 Charlotte, NC 28277 From chemistry-request@server.ccl.net Fri Mar 31 15:59:53 2000 Received: from lrz.uni-muenchen.de (root@lsanca1-ar99-078-042.biz.dsl.gtei.net [4.3.78.42]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id PAA29730 for ; Fri, 31 Mar 2000 15:59:52 -0500 Received: (from eugene.leitl@localhost) by lrz.uni-muenchen.de (8.8.8/8.8.8) id NAA24316 for ; Fri, 31 Mar 2000 13:00:14 -0800 Resent-From: Eugene Leitl Resent-Message-ID: <14565.4573.961249.887488@lrz.uni-muenchen.de> Resent-Date: Fri, 31 Mar 2000 13:00:13 -0800 (PST) Resent-To: X-Authentication-Warning: ganesh.phy.duke.edu: rgb owned process doing -bs In-Reply-To: <002901bf9adb$4bba0220$0100a8c0@chem.wsu.edu> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk From: "Robert G. Brown" To: Phillip Matz cc: beowulf@beowulf.gsfc.nasa.gov Subject: Re: Fw: CCL:Scaling of G98 on Clusters Date: Fri, 31 Mar 2000 08:52:01 -0500 (EST) On Thu, 30 Mar 2000, Phillip Matz wrote: > > And one last comment, I was completely amazed at how easy and accurate it > > was to model my G98 beowulf's performance based on the simple equations > > found in Dr. Brown's beowulf profiling guide - so thank you Dr. Brown! > > > > Respectfully, > > Phillip Matz Aw, you'll make me blush...;-) Remember, I didn't really derive any of that stuff, I just digested the work of many other people in the talk. I've also been trying to update the brahma site with a few even simpler talks, this time with scaling figures. The real moral of the exercise is that beowulfery is really truly a form of parallel computing, and one can (with a bit of effort) understand the way various (e.g. IPC) times limit parallel scaling in a calculation. It is therefore worth getting a book or two on parallel computing or using the online book by Ian Foster at: http://www-unix.mcs.anl.gov/dbpp/ to learn about parallel algorithms and so forth. I've tried to summarize in simple form a lot of the very simple per-processor scaling so people can understand why it might be stupid to build a 128 node beowulf (even if they can afford it easily) to tackle a problem that has a peak speedup at only 8 nodes for their chosen hardware. On the other hand, spending all that money on 4x more expensive hardware with much faster networking, they might not reach their peak speedup until 32 nodes. However, there is a lot more to learn about things like the scaling of algorithms with problem size. That's what real computer scientists are for -- they work out all this stuff for us, if only we'd take the time to learn about what they've done. rgb Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to beowulf-request@beowulf.org From chemistry-request@server.ccl.net Sun Apr 2 10:47:27 2000 Received: from ccl.net (atlantis.ccl.net [192.148.249.4]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id KAA08186 for ; Sun, 2 Apr 2000 10:47:25 -0400 Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ccl.net (8.9.3/8.9.3/OSC 2.0) with ESMTP id KAA03462 for ; Sun, 2 Apr 2000 10:47:11 -0400 (EDT) Received: from feldmann.nist.gov (feldmann.nist.gov [129.6.178.78]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id KAA00658; Sun, 2 Apr 2000 10:43:00 -0400 (EDT) Received: from localhost (chem@localhost) by feldmann.nist.gov (8.8.8+Sun/8.8.8) with SMTP id KAA19288; Sun, 2 Apr 2000 10:25:12 -0400 (EDT) Date: Sun, 2 Apr 2000 10:25:12 -0400 (EDT) From: Steve Heller To: lists , amber@cgl.ucsf.edu, APPLSPEC@listserv.uga.edu, cache@pacificu.edu, CHEMED-L@atlantis.UWF.EDU, CHEMIG@LIST.NIH.GOV, CHEMISTRY@www.ccl.net, isisforum-l@mdli.com, listproc@msi.com, listserver@ic.ac.uk, mailbase@mailbase.ac.uk, MOL-DIVERSITY@LISTSERV.ARIZONA.EDU, molecular-dynamics-news@mailbase.ac.uk, pdb-l@rcsb.org, PHILCHEM@VM.SC.EDU, spectroscopy-group@mailbase.ac.uk, ToxList@esc.syrres.com Subject: IUPAC Chemical Identifier Project (IChIP) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII April 2, 2000 IUPAC Chemical Identifier Project (IChIP) The initial meeting of the IUPAC Strategy Round Table: Representation of Molecular Structure: Nomenclature and Its Alternatives, was held on March 10-11, 2000 at the National Academy of Sciences in Washington DC. As noted in the minutes (see below) from that meeting, the group agreed to study the feasibility of creating an IUPAC chemical identifier. Steve Heller and Steve Stein (NIST) were asked to coordinate this task and provide a feasibility report to the IUPAC Secretariat including a potential plan of action by the fall of 2000. This message is being sent to attendees of the meeting, as well as a wide audience of chemists, information specialists, and others to solicit comments and suggestions concerning technical issues involved in developing a standard unique digital representation of chemical structures. Steve Stein and I would appreciate a response from you by 1 May 2000. At this initial stage, we are particularly concerned with the representation of well-defined covalently-bonded molecules. Please feel free to pass this information on to any colleague you believe would be interested in this project. A variety of methods have been proposed for deriving a unique digital "name" from a defined chemical structure. We wish to begin by collecting and comparing available methods that may be applied to this task along with known deficiencies and other technical concerns. Specifically, we wish to consider the pros and cons of various chemical structure normalization rules (e.g., tautomerization, aromatization, etc.) and related issues along with available "canonicalization" schemes leading to a creation of a unique digital "name". In addition, we wish to consider any standards that may be needed for structure entry to ensure unambiguous name by any structure-drawing package. Finally, complete specification of a single chemical substance will require additional qualifiers, including stereochemistry, geometrical configuration, chemical state, charge, electronic state, etc. We expect to include these as pre-defined fields separable from the basic connectivity information. It is intended that the rules leading to the formulation of a unique digital representation from a chemical structure will be openly available and capable of being extended to a wider range of chemical structures, including, for example, organometallic compounds, polymers, incompletely-defined structures and compound classes. Steve Heller/Steve Stein ------------ IUPAC - Summary of report the the IUAPC Executive Committee - San Francisco, CA March 24-25, 2000 The IUPAC Executive Committee approved the formation of an ad hoc Committee on Chemical Identity and Nomenclature Systems, with Dr. Alan McNaught as Chairman. The CCINS will be responsible for developing systems for conventional and computer-based chemical nomenclature; cooperating with the four nomenclature Commissions (until the end of 2001); coordinating interdisciplinary activities in the nomenclature field; and recommending to the Bureau long-range strategy on chemical nomenclature. It is expected that this body will provide the long-term central planning, management and coordination of chemical nomenclature that would otherwise be lost when the Commissions are discontinued at the end of 2001. The Executive Committee also approved a feasibility study of the Chemical Identifier project, to be managed by the CCINS. Chemical Identifier A proposal by Dr. Stephen Heller for a major new IUPAC initiative was extensively discussed and clarified during the IUPAC Nomenclature Round Table. Framed initially in terms of an "IUPAC chemical registry system," the proposal was recast as a "chemical identifier" - a meaningful alphanumeric text string that can uniquely identify a chemical compound and facilitate its handling in computer databases. This code would be the equivalent of an IUPAC systematic name but would be designed to be easily used by computers. The Identifier could also include other information about the specific substance in question. There are several issues to be resolved as indicated below. The participants recommended that the feasibility of the project and resolution of these issues be carried out as soon as possible by representatives of a wide range of interested parties. Drs. Heller and Stein (NIST) were asked to recommend a list of individuals and groups that should be consulted initially and to propose a framework for addressing the issues. The aim of the IUPAC Chemical Identifier (IChI) Project is to establish a unique label, the IUPAC Chemical Identifier (IChI), which would be a non-proprietary identifier for chemical substances that could be used in printed and electronic data sources thus enabling easier linking of diverse data compilations. IChI will not require the establishment of a registry system. Unlike the CAS Registry System, it will not depend on the existence of a database of unique substance records to establish the next available sequence number for any new chemical substance being assigned an IChI. It will use a, yet to be defined, set of IUPAC structure conventions, and rules for normalisation and canonicalisation of the structure representation to establish the unique label. It will thus enable an automatic conversion of a graphical representation of a chemical substance into the unique IChI label which can be performed anywhere in the world and which could be built into desktop chemical structure drawing packages (such as ChemDraw, ISIS/Draw, etc.) and online chemical structure drawing applets (such as ACD/Draw). The brainstorming session after the IUPAC Strategy Round Table in Washington suggested a number of mutually incompatible attributes for IChI: 1. It should be short and easily usable by humans and contain a check digit which could detect typing errors such as transposition of characters (as in the CAS Registry number) 2. It should be fully reversible (i.e., a computer should be able to convert IChI back into a structure representation which can be displayed) which is likely to result in a representation too long to be used by humans 3. It should contain intelligence (i.e., it should group families of salts, stereo isomers, etc.) and thus be a type of classification system. Consensus needs to be obtained by the working group set up to investigate the feasibility of the project [or imposed by IUPAC management] before the IChI project can proceed to establish working groups to look at structure conventions and the rules for normalisation and canonicalisation. The process flows from input by a chemist of a structure, using drawing software, to the creation of the Identifier. IUPAC would define three aspects of this process: the rules for drawing a structure, the form of the in-memory representation of the structure diagram, and the mathematical algorithm for converting the in memory representation to a text string, the Identifier. The steps to convert from the drawn structure to the machine representation, normalization and canonicalization, would be done by vendor developed software. This part of the process has been implemented by a number of software developers. The new aspect to be introduced by IUPAC would be a standard data table structure. The definition of a standard data table structure is necessary to allow the next step, the conversion of the data table to an alphanumeric text string. IUPAC would define the mathematical algorithm, the implementation of the algorithm would be left to interested software developers. The output from application of the algorithm would be the IUPAC Chemical Identifier. The process would be reversible if criterion 2 above is met, so that the Identifier could be used to recreate the machine representation. This would then allow either display of the structure or generation of the IUPAC name. The Identifier would thus serve as the computer equivalent of the IUPAC name for a molecule. This would facilitate searching the internet and labeling information in electronic documents with the name of the chemical substance in question. ---------------- Stephen R. Heller, Ph. D. Guest Researcher NIST/SRD, Mail Stop: 820/113 100 Bureau Drive 820 Diamond Avenue, Room 101 Gaithersburg, MD 20899-2310 USA Phone: 301-975-3338 FAX: 301-926-0416 E-mail: steve@hellers.com WWW: www.hellers.com/~steve -------------------------------------------------- As a member of the Organizing Committee, I invite you to attend Chemistry & the Internet - ChemInt2000; September 23-26, 2000; Washington, DC. http://www.chemint.org From chemistry-request@server.ccl.net Sun Apr 2 15:24:20 2000 Received: from ccl.net (atlantis.ccl.net [192.148.249.4]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id PAA09363 for ; Sun, 2 Apr 2000 15:24:19 -0400 Received: from host241.abbott.com (host241.abbott.com [207.140.194.241]) by ccl.net (8.9.3/8.9.3/OSC 2.0) with SMTP id PAA05678 for ; Sun, 2 Apr 2000 15:23:27 -0400 (EDT) Received: by host241.abbott.com id OAA27369 (InterLock SMTP Gateway 3.0 for CHEMISTRY@www.ccl.net); Sun, 2 Apr 2000 14:18:41 -0500 Received: by host241.abbott.com (Internal Mail Agent-3); Sun, 2 Apr 2000 14:18:41 -0500 Received: by host241.abbott.com (Internal Mail Agent-2); Sun, 2 Apr 2000 14:18:41 -0500 Received: by host241.abbott.com (Internal Mail Agent-1); Sun, 2 Apr 2000 14:18:41 -0500 From: "Martin,Yvonne" To: , , Cc: Subject: PD3 Series on Hydrophobicity and Solvation Message-Id: <0055600026798438000002L082*@MHS> Date: Sun, 2 Apr 2000 14:19:21 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.ccl.net id PAA09364 >From the preface: &Our intention, in editing a series of issues of Perspectives in Drug Discovery and Design on the topic of including solvation in the prediction of binding affinity, is to bring together a broad spectrum of expertise into a frank and direct treatise on the state of present day understanding of the desolvation phenomena as they relate to drug discovery. Every contribution is designed to be accessible to the broad range of scientists interested in the application of computers to problems in drug discovery. We expect to challenge each sub-discipline of computational drug discovery with new information and viewpoints and hope that this leads to progress in this challenging problem.8 The following are the titles in the first three volumes in this series: Volume 17, 1999 Yvonne C. Martin and Robert S. DeWitte, editors Corwin Hansch and Albert Leo: On the Role of Hydrophobic Effects in Mechanistic QSAR Frank Eisenhaber: Hydrophobic Regions on Protein Surfaces Dudley Williams and Ben Bardsley: The Hydrophobic Effect and Cooperativity Paul Ruelle: Towards a Comprehensive Non-Ergodic Treatment of H-bonds and Hydrophobicity in Real Solutions: The Mobile Order and Disorder (MOD) Theory Greg Hura, Jon Sorenson, Robert Glaeser, and Teresa Head-Gordon: Solution X-ray Scattering as a Probe of Hydration-Dependent Structuring of Aqueous Solutions Volume 18, 2000 Yvonne C. Martin and Robert S. DeWitte, editors Raimund Mannhold and Roelof Rekker: The Hydrophobic Fragmental Constant Approach for Calculating Log P in Octanol / Water and Aliphatic Hydrocarbon / Water Systems Albert Leo and David Hoekman : Calculating logP with No Missing Fragments Christian Laurence and Michel Berthelot : Observations on the Strength of Hydrogen Bonding Paul Ruelle, America Farina-Cuendet and Ulrich Kesselring : Solvation versus Solvophobicity in the Dissolution of Hydroxysteroids: An Analysis from the Mobile Order and Disorder (MOD) Theory Irina Massova and Peter A. Kollman: Combined Molecular Mechanical and Continuum Solvent Approach (MM-PBSA/GBSA) to Predict Ligand Binding Volume 19, 2000 Yvonne C. Martin, editor Ulf Norinder and Thomas Osterberg : The Applicability of Computational Chemistry in the Evaluation and Prediction of Drug Transport Properties Peter Buchwald: Modeling Liquid Properties, Solvation, and Hydrophobicity: A Molecular Size-Based Perspective Renxiao Wang, Ying Gao, and Luhua Lai: Calculating Partition Coefficient by Atom-Additive Method William M. Meylan and Philip H. Howard: Estimating logP with Atom/Fragments and Water Solubility with logP Vellarkad N. Viswanadhan, Arup K. Ghose, and John J. Wendoloski: Estimating Aqueous Solvation and Lipophilicity of Small Organic Molecules: A Comparative Overview of Atom/Group Contribution Methods Alanas A. Petrauskas and Eduard A. Dolovanov: ACD/LogP Method Description James Devillers: EVA/PLS versus Autocorrelation/Neural Network Estimation of Partition Coefficients Roustem D. Saiakhov, Liliana R. Stefan and Gilles Klopman: Multiple Computer-Automated Structure Evaluation Model of the Plasma Protein-Bidning Affinity of Diverse Drugs Stefan Balaz: Lipophilicity in Trans-bilayer Transport and Subcellular Pharmacokinetics Bernard Testa, Patrizia Crivori, Marianne Reist, and Peirre-Alain Carrupt: The Influence of Lipophilicity on the Pharmacokinetic Behavior of Drugs: Concepts and Examples PD3 is published by Kluwer Academic Publishers as a companion volume to Journal of Computer-Aided Molecular Design P.O. Box 17, 3300 AA Dordrecht, the Netherlands Phone: (+31) 78 639 23 92 Fax: (+31) 78 639 22 54 http://www.wkap.nl/journalhome.htm/0928-2866 Yvonne C. Martin D-47E, AP10/2 100 Abbott Park Rd Abbott Park IL 60064-6100 yvonne.c.martin@abbott.com From chemistry-request@server.ccl.net Sun Apr 2 15:31:16 2000 Received: from deimos.cber.nih.gov (deimos.cber.nih.gov [128.231.52.2]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id PAA09382 for ; Sun, 2 Apr 2000 15:31:16 -0400 Received: from localhost by deimos.cber.nih.gov with SMTP (1.37.109.14/16.2) id AA001353010; Sun, 2 Apr 2000 15:16:50 -0400 Date: Sun, 2 Apr 2000 15:16:50 -0400 (EDT) From: Rick Venable To: Andy Tucker Cc: Eugene Leitl , beowulf@beowulf.gsfc.nasa.gov, chemistry@ccl.net Subject: Re: CCL:Scaling of G98 on Clusters In-Reply-To: <200003311552.KAA27337@jazz.ncren.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have observed similar behavior for CHARMM recently-- reasonable scaling for up to 8 nodes, but problems with e.g. 16 nodes. This is using MPI on either 100baseT or Gbit ethernet as the host-to-host transport within a cluster of Intel-based machines running Linux (RH). It seems to be typical of tightly coupled parallel calculations, where there is significant data passing between processing streams. Ethernet based Linux clusters seem to be I/O bound for more than 8 processors. I suspect packet collisions may be an issue-- IP ethernet protocols tend to degrade under heavy load. One factor in this is that when 2 packets arrive at a host interface at the same time (collide), BOTH get rejected, and both originating hosts must resend the packet. I'm a little surprised that a high speed token ring interface hasn't been developed and marketed for such dedicated, sustained high bandwidth applications. Myrinet does offer an alternative to TCP/IP ethernet, which shows better scaling for 8 processors (I hope to test 16 sometime soon), but the board cost is ca. $1000 US and requires custom switches as well. Problem partioning (load balancing) and synchronization frequency are other factors in this situation; all processors are limited to the rate of the slowest process stream. For parallel MD, where synchronization is required on every time integration step (global sums, etc.), load imbalances can have a significant impact. A substantial effort was expended into determining the best heuristic to use for partitoning the nonbond pair list (list sequence, spatial decomposition, etc.) within CHARMM to achieve good load balancing. The frequent synchronization means, however, that all nodes are trying to communicate and obtain results simultaneously on each timestep, a scenario which invites collisions on ethernet transports. > > this question goes to those who use Gaussian 98 (or maybe also other > > versions) on workstations clusters. > > > > Now, I ran the jobs with a-pinene and abietic acid (a mono- and a > > diterpene) with 1, 4, 8, 12 and 16 nodes to see how the setup scales. > > What I see is an almost linear scaling up to 4 nodes. With eight nodes > > the effective speedup is still nice with 6.41 where perfect behaviour > > obviously would be 8.00. But then it gets worse as you see and when > > going from 12 to 16 nodes the calculation even slows down. Here are the > > numbers. On Fri, 31 Mar 2000, Andy Tucker wrote: > I'm just getting started with some parallel molecular dynamics > calculations, so I can't claim to be an expert. However, upon > reading about the Gaussian scaling problem, it seems that this > could be a general problem in computational chemistry > calculations. > > The program "GROMACS" does molecular dynamics on large > systems, and scales pretty well up to 8 nodes, and performance > starts to slack off after that point. (see > http://rugmd0.chem.rug.nl/~gmx/gmxbench.html ) -- Rick Venable =====\ |=| "Eschew Obfuscation" FDA/CBER Biophysics Lab |____/ |=| Bethesda, MD U.S.A. | \ / |=| ( Not an official statement or Rick_Venable@nih.gov | \ / |=| position of the FDA; for that, rvenable@speakeasy.org \/ |=| see http://www.fda.gov )