From owner-chemistry@ccl.net Fri Sep 30 01:05:00 2005 From: "CCL" To: CCL Subject: CCL: Open source contributions by pharma. Message-Id: <-29408-050929200626-4197-eKLzqCqaeXDaQnLOvzpcUA^_^server.ccl.net> X-Original-From: "Miklos Vargyas" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 30 Sep 2005 01:04:47 +0200 MIME-Version: 1.0 Sent to CCL by: "Miklos Vargyas" [mvargyas^_^chemaxon.hu] --Replace strange characters with the "at" sign to recover email address--. ChemAxon's Screen tool generates various molecular descriptors (e.g. BCUT, pharmacophore and chemical fingerprints, logP, topological PSA, etc). It provides plug-and-play technology to integrate custom (user defined or third party) descriptors. Marvin (structure visualization and drawing tool) generates 3d coordinates for 2d input structures, multiple conformations can also be generated. MarvinSpace does 3D visualization (small and macromolecules), not yet as mature as MOE but it is evolving rapidly. ChemAxon software are affordable and free for academic users. Miklos Vargyas ----- Original Message ----- > From: "CCL" To: "Vargyas, Miklos " Sent: Thursday, September 29, 2005 10:24 AM Subject: CCL: Open source contributions by pharma. > > Sent to CCL by: peter murray-rust [pm286^cam.ac.uk] > > --Replace strange characters with the "at" sign to recover email address--. > > At 00:46 29/09/2005, CCL wrote: > > >Sent to CCL by: "Peter Spiro" [spiro(a)renovis.com] > > > > > >On the subject of cheminformatics applications such as descriptor > >calculation, conformational search, QSAR, etc, I'd be interested to > >know people's recommendations for open source/free/cheap software in > >this area. Is there anything that comes close to, say, MOE? > > > > One of the approaches is to produce interoperable tools that can be > combined to fit a problem. With that in mind a number of us have > formed "The Blue Obelisk" - a virtual collaboration of some of the > main Open groups in this area. See: > http://geoffhutchison.net/blog/archives/2005/03/14/the-blue-obelisk-movement / > http://wwmm.ch.cam.ac.uk/presentations/acs2005/communal/blueobelisk.html > http://almost.cubic.uni-koeln.de/jrg/pictures/blueobeliskfolder/zphotoslides folder_view > > The philosophy is: > * Open: Access, Data, Standards, Source > * consistent and complementary > * non-divisive and fun > Components include > * CDK > * JChempaint > * Jmol > * JOELib > * JUMBO > * NMRShiftDB > * Octet > * Openbabel > * QSAR > * WWMM > The underlying concept is that all members create software to > interoperate with the others. This means careful attention to > interfaces, APIs, ontologies/dictionaries, reference data sets, etc. > Anyone is welcome to add their project to the group as long as (a) > the software is developed under an OSI license (not just "free") (b) > there is a conscious effort to use communal > metadata/dictionaries/reference data where possible (for example we > all try to use the same atomic weights (c) Open standards > (particularly W3C/XML) are used where possible. > > We have integrated much of this with Open workflow/pipeline systems > (e.g. Taverna, Kepler) and are looking to use R for much of the > statistical analysis and management. With these tools it is possible > to build systems of great scope. There are currently a few components > that we lack and we'd be extremely grateful for anyone who can > contribute (note that data/metadata/specifications are as important as source). > > We also believe that WebServices (WSDL) will be extremely valuable as > they can greatly reduce the problem of language and platform > incompatibility. For example we have mounted an InChI server so that > anyone wanting an InChI can send a WSDL request rather than have to > install and wrap the InChI program. A number of Blue Obelisk members > are starting to offer QSAR services or descriptors in this way > > P.Peter Murray-Rust > Unilever Centre for Molecular Sciences Informatics > University of Cambridge, > Lensfield Road, Cambridge CB2 1EW, UK > +44-1223-763069> > > From owner-chemistry@ccl.net Fri Sep 30 01:40:03 2005 From: "CCL" To: CCL Subject: CCL: Madelung or Klechkovski /Aufbau principle Message-Id: <-29409-050929233316-3537-lf9JTXZ1wkgJpwvfis/z6Q~!~server.ccl.net> X-Original-From: Eric Scerri Content-Type: multipart/alternative; boundary="============_-1084071427==_ma============" Date: Thu, 29 Sep 2005 19:17:41 -0700 Mime-Version: 1.0 Sent to CCL by: Eric Scerri [scerri~!~chem.ucla.edu] --Replace strange characters with the "at" sign to recover email address--. --============_-1084071427==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable >Can someone explain how Madelung-- Klechkovski (or Kelchkowki's) >rule differ from >the Aufbau principle (Aufbauprinzip) described by >Niels Bohr circa >1920? No difference except the n + l rule gives the actual order, which is read off the empirical data. Bohr's aufbau is that orbitals fill in order of increasing energy. He could not derive this order, except empirically from spectra and chemical properties of atoms although he often gave the impression that he was deducing it from principles. This has been written about by Kragh and myself in several articles. The rule is just a convenient mnemonic for spelling out the aufbau. eric scerri > > > Kenneth Butenhof phone: 800 756-4674 >Principal Scientist email: kenb~!~accelrys.com >Accelrys Inc. web: www.accelrys.com > > >"CCL" >Sent by: owner-chemistry~!~ccl.net > >09/29/2005 10:25 AM >Please respond to >"CCL Subscribers" > >To >"Butenhof, Ken " >cc >Subject >CCL: Madelung or Klechkovski ? > > > > > >Sent to CCL by: Anastassia Alexandrova [anastassia.alexandrova:+:yale.edu] > >--Replace strange characters with the "at" sign to recover email address--. > >In Russia people teach Klechkovskyi rule. So another 1/6th of the World >thinks it was Klechkovskyi. > >-- >Anastassia Alexandrova, Ph.D. >Yale University >Department of Chemistry >225 Prospect Street >New Haven, CT 06520-8107 >Phone: 203-432-6288 >Fax: 203-432-6144 >anastassia.alexandrova~!~yale.edu >http://zarbi.chem.yale.edu/~anastassia/ > > >Quoting CCL : > >> >> Sent to CCL by: Paul Fleurat-Lessard >> [Paul.Fleurat-Lessard:-:ens-lyon.fr] >> >> --Replace strange characters with the "at" sign to recover email >> address--. >> >> Dear Xavier, >> >> During my teaching experience in france, I also discovered that the >> >> Kelchkowki rules are, as we say in France, a cultural exception ! >> While >> searching for the origin of these rules, I found that most of the >> countries refer to them as 'the aufbau principle' (something like the >> >> 'construction principle'), but I have no reference about it. May be >> some >> CCLers can help us on this ! >> >> I took some time searching through some database, and Klechkowsky >> name >> never appeared... >> >> Regards, >> Paul. >> >> -- >> Fleurat-Lessard Paul, Lecturer e-mail: >> Paul.Fleurat-Lessard~!~ens-lyon.fr >> Laboratoire de Chimie >> Ecole Normale Sup=E9rieure de Lyon Tel: + 33 (0)4 72 72 81 >> 54 >> 46, All=E9e d'Italie Fax: + 33 (0)4 72 72 88 >> 60 >> 69364 Lyon Cedex 07 >> >> Si vous ne pouvez expliquer un concept =E0 un enfant de six ans, >> c'est que vous ne le comprenez pas compl=E8tement. >> Albert Einstein >> >> >> >> -=3D This is automatically added to each message by the mailing script >> =3D- >> To recover the email address of the author of the message, please >> change> >> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >+-+ >> >> >> > > > >-=3D This is automatically added to each message by the mailing script =3D-> > > > > > > >-- >Click on the link below to report this email as spam >https://www.mailcontrol.com/sr/Fn6kLNLmVN8eBfTljOp+PEZHUEeihbupL6fNoe1YRahu= S7jsR6G+dMtRoHlUzjHw+4NaKEq4vCC4N3AcDbBM5+CCqNntONU5r4U1gUc9fU9n!4OiIDLjbpff= OF3Drvvl5jw4ANltGpJxqfx8gsAj02!hAfoKUTbNzd9RBlstxIUnmQhx1IsJ9iX6GcBKtJSaDASE= 1fBJY82oV2JwgT4t71NOO9GFnNxV -- Dr. Eric Scerri , UCLA, 4077C, Young Hall, Department of Chemistry & Biochemistry, 607 Charles E. Young Drive East, Los Angeles, CA 90095-1569 USA E-mail : scerri~!~chem.ucla.edu tel: 310 206 7443 fax: 310 206 2061 Web Page: http://www.chem.ucla.edu/dept/Faculty/scerri/index.html Editor-in-chief of Foundations of Chemistry http://springerlink.metapress.com/app/home/journal.asp?wasp=3D503c4f278d734f= 3f957c34496b6939dc&referrer=3Dparent&backto=3Dlinkingpublicationresults,1:10= 3024,1 Also see International Society for the Philosophy of Chemistry http://ispc.sas.upenn.edu/ --============_-1084071427==_ma============ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: CCL: Madelung or Klechkovski /Aufbau principle
Can  someone explain how   Madelung-- Klechkovski (or Kelchkowki's) rule differ > from
the  Aufbau principle (Aufbauprinzip) described by Niels Bohr circa 1920?


No difference except the n + l rule gives the actual order, which is read off the empirical data.

Bohr's aufbau is that orbitals fill in order of increasing energy.
He could not derive this order, except empirically from spectra and chemical properties of atoms although he often gave the impression that he was deducing it from principles.  This has been written about by Kragh and myself in several articles.

The rule is just a convenient mnemonic for spelling out the aufbau.


eric scerri






 Kenneth Butenhof          phone:  800 756-4674
Principal Scientist          email:    kenb~!~accelrys.com
Accelrys Inc.                   web:     www.accelrys.com


"CCL" <owner-chemistry~!~ccl.net>
Sent by: owner-chemistry~!~ccl.net
09/29/2005 10:25 AM
Please respond to
"CCL Subscribers" <chemistry~!~ccl.net>

To
"Butenhof, Ken " <kenb~!~accelrys.com>
cc
Subject
CCL: Madelung or Klechkovski ?





Sent to CCL by: Anastassia Alexandrova [anastassia.alexandrova:+:yale.edu]

--Replace strange characters with the "at" sign to recover email address--.

In Russia people teach Klechkovskyi rule. So another 1/6th of the World
thinks it was Klechkovskyi.

--
Anastassia Alexandrova, Ph.D.
Yale University
Department of Chemistry
225 Prospect Street
New Haven, CT 06520-8107
Phone: 203-432-6288
=46ax: 203-432-6144
anastassia.alexandrova~!~yale.edu
http://zarbi.chem.yale.edu/~anastassia/


Quoting CCL <owner-chemistry~!~ccl.net>:

>
> Sent to CCL by: Paul Fleurat-Lessard
> [Paul.Fleurat-Lessard:-:ens-lyon.fr]
>
> --Replace strange characters with the "at" sign to recover email
> address--.
>
> Dear Xavier,
>
> During my teaching experience in france, I also discovered that the
>
> Kelchkowki rules are, as we say in France, a cultural exception !
> While
> searching for the origin of these rules, I found that most of the
> countries refer to them as 'the aufbau principle' (something like the
>
> 'construction principle'), but I have no reference about it. May be
> some
> CCLers can help us on this !
>
> I took some time searching through some database, and Klechkowsky
> name
> never appeared...
>
> Regards,
> Paul.
>
> --
> Fleurat-Lessard Paul, Lecturer  e-mail:
> Paul.Fleurat-Lessard~!~ens-lyon.fr
> Laboratoire de Chimie
> Ecole Normale Sup=E9rieure de Lyon              Tel: + 33 (0)4 72 72 81
> 54
> 46, All=E9e d'Italie                            Fax: + 33 (0)4 72 72 88
> 60
> 69364 Lyon Cedex 07
>
> Si vous ne pouvez expliquer un concept =E0 un enfant de six ans,
> c'est que vous ne le comprenez pas compl=E8tement.
>                   Albert Einstein
>
>
>
> -=3D This is automatically added to each message by the mailing script
> =3D-
> To recover the email address of the author of the message, please
> change>
> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
>
>
>



-=3D This is automatically added to each message by the mailing script =3D-

     http://www.ccl.net/cgi-bin/ccl/send_ccl_message

     http://www.ccl.net/cgi-bin/ccl/send_ccl_message







--
Click on the link below to report this email as spam
https://www.mailcontrol.com/sr/Fn6kLNLmVN8eBfTljOp+PEZHUEeihbupL6fNoe1YRahuS7jsR6G+dMtRoHlUzjHw+4NaKEq4vCC4N3AcDbBM5+CCqNntONU5r4U1gUc9fU9n!4OiIDLjbpffOF3Drvvl5jw4ANltGpJxqfx8gsAj02!hAfoKUTbNzd9RBlstxIUnmQhx1IsJ9iX6GcBKtJSaDASE1fBJY82oV2JwgT4t71NOO9GFnNxV

--


Dr. Eric Scerri ,
UCLA,
4077C, Young Hall,
Department of Chemistry & Biochemistry,
607 Charles E. Young Drive East,
Los Angeles,  CA 90095-1569
USA

E-mail :   scerri~!~chem.ucla.edu
tel:  310 206 7443
fax:  310 206 2061
Web Page:    http://www.chem.ucla.edu/dept/Faculty/scerri/index.html
Editor-in-chief of  =46oundations of Chemistry
http://springerlink.metapress.com/app/home/journal.asp?wasp=3D503c4f278d734f3f957c34496b6939dc&referrer=3Dparent&backto=3Dlinkingpublicationresults,1:103024,1

Also see International Society for the Philosophy of Chemistry
http://ispc.sas.upenn.edu/
--============_-1084071427==_ma============-- From owner-chemistry@ccl.net Fri Sep 30 02:15:00 2005 From: "CCL" To: CCL Subject: CCL: NMR chemical shifts - STOs v. GTOs Message-Id: <-29410-050929164802-18869-wbIfHPeLgoddGzQlubMNvQ^^^server.ccl.net> X-Original-From: Marcel Swart Content-Type: multipart/alternative; boundary=Apple-Mail-2--606811143 Date: Thu, 29 Sep 2005 22:04:04 +0200 Mime-Version: 1.0 (Apple Message framework v553) Sent to CCL by: Marcel Swart [m.swart^^^few.vu.nl] --Replace strange characters with the "at" sign to recover email address--. --Apple-Mail-2--606811143 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Dear all, not only the basis set is important, but also the setup of the=20 integration grid when using DFT; of course, it depends on what you are looking at, but=20 when you want to really look at small effects (at the ppb level, i.e.=20 parts-per-billion !!), it helps to be able to crank up the accuracy that well. Not only does ADF use Slaters (with the better performance in general,=20= but probably especially for these properties), it is also straightforward to=20 increase the accuracy of the calculations. For those interested in doing NMR calculations that don't depend=20 anymore on the choice of the integration grid (up to the ppb level), use ADF with the following settings: INTEGRATION accint 7.0 dishul 6.0 END See the following paper for its application: J. Amer. Chem. Soc. 2004, 126, 16718 Of course, the DFT functional has a large impact on the accuracy on the=20= absolute value of the NMR shielding, with SAOP or KT2 performing better than=20 standard GGA's; but both the latter seem to be performing better than=20 non-multiplicative functionals. For those interested in the performance of different DFT functionals,=20 see papers by J. Poater and co-workers, J.Chem.Phys. 118 8584 P. Pulay and co-workers, J.Chem.Phys. 119 1350 D. Tozer and co-workers, J.Chem.Phys. 119 3015 and related papers. On Thursday, September 29, 2005, at 07:58 PM, CCL wrote: > Hmm, I never did such a comparison but ADF with TZP basis set and=20 > revPBE DFT functional gave me quite well results for platinum nmr for=20= > series of halogen complexes, at least for Cl and Br. I do not have=20 > experimental data for iodine complexes. Frankly speaking the main=20 > problem is to choose proper model for environment especialy if you=20 > have bare ions in solution. But not only bare ions have problem, I=20 > still cannot get -1630 ppm for PtCl_4^{2-} with respect to=20 > PtCl_6^{2-}... life is cruel. > And you can find planty of such "small" problems in literature. > > If you have time and free resources one can download evaluation=20 > version of adf for free (www.scm.com) and check whether STOs are=20 > better than GTOs. Program is fully functional during one month as I=20 > remember. > > Anyway question was about best method for organic molecules. As I=20 > remember the best chemical shift results were obtained within coupled=20= > cluster scheme, but DFT will be good enough. What kind of functional=20= > you should use - I do not know. You can use plenty of different=20 > programs adf, turbomole, gaussian, nwchem, demon and many others. I=20 > use adf because it's fast, scales allmost lineary up to 64 proc. and=20= > it has allmost everything I need. For b3-lyp calculations I would=20 > suggest turbomole or jaguar if you need fast b3-lyp. =96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96= =96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96 dr. Marcel Swart Theoretische Chemie Vrije Universiteit Amsterdam Faculteit der Exacte Wetenschappen De Boelelaan 1083 1081 HV Amsterdam The Netherlands Tel +31-20-5987619 Fax +31-20-5987629 E-mail m.swart^^^few.vu.nl Web http://www.few.vu.nl/~swart =96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96= =96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96 --Apple-Mail-2--606811143 Content-Transfer-Encoding: quoted-printable Content-Type: text/enriched; charset=WINDOWS-1252 Dear all, not only the basis set is important, but also the setup of the integration grid when using DFT; of course, it depends on what you are looking at, but when you want to really look at small effects (at the ppb level, i.e. parts-per-billion !!), it helps to be able to crank up the accuracy that well. Not only does ADF use Slaters (with the better performance in general, but probably especially for these properties), it is also straightforward to increase the accuracy of the calculations.=20 For those interested in doing NMR calculations that don't depend anymore on the choice of the integration grid (up to the ppb level),=20 use ADF with the following settings: INTEGRATION accint 7.0 dishul 6.0 END See the following paper for its application: J. Amer. Chem. Soc. 2004, 126, 16718 Of course, the DFT functional has a large impact on the accuracy on the absolute value of the NMR shielding, with SAOP or KT2 performing better than standard GGA's; but both the latter seem to be performing better than non-multiplicative functionals. For those interested in the performance of different DFT functionals, see papers by J. Poater and co-workers, J.Chem.Phys. 118 8584 P. Pulay and co-workers, J.Chem.Phys. 119 1350 D. Tozer and co-workers, J.Chem.Phys. 119 3015 and related papers. On Thursday, September 29, 2005, at 07:58 PM, CCL wrote: Hmm, I never did such a comparison but ADF with TZP basis set and revPBE DFT functional gave me quite well results for platinum nmr for series of halogen complexes, at least for Cl and Br. I do not have experimental data for iodine complexes. Frankly speaking the main problem is to choose proper model for environment especialy if you have bare ions in solution. But not only bare ions have problem, I still cannot get -1630 ppm for PtCl_4^{2-} with respect to PtCl_6^{2-}... life is cruel. And you can find planty of such "small" problems in literature. If you have time and free resources one can download evaluation version of adf for free (www.scm.com) and check whether STOs are better than GTOs. Program is fully functional during one month as I remember. Anyway question was about best method for organic molecules. As I remember the best chemical shift results were obtained within coupled cluster scheme, but DFT will be good enough. What kind of functional you should use - I do not know. You can use plenty of different programs adf, turbomole, gaussian, nwchem, demon and many others. I use adf because it's fast, scales allmost lineary up to 64 proc. and it has allmost everything I need. For b3-lyp calculations I would suggest turbomole or jaguar if you need fast b3-lyp. =96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96= =96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96 dr. Marcel Swart Theoretische Chemie Vrije Universiteit Amsterdam Faculteit der Exacte Wetenschappen De Boelelaan 1083 1081 HV Amsterdam The Netherlands Tel +31-20-5987619 Fax +31-20-5987629 E-mail m.swart^^^few.vu.nl Web http://www.few.vu.nl/~swart =96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96= =96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96=96 --Apple-Mail-2--606811143-- From owner-chemistry@ccl.net Fri Sep 30 05:11:00 2005 From: "CCL" To: CCL Subject: CCL: Open source contributions by pharma. Message-Id: <-29411-050930050919-10184-1R4IqcLSQ7t8nU1vHTpwLA[*]server.ccl.net> X-Original-From: Eugen Leitl Content-Disposition: inline Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Sep 2005 11:09:08 +0200 Mime-Version: 1.0 Sent to CCL by: Eugen Leitl [eugen[*]leitl.org] --Replace strange characters with the "at" sign to recover email address--. On Fri, Sep 30, 2005 at 01:04:47AM +0200, CCL wrote: > ChemAxon software are affordable and free for academic users. While I've used ChemAxon personally, and like it, it is not open source -- free as gratis, not libre. -- Eugen* Leitl leitl ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From owner-chemistry@ccl.net Fri Sep 30 05:46:00 2005 From: "CCL" To: CCL Subject: CCL: What Open Source Chemistry Tools do we lack most? (was: Open source contributions by pharma) Message-Id: <-29412-050930054228-28914-uWlhDK/N7XS3Dj6BU+iKgQ- -server.ccl.net> X-Original-From: Egon Willighagen Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Date: Fri, 30 Sep 2005 11:41:57 +0200 MIME-Version: 1.0 Sent to CCL by: Egon Willighagen [e.willighagen- -science.ru.nl] --Replace strange characters with the "at" sign to recover email address--. Hi all, today I was wondering, despite the contributions from pharma :), what the our CCL community is really lacking in terms of open source. In two weeks, the CDK [1] project is having a one week workshop event [2], and interaction with other tools, and its future is on the agenda (among many other interesting things). This would be a good moment to let me know the biggest ommision in open source tools you currently experience. Send me email with your list of missing tools, and I will compose a most-wanted list. The total open source chemistry community is large enough to address the list. Suggestions do not have to be restricted to the CDK, and can be of any field related to the CCL list. It might also have to do with missing interaction options between open source projects... or whatever else you think appropriate. Very much looking forward to your ideas on this! Egon 1. http://cdk.sourceforge.net/ 2. http://almost.cubic.uni-koeln.de/cdk/cdk_top/events/cdk5yearworkshop/ From owner-chemistry@ccl.net Fri Sep 30 06:55:00 2005 From: "CCL" To: CCL Subject: CCL: What Open Source Chemistry Tools do we lack most? Message-Id: <-29413-050930065214-17972-P2PUQP691m8gIjurYaq47g.@.server.ccl.net> X-Original-From: "Noel O'Boyle" Content-Transfer-Encoding: 7bit Content-Type: text/plain Date: Fri, 30 Sep 2005 11:51:59 +0100 Mime-Version: 1.0 Sent to CCL by: "Noel O'Boyle" [noel.oboyle2...@...mail.dcu.ie] --Replace strange characters with the "at" sign to recover email address--. Hello Egon, I recently compiled a list of open-source Python libraries useful in Chemistry for a talk I was giving (available at http://www-mitchell.ch.cam.ac.uk/noel/) Scientific computing: scipy/pylab (like Matlab) Molecular dynamics: MMTK Statistics: scipy, rpy (R), pychem 3D-visualisation: mayavi (VTK) 2D-visualisation: scipy, pylab, rpy coming soon, a wrapper around OpenBabel cheminformatics: frowns, PyDaylight, pychem bioinformatics: BioPython structural biology: PyMOL computational chemistry: GaussSum and...you can still use Java libraries...like the CDK Regards, Noel On Fri, 2005-09-30 at 11:41 +0200, CCL wrote: > Sent to CCL by: Egon Willighagen [e.willighagen- -science.ru.nl] > > --Replace strange characters with the "at" sign to recover email address--. > > > Hi all, > > today I was wondering, despite the contributions from pharma :), what the our > CCL community is really lacking in terms of open source. > > In two weeks, the CDK [1] project is having a one week workshop event [2], and > interaction with other tools, and its future is on the agenda (among many > other interesting things). > > This would be a good moment to let me know the biggest ommision in open source > tools you currently experience. Send me email with your list of missing > tools, and I will compose a most-wanted list. The total open source chemistry > community is large enough to address the list. > > Suggestions do not have to be restricted to the CDK, and can be of any field > related to the CCL list. It might also have to do with missing interaction > options between open source projects... or whatever else you think > appropriate. > > Very much looking forward to your ideas on this! > > Egon > > 1. http://cdk.sourceforge.net/ > 2. http://almost.cubic.uni-koeln.de/cdk/cdk_top/events/cdk5yearworkshop/> > > From owner-chemistry@ccl.net Fri Sep 30 07:30:00 2005 From: "CCL" To: CCL Subject: CCL: W:CCL: Cleaning up dusty deck fortran and converting to C/C++ - Wrap up Message-Id: <-29414-050930064007-15660-RXas2LdUfOhuJ7NBQRbQog:+:server.ccl.net> X-Original-From: "Konrad Hinsen" Sent to CCL by: "Konrad Hinsen" [khinsen:+:cea.fr] --Replace strange characters with the "at" sign to recover email address--. On Sep 29, 2005, at 22:39, Bob Duke wrote: > Thanks to the folks who said they found the comparative coding discussion helpful. > My goals were to highlight the facts that: > 1) f90/95 now supports most, if not all algorithms/data structures anyone would > want to use for numerical s/w development. I have some doubt about "anyone" (myself being an exception), but the more important point is that "numerical" software is not a clear-cut category. Most non-trivial scientific software has numerical and non-numerical aspects. For example, I work on simulation and modelling of biomolecular systems. This certainly involves good old numerical algorithms, and that's where an application tends to spend most of its time. However, the majority of the code deals with the data structures that represent complex molecules. This is a pain to do in Fortran, with the result that those who do such work in Fortran usually cut corners and produce programs that are not a pleasure to use. Apart from such issues that are very domain specific, there are also some general aspects of modern scientific software that are difficult to handle in Fortran: - Graphical user interfaces. Fortran programmers tend to factor them out into separate frontends written in some scripting language. The result is rarely as good as a tightly integrated GUI with real interactivity. If you want your code to be used by experimentalists (among others), GUIs are a huge advantage. - Data I/O. Most of the computing world is moving to XML formats because of the benefits of standardized I/O libraries and transformation software. Scientists are lagging behind, with one reason being the difficulty of handling XML (or any other structured data format) in Fortran. Yes, I know there is an XML parser in Fortran 90, but it's a pain to use compared to parsers for other languages. - File handling. Fortran has its very own way of handling data files. If you have to deal with someone else's file format (and that someone else doesn't use Fortran), you have a problem. Sophisticated I/O libraries (netCDF, HDF, etc.) are written in C for a reason. - System access. Interfacing to the outside world is limited to files in Fortran. If you need access to network features, e.g. for parallelism, you have to resort to some other language again. MPI implementations are written in C for a reason. All these aspects can of course be handled by C libraries interfaced to Fortran, but this is a restrictive approach becuase the interfaces are limited to the Fortran 77 level (i.e. no data structures other than arrays). In most cases, a special interface wrapper needs to be written - in C. Mixing C and Fortran is also made difficult by the fact that many Fortran compilers require the main entry point of the code to be in the Fortran part, and of course by a lack of standardization of cross-linking. This is in fact the single reason why I don't use Fortran at all. If interfacing with C (and by extension with all C-interfaceable languages) were easy and portable, I'd probably use Fortran for numerical subroutines. But since I have to choose between all-Fortran and no-Fortran, I go for no-Fortran. > 2) The support for the humble array is better in f90/95 than in c. That is certainly true. However, libraries can make a C programmer's job with arrays much easier. Personally, I do most of my array stuff in Python, which has a nice array package which also has a nice C interface. Just as a reminder that there are more options than just Fortran, C, and C++. -- --------------------------------------------------------------------- Konrad Hinsen Laboratoire Lon Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: khinsen:+:cea.fr --------------------------------------------------------------------- From owner-chemistry@ccl.net Fri Sep 30 08:04:00 2005 From: "CCL" To: CCL Subject: CCL: W:Identifying bridgehead atoms Message-Id: <-29415-050930074330-6231-Wa8VJlb3i0HUp2eTGhMz5A#%#server.ccl.net> X-Original-From: Tim Aitken Content-Type: multipart/alternative; boundary="=_alternative 003AADD98025708C_=" Date: Fri, 30 Sep 2005 11:40:56 +0100 MIME-Version: 1.0 Sent to CCL by: Tim Aitken [taitken#%#accelrys.com] --Replace strange characters with the "at" sign to recover email address--. This is a multipart message in MIME format. --=_alternative 003AADD98025708C_= Content-Type: text/plain; charset="US-ASCII" Dear Richard, the Accord SDK from Accelrys can be used to identify & step through ring atoms, fused, bridge & spiro rings, and it would only take a few lines of code to fill an array with all atoms in a ring system and count the number of bonds to the nearest atom with >2 ring bonds - identifying the bridgehead. Best, Tim Aitken Accelrys Cheminformatics "CCL" Sent by: owner-chemistry#%#ccl.net 30/09/2005 00:41 Please respond to "CCL Subscribers" To "Aitken, Tim " cc Subject CCL: W:Identifying bridgehead atoms Sent to CCL by: "Richard Hull" [hull%a%axontologic.com] --Replace strange characters with the "at" sign to recover email address--. Are there any published algorithms for identifying bridgehead atoms within polycyclic ring systems, particularly for 2-D connection tables? I am most interested in topological properties of the corresponding chemical graph that can be exploited. Any pointers would be greatly appreciated. Best, Richard Hull hull#%#axontologic.comhttp://www.ccl.net/cgi-bin/ccl/send_ccl_message-- Click on the link below to report this email as spam https://www.mailcontrol.com/sr/9VKiiPZK21nwAs+9rBke+pcPieEFzNqiuIzGgjtzI5MWEBsIXANI7gMOEOaTaSB2SvlHBJ5RQj2p7xXmFTF!uLaYJj1Nju1+cNKEbClnK7jxQ0sSxvzeLHHQ8qwpK3XP1jIipoAzCbZkBsRgg0KG7tC!Abk8gOt!yNkk!LsdJCH3JChyBuy1PYIe1X!2cXgtecYBmP1vWbujVWKZuicG7R3mssVn+j+k --=_alternative 003AADD98025708C_= Content-Type: text/html; charset="US-ASCII"
Dear Richard,

the Accord SDK from Accelrys can be used to identify & step through ring atoms, fused, bridge & spiro rings, and it would only take a few lines of code to fill an array with all atoms in a ring system  and count the number of bonds to the nearest atom with >2 ring bonds - identifying the bridgehead.

Best,

Tim Aitken
Accelrys Cheminformatics



"CCL" <owner-chemistry#%#ccl.net>
Sent by: owner-chemistry#%#ccl.net

30/09/2005 00:41
Please respond to
"CCL Subscribers" <chemistry#%#ccl.net>
To
"Aitken, Tim " <taitken#%#accelrys.com>
cc
Subject
CCL: W:Identifying bridgehead atoms






Sent to CCL by: "Richard  Hull" [hull%a%axontologic.com]

--Replace strange characters with the "at" sign to recover email address--.

Are there any published algorithms for identifying bridgehead atoms within polycyclic ring systems, particularly for 2-D connection tables?  I am most interested in topological properties of the corresponding chemical graph that can be exploited.

Any pointers would be greatly appreciated.

Best,

Richard Hull
hull#%#axontologic.com


     http://www.ccl.net/cgi-bin/ccl/send_ccl_message
     http://www.ccl.net/cgi-bin/ccl/send_ccl_message





--
Click on the link below to report this email as spam
https://www.mailcontrol.com/sr/9VKiiPZK21nwAs+9rBke+pcPieEFzNqiuIzGgjtzI5MWEBsIXANI7gMOEOaTaSB2SvlHBJ5RQj2p7xXmFTF!uLaYJj1Nju1+cNKEbClnK7jxQ0sSxvzeLHHQ8qwpK3XP1jIipoAzCbZkBsRgg0KG7tC!Abk8gOt!yNkk!LsdJCH3JChyBuy1PYIe1X!2cXgtecYBmP1vWbujVWKZuicG7R3mssVn+j+k

--=_alternative 003AADD98025708C_=-- From owner-chemistry@ccl.net Fri Sep 30 08:39:00 2005 From: "CCL" To: CCL Subject: CCL: pl unsubscribe Message-Id: <-29416-050930074627-7232-wRVe8VpVubvLUsgdRUDTVw!^!server.ccl.net> X-Original-From: sangeetha Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Date: Fri, 30 Sep 2005 12:46:21 +0100 (BST) MIME-Version: 1.0 Sent to CCL by: sangeetha [srdshigella2001!^!yahoo.co.in] --Replace strange characters with the "at" sign to recover email address--. --- CCL wrote: > > Sent to CCL by: "Noel O'Boyle" > [noel.oboyle2.!^!.mail.dcu.ie] > > --Replace strange characters with the "at" sign to > recover email address--. > > Hello Egon, > > I recently compiled a list of open-source Python > libraries useful in > Chemistry for a talk I was giving (available at > http://www-mitchell.ch.cam.ac.uk/noel/) > > Scientific computing: scipy/pylab (like Matlab) > Molecular dynamics: MMTK > Statistics: scipy, rpy (R), pychem > 3D-visualisation: mayavi (VTK) > 2D-visualisation: scipy, pylab, rpy > coming soon, a wrapper around OpenBabel > cheminformatics: frowns, PyDaylight, pychem > bioinformatics: BioPython > structural biology: PyMOL > computational chemistry: GaussSum > and...you can still use Java libraries...like the > CDK > > Regards, > Noel > > On Fri, 2005-09-30 at 11:41 +0200, CCL wrote: > > Sent to CCL by: Egon Willighagen [e.willighagen- > -science.ru.nl] > > > > --Replace strange characters with the "at" sign to > recover email address--. > > > > > > Hi all, > > > > today I was wondering, despite the contributions > from pharma :), what the our > > CCL community is really lacking in terms of open > source. > > > > In two weeks, the CDK [1] project is having a one > week workshop event [2], and > > interaction with other tools, and its future is on > the agenda (among many > > other interesting things). > > > > This would be a good moment to let me know the > biggest ommision in open source > > tools you currently experience. Send me email with > your list of missing > > tools, and I will compose a most-wanted list. The > total open source chemistry > > community is large enough to address the list. > > > > Suggestions do not have to be restricted to the > CDK, and can be of any field > > related to the CCL list. It might also have to do > with missing interaction > > options between open source projects... or > whatever else you think > > appropriate. > > > > Very much looking forward to your ideas on this! > > > > Egon > > > > 1. http://cdk.sourceforge.net/ > > 2. > http://almost.cubic.uni-koeln.de/cdk/cdk_top/events/cdk5yearworkshop/> > > > > > > > > > -= This is automatically added to each message by > the mailing script =- > To recover the email address of the author of the > message, please change > the strange characters on the top line to the !^! > sign. You can also> > E-mail to administrators: CHEMISTRY-REQUEST!^!ccl.net > or use> > > > __________________________________________________________ Yahoo! India Matrimony: Find your partner now. Go to http://yahoo.shaadi.com From owner-chemistry@ccl.net Fri Sep 30 09:14:01 2005 From: "CCL" To: CCL Subject: CCL: W:Expt Denisty of supercritical mixture Message-Id: <-29417-050930045825-9729-ntwKXwevNA41u2MfvPtvZA * server.ccl.net> X-Original-From: "Bhabani Mallik" Sent to CCL by: "Bhabani Mallik" [mbhabani * iitk.ac.in] --Replace strange characters with the "at" sign to recover email address--. Dear All, I want to know the experimental density of acetone,methanol in supercritcal water (mixture) at different temperature (particularly at 673K ) with varying mol fraction. Help will be greatly appreciated. regards, Bhabani From owner-chemistry@ccl.net Fri Sep 30 09:50:01 2005 From: "CCL" To: CCL Subject: CCL: W:hardware for computational chemistry calculations Message-Id: <-29418-050929103900-10787-oeEqXTleQjruy5Zunf97dA:_:server.ccl.net> X-Original-From: "Luis Manuel Simon" Sent to CCL by: "Luis Manuel Simon" [luissimonrubio:_:hotmail.com] --Replace strange characters with the "at" sign to recover email address--. Dear all: Probably, there have been many discussions about hardware on this list, but somehow I need some update about few questions: Which is the better performance/price choice for computational chemistry (quantum chemistry and mollecular dynamic simulations)? Is it better a PC-cluster or a workstation? Several PC nodes in a cluster or several processors in a board? AMD 64, OPTERON, intel PIV, Xeon, SPARC? Are dual processors worth? How important is microprocessor cache size? How important is RAM size? And registered DDR modules? Is it RAID worth? Does SCSI hard drive really perform better than SATA? What about operating system, linux distribution, etc? Is there any comparison, next to spec.org, about different configurations? Thanks to all: Luis From owner-chemistry@ccl.net Fri Sep 30 10:25:01 2005 From: "CCL" To: CCL Subject: CCL: Open source contributions by pharma. Message-Id: <-29419-050929104813-12344-RyAHqBdSsQDdm2UzDYx5ew^^server.ccl.net> X-Original-From: Rajarshi Guha Content-Transfer-Encoding: 7bit Content-Type: text/plain Date: Thu, 29 Sep 2005 10:48:03 -0400 Mime-Version: 1.0 Sent to CCL by: Rajarshi Guha [rxg218^^psu.edu] --Replace strange characters with the "at" sign to recover email address--. On Wed, 2005-09-28 at 16:46 -0700, CCL wrote: > Sent to CCL by: "Peter Spiro" [spiro(a)renovis.com] > > On the subject of cheminformatics applications such as descriptor > calculation, conformational search, QSAR, etc, I'd be interested to > know people's recommendations for open source/free/cheap software in > this area. Is there anything that comes close to, say, MOE? For descriptor calculations JOElib is nice - there was a post on this list sometime back summarizing free/opensource descriptor calculation software. For QSAR modeling a good opensource program is R As for combining descriptor calculation & modeling you have commercial software, such as MOE and others. On the free/opensource side, PowerMV (http://www.niss.org/PowerMV/) is one possibility (which actually uses R as the backend). ------------------------------------------------------------------- Rajarshi Guha GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- 667: The neighbor of the beast. From owner-chemistry@ccl.net Fri Sep 30 11:35:00 2005 From: "CCL" To: CCL Subject: CCL: [CCL] Re: CCL: W:Identifying bridgehead atoms Message-Id: <-29420-050930091339-12844-Hgdlu5HBfHy3gjjzmxJz7g|-|server.ccl.net> X-Original-From: Cory Pye Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Fri, 30 Sep 2005 09:25:05 -0300 (ADT) MIME-Version: 1.0 Sent to CCL by: Cory Pye [cpye|-|crux.smu.ca] --Replace strange characters with the "at" sign to recover email address--. On Thu, 29 Sep 2005, CCL wrote: > > Sent to CCL by: "Richard Hull" [hull%a%axontologic.com] > > Are there any published algorithms for identifying bridgehead atoms within polycyclic ring systems, particularly for 2-D connection tables? I am most interested in topological properties of the corresponding chemical graph that can be exploited. > > Any pointers would be greatly appreciated. > Hi, I wrote something that can do this a while ago in a different context. Basically the molecular graph (all connections are like single bonds) is pruned, then homeomorphically reduced as much as it can go. What you have left are the bridgehead atoms. Pye and Poirier, J. Comp. Chem. 19, 504-511 (1998) ************* ! Dr. Cory C. Pye ***************** ! Associate Professor *** ** ** ** ! Theoretical and Computational Chemistry ** * **** ! Department of Chemistry, Saint Mary's University ** * * ! 923 Robie Street, Halifax, NS B3H 3C3 ** * * ! cpye|-|crux.stmarys.ca http://apwww.stmarys.ca/~cpye *** * * ** ! Ph: (902)-420-5654 FAX:(902)-496-8104 ***************** ! ************* ! Les Hartree-Focks (Apologies to Montreal Canadien Fans) From owner-chemistry@ccl.net Fri Sep 30 12:10:00 2005 From: "CCL: $quoted_string_for_from" To: CCL Subject: CCL: W:CCL: Cleaning up dusty deck fortran and converting to C/C++ - Wrap up Message-Id: <-29421-050930092459-6413-JbmysGzLgSMkXNqIi9yUSQ.:.server.ccl.net> X-Original-From: "Robert Duke" Content-Transfer-Encoding: 7bit Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Date: Fri, 30 Sep 2005 09:24:46 -0400 MIME-Version: 1.0 Sent to CCL by: "Robert Duke" [rduke.:.email.unc.edu] --Replace strange characters with the "at" sign to recover email address--. Konrad - I definitely see your point on most of the items below, and have mentioned the system interface problems myself earlier in this thread (and all your comments really boil down to the system interface). I understand that once someone is thoroughly immersed in C/C++, then it offers opportunities that are hard to ignore. I guess the reason, in the first place, that I jumped in on this thread was that it was stated that one cannot do more sophisticated algorithms and data structures in fortran, and I think this is a prejudice that should not be extended past fortran 77 to fortran 90 and its successors. A sincere, if at times clunky, effort has been made to support all the sorts of data structures and algorithms one would want to use in a modern software engineering effort, short of a real object model. The comments on i/o are also interesting; I deal mostly with ascii output myself, and find fortran fine for that; when one has to do binary output I understand the pain, and the unix/c view of a file as a flat string of bytes is after all about as general (and therefore capable of everything) as you could want. Also, I agree that writing a gui in fortran is a bad idea. Fortran can be a backend fired up by a gui, but without system calls for ipc it is a little limited. I guess a good standardized unix system interface for Fortran would be a good thing, but I have no idea how much crossover there is to windows in this community and that is always an issue (but this is an issue even in C; a while back I had a job where I was responsible for creating a C interface layer to either a windows or unix system that was completely transparent to the application developer for the full range of system calls, including threading, net ipc, and file i/o - I did it but the effort was nontrivial, and the company and eventually its parent company died, taking the interface with it). Anyway, I think you brought up some valid points, and that is the sort of thing folks ought to be making their decisions on; not on old prejudices against f77 extended forward to f90 et al. Why not just use C and forget fortran, period? Basically there are 3 issues: 1) the sharp tool issue - you really have to know what you are doing, or you will create a mess for yourself and your successors, 2) the issue of fortran 90+ having better support for writing mathematically oriented code, and 3) the expense of a port from old fortran to c - the benefit should be greater than the cost. Best Regards - Bob ----- Original Message ----- > From: "CCL" To: "Duke, Robert E " Sent: Friday, September 30, 2005 7:48 AM Subject: CCL: W:CCL: Cleaning up dusty deck fortran and converting to C/C++ - Wrap up > > Sent to CCL by: "Konrad Hinsen" [khinsen:+:cea.fr] > > --Replace strange characters with the "at" sign to recover email > address--. > > On Sep 29, 2005, at 22:39, Bob Duke wrote: > >> Thanks to the folks who said they found the comparative coding discussion >> helpful. >> My goals were to highlight the facts that: > >> 1) f90/95 now supports most, if not all algorithms/data structures anyone >> would >> want to use for numerical s/w development. > > I have some doubt about "anyone" (myself being an exception), but the more > important point is that > "numerical" software is not a clear-cut category. Most non-trivial > scientific software has numerical > and non-numerical aspects. For example, I work on simulation and modelling > of biomolecular > systems. This certainly involves good old numerical algorithms, and that's > where an application > tends to spend most of its time. However, the majority of the code deals > with the data structures > that represent complex molecules. This is a pain to do in Fortran, with > the result that those who do > such work in Fortran usually cut corners and produce programs that are not > a pleasure to use. > > Apart from such issues that are very domain specific, there are also some > general aspects of > modern scientific software that are difficult to handle in Fortran: > > - Graphical user interfaces. Fortran programmers tend to factor them out > into separate > frontends written in some scripting language. The result is rarely as > good as a > tightly integrated GUI with real interactivity. If you want your code to > be used by > experimentalists (among others), GUIs are a huge advantage. > > - Data I/O. Most of the computing world is moving to XML formats because > of the > benefits of standardized I/O libraries and transformation software. > Scientists are > lagging behind, with one reason being the difficulty of handling XML (or > any other > structured data format) in Fortran. Yes, I know there is an XML parser in > Fortran 90, > but it's a pain to use compared to parsers for other languages. > > - File handling. Fortran has its very own way of handling data files. If > you have to deal > with someone else's file format (and that someone else doesn't use > Fortran), you > have a problem. Sophisticated I/O libraries (netCDF, HDF, etc.) are > written in C for a > reason. > > - System access. Interfacing to the outside world is limited to files in > Fortran. If you > need access to network features, e.g. for parallelism, you have to resort > to some > other language again. MPI implementations are written in C for a reason. > > All these aspects can of course be handled by C libraries interfaced to > Fortran, but this is a > restrictive approach becuase the interfaces are limited to the Fortran 77 > level (i.e. no data > structures other than arrays). In most cases, a special interface wrapper > needs to be written - in C. > Mixing C and Fortran is also made difficult by the fact that many Fortran > compilers require the main > entry point of the code to be in the Fortran part, and of course by a lack > of standardization of > cross-linking. > > This is in fact the single reason why I don't use Fortran at all. If > interfacing with C (and by extension > with all C-interfaceable languages) were easy and portable, I'd probably > use Fortran for numerical > subroutines. But since I have to choose between all-Fortran and > no-Fortran, I go for no-Fortran. > >> 2) The support for the humble array is better in f90/95 than in c. > > That is certainly true. However, libraries can make a C programmer's job > with arrays much easier. > Personally, I do most of my array stuff in Python, which has a nice array > package which also has a > nice C interface. Just as a reminder that there are more options than just > Fortran, C, and C++. > -- > --------------------------------------------------------------------- > Konrad Hinsen > Laboratoire Lon Brillouin, CEA Saclay, > 91191 Gif-sur-Yvette Cedex, France > Tel.: +33-1 69 08 79 25 > Fax: +33-1 69 08 82 61 > E-Mail: khinsen.:.cea.fr > ---------------------------------------------------------------------> lookup the X-Original-From: line in the mail header.> > Job advertising: http://www.ccl.net/jobs> > > > From owner-chemistry@ccl.net Fri Sep 30 12:45:01 2005 From: "CCL: peter murray-rust pm286-#-cam.ac.uk" To: CCL Subject: CCL: What Open Source Chemistry Tools do we lack most? (was: Open source contributions by pharma) Message-Id: <-29422-050930084949-12040-TXSYZlJSYLupeYYaBa3ucg-#-server.ccl.net> X-Original-From: peter murray-rust Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Fri, 30 Sep 2005 13:49:40 +0100 Mime-Version: 1.0 Sent to CCL by: peter murray-rust [pm286-#-cam.ac.uk] --Replace strange characters with the "at" sign to recover email address--. At 10:41 30/09/2005, CCL wrote: >Sent to CCL by: Egon Willighagen [e.willighagen- -science.ru.nl] > >--Replace strange characters with the "at" sign to recover email address--. > > >Hi all, > >today I was wondering, despite the contributions from pharma :), what the our >CCL community is really lacking in terms of open source. > >In two weeks, the CDK [1] project is having a one week workshop >event [2], and >interaction with other tools, and its future is on the agenda (among many >other interesting things). > >This would be a good moment to let me know the biggest ommision in >open source >tools you currently experience. Send me email with your list of missing >tools, and I will compose a most-wanted list. The total open source chemistry >community is large enough to address the list. > >Suggestions do not have to be restricted to the CDK, and can be of any field >related to the CCL list. It might also have to do with missing interaction >options between open source projects... or whatever else you think >appropriate. These are my Wibnis which I use in my talks. Leading WIBNIs* for Open Chemistry * Communal dictionaries/ontologies * Molecular descriptor and fragment ontology * 3-D builder and fragments * name2structure lookup and parsing * XMLisation of Open computational codes * Authoring tools * Open chemical database technology * Agreed webservice providers Wouldn't it be nice if... We are making good progress on some of these and have fragments which we can contribute to others... P. Peter Murray-Rust Unilever Centre for Molecular Sciences Informatics University of Cambridge, Lensfield Road, Cambridge CB2 1EW, UK +44-1223-763069 From owner-chemistry@ccl.net Fri Sep 30 13:20:00 2005 From: "CCL: angelo danilo favia angel.favia^tiscali.it" To: CCL Subject: CCL: W:plop error Message-Id: <-29423-050930100714-15496-WtAr+G9LXh6w6RGDtISNSg^server.ccl.net> X-Original-From: "angelo danilo favia" Sent to CCL by: "angelo danilo favia" [angel.favia^tiscali.it] --Replace strange characters with the "at" sign to recover email address--. hi list, I'm using PLOP, in order to minimize the structure of a protein with a cofactor bound. unfortunately the calculation stops after few seconds, and the only message I get is: ERROR: in srpfn, -nan -nan The problem should be related with the cofactor (NADPH), cause PLOP works fine not taking it into account. any clue? thanks angelo angel.favia^tiscali.it From owner-chemistry@ccl.net Fri Sep 30 13:55:00 2005 From: "CCL: Angelo Danilo Favia anegl.favia_._tiscali.it" To: CCL Subject: CCL: W:error in plop Message-Id: <-29424-050930100520-15195-ohWL70m/3Suc6btpUelkKg_._server.ccl.net> X-Original-From: "Angelo Danilo Favia" Sent to CCL by: "Angelo Danilo Favia" [anegl.favia_._tiscali.it] --Replace strange characters with the "at" sign to recover email address--. hi list, I'm using PLOP, in order to minimize the structure of a protein with a cofactor bound. unfortunately the calculation stops after few seconds, and the only message I get is: ERROR: in srpfn, -nan -nan The problem should be related with the cofactor (NADPH), cause PLOP works fine not taking it into account. any clue? thanks angelo angel.favia_._tiscali.it From owner-chemistry@ccl.net Fri Sep 30 14:30:01 2005 From: "CCL: Perry E. Metzger perry]=[piermont.com" To: CCL Subject: CCL: Cleaning up dusty deck fortran and converting to C/C++ - Wrap up Message-Id: <-29425-050930101855-25440-sE6WzyCvqjwHI3qz0yvukw]=[server.ccl.net> X-Original-From: "Perry E. Metzger" Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Sep 2005 10:18:47 -0400 MIME-Version: 1.0 Sent to CCL by: "Perry E. Metzger" [perry]=[piermont.com] --Replace strange characters with the "at" sign to recover email address--. "Konrad Hinsen" writes: > Personally, I do most of my array stuff in Python, which has a nice > array package which also has a nice C interface. Just as a reminder > that there are more options than just Fortran, C, and C++. That's very important to remember. Lots of people kept forcing me to defend C, but I'm not even that big a fan of C. Python is an enormously powerful and fun language to work in, as is the less well known but also powerful and fun Ruby. Neither is fast -- both are interpreted environments -- but often it is more important to be able to write the code fast than for it to run fast. You can always write C routines for core math and link them in to your Python code, too. Java and C# are also possibilities -- they're VM based so again they're not as fast as they could be, though with run time optimization Java has gotten quite acceptably quick for lots of stuff. I'm also a big fan of Lisp, as I've said. In fact, it is by far my favorite language, but many people are disturbed by how alien it is so they never try it. It is amazing the sort of power you get by using Lisp though. Some friends of mine are now giant fans of Haskell. Haskell is a strongly typed functional language in the ML family (i.e. it does type inference so you don't need to, and thus automatically gives you polymorphically typed generic functions) but it also has the feature that it is *purely* functional (all state is accumulated indirectly via monads) and it is "lazy" -- i.e. all evaluation is put off until needed, so you can easily speak of things like infinite arrays and other non-strict constructs. I haven't played much with Haskell but the fans seem pretty happy with it. Lastly, may I make a pitch for meta-programming? I know one researcher who needed to highly optimize a computation, but the optimal set of routines to do the computation were a family of very long and rather complicated operations that would be extremely tedious to code by hand. Rather than writing the code by hand, he wrote a short Lisp program that automatically generated the families of optimal functions in C, which he then compiled and ran. (Such things are natural to Lisp programmers because Lisp programs routinely contain code generating code, though usually the target code is Lisp, not another language.) Writing programs that build programs is something I don't see done a lot in the CChem world even though it is frequently the case that computational chemists have to deal with things for which program building programs are the right tool. For example, it is often unnecessary to write your own parsers for complicated data formats in a world where lexical analyzer and parser generators are common. In general the thing to keep in mind is that computers are there to do work *for you*. If you notice that you're doing something by hand that involves mechanical effort rather than thinking, a program should be doing the work, not you. I'll often write a program even if it takes slightly longer than doing something by hand, both because I then have a tool I can reuse (saving future labor) and because a computer program makes fewer errors than a human, and the errors it does make are always systematic and can be removed once and for all by debugging. Perry From owner-chemistry@ccl.net Fri Sep 30 15:04:00 2005 From: "CCL: Sandro Cosconati sa.cosco _ virgilio.it" To: CCL Subject: CCL: W:LIE free software Message-Id: <-29426-050930111049-9369-QifFECbARPJ6iHCzbGr76Q _ server.ccl.net> X-Original-From: "Sandro Cosconati" Sent to CCL by: "Sandro Cosconati" [sa.cosco _ virgilio.it] --Replace strange characters with the "at" sign to recover email address--. Dear All, I was wondering if someone of you could give me some infos about any software ( better if free of charge)that implements the LIE (Linear Interaction Energy) method in order to predict the free energy of binding of some given complexes. Thanks in advance Best regards Sandro From owner-chemistry@ccl.net Fri Sep 30 15:40:00 2005 From: "CCL: Perry E. Metzger perry:piermont.com" To: CCL Subject: CCL: W:hardware for computational chemistry calculations Message-Id: <-29427-050930114958-18622-QlbAE0VdIWvL1uzbkJXZog:server.ccl.net> X-Original-From: "Perry E. Metzger" Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Sep 2005 11:49:50 -0400 MIME-Version: 1.0 Sent to CCL by: "Perry E. Metzger" [perry:piermont.com] --Replace strange characters with the "at" sign to recover email address--. "Luis Manuel Simon" writes: > Probably, there have been many discussions about hardware on this > list, but somehow I need some update about few questions: > > Which is the better performance/price choice for computational > chemistry (quantum chemistry and mollecular dynamic simulations)? > Is it better a PC-cluster or a workstation? Several PC nodes in a > cluster or several processors in a board? > AMD 64, OPTERON, intel PIV, Xeon, SPARC? Are dual processors worth? > How important is microprocessor cache size? > How important is RAM size? And registered DDR modules? > Is it RAID worth? Does SCSI hard drive really perform better than SATA? > What about operating system, linux distribution, etc? > Is there any comparison, next to spec.org, about different configurations? > From what I can tell, at the moment (and this could change at any time), the price/performance of AMD 64 equipment ("Opteron" is just a model of AMD 64) is by far the best. I know people who do a lot of number crunching who are buying AMD 64 whiteboxes by the fleet, and putting them in clusters. As to the rest, the Sparc is very very far behind on the price/performance curve at this point. I wouldn't even vaguely consider it. Cache size is of course quite important on modern machines, because main memory continues to lag far behind the speed of the cache. Taking a cache miss means your processor sits around twiddling its thumbs for a very long time, so you want as few cache misses as possible. That said, the precise size of cache that is important to you is totally dependent on the specific problem you are working on. Some problems fit in fairly small caches, some need very large caches. "It depends." Of course, since you can't buy cache separately from the processor in a modern machine, generally speaking this isn't something to do separately from the processor decision -- if you've benchmarked a particular processor and it works best, you know the cache it has is the best for your problem. RAM size is also an issue. On a modern machine, you want to avoid ever getting page faults because paging something in is Very Very Very Slow. That means you want enough RAM that your entire working set fits in memory nicely. RAM is also used these days as buffer cache for file data, so the more RAM you have, the faster file i/o ends up being if you're doing lots of it. So, again, how much is enough depends a lot on your problem. Different sized problems will eat different amounts of RAM successfully. Luckily, these days RAM is dirt cheap. The biggest issue you will have is in dealing with problems that need very large memory spaces -- if you need an address space for your problem with more than a gig or two of memory, you need a 64 bit processor. (Technically, a 32 bit processor can handle 4G of address space, but remember that in most OSes, a big chunk (sometimes half) of the address space (not memory, address space!) is used by the OS, and mappings for the stack, shared libraries, etc., will make it impossible to truly use all the rest.) The 32 bit x86 processors can use more than 4G of RAM, but they can't devote it all to the address space of one process -- it is only really useful if you have multiple processes that can make use of it -- so again, if you have a problem that needs a big address space, you want AMD 64 or the Intel stuff with the same 64 bit extensions (but those processors aren't as fast.) On the question of clusters versus MP in a single machine, again, "that depends". Multiple processors or machines in general will only help you if your problem is easily parallelized. If it is easily parallelized but requires extremely tight coupling (i.e. you've got some small places where you could vectorize but you'll lose if you have to take a communications hit), even more than one processor won't help. If you have somewhat looser communications constraints but need shared RAM in order to operate effectively, you have no choice but to use an MP machine. Here again, though, keep in mind that you have strong limits to where you will get that way -- price/performance of MP machines goes down sharply with the number of processors, and affordable MP machines rarely have more than 4. Even in clusters, though, sometimes dual processor machines make sense if you save enough on things like power supplies, cases, etc. that you've saved money over all. If your problem is embarrassingly parallel and you can put it over a cluster, by all means, use a cluster. Especially with gig E networking cards as cheap as they are now, you'll win big. On disk performance and controllers: in computational problems, it is very rare that you are actually remotely I/O bound. Most computational chemistry isn't moving 200G of data set in and out of RAM as fast as possible, it is loading a problem into memory and the problem then stays in memory. If your problem is a factor of 2 too big for memory, don't get a faster disk controller, get more RAM -- it will make far more of a difference. In other applications -- if you were building a database server, say, or you have a rare chem problem that actually is disk bound -- I'd give a different answer. In general, though, these days I go with SATA when I can -- the price/performance of SCSI doesn't justify it any more except at the very high end of I/O needs. RAID is nice on a server because it can save you when you have trouble and such, but really, RAID or SCSI on machines in your compute cluster would be silly, since they're not going to do much disk i/o if you can help it! If your cluster machine isn't doing much disk i/o, just use the SATA or IDE controller on the mother board and be done with it. On RAM, for large memories, you really *need* ECC. The odds are just too high that you'll get a single bit error somewhere and ruin days of number crunching with it. Skimping on fancy cases for your computers is one thing, skimping on ECC is another. Incidently, not all chip sets actually pay attention to ECC! Make sure your motherboards do, or you'll be spending extra money for nothing. By the same token, incidently, do not get crappy power supplies -- they are by far and away (in my experience) the biggest source of "mysterious trouble" in modern machines. A nice ANTEC or other quality supply properly rated for the power consumption of your cluster member will make it a whole lot happier long run, which means less trouble for you. Similarly, clean AC power going in, and a nice clean machine room (google for "zinc whiskers" some time) will make you far happier. As for operating systems, that's a matter of taste. So long as you aren't Windows, you'll be fine. And yes, I'm quite serious about "not Windows". You would imagine that since we're talking about something compute bound that barely cares about the kernel, all OSes would be the same, but you would be wrong. There are multiple reasons to stay away from Windows for compute clusters. First, there are dumb architectural mistakes in Windows that make it do too much I/O -- it pages too often, and doesn't use RAM as buffer cache efficiently. Linux and BSD also need tuning to minimize paging, but you at least *can* effectively do the tuning. On Windows, you'll be fiddling with the registry forever, trying to figure out why it is that you can't get the buffer cache large enough and can't keep your executable pages in RAM long enough even though there are gigs of free memory, and then you'll spend six hours on the phone with Redmond, and then you'll give up. Give up in advance -- you will be happier. Also, network I/O performance just can't be tuned up as far as you want on Windows. Lastly, and almost most significantly, you can set up Linux or NetBSD or FreeBSD so that you just shove another box into the rack, let it PXE boot, and walk away from it, never having to think about it again until the day your management script says you need to replace it because it died. You just can't do that with Windows -- it is simply not architected right to allow you to mass manage that way. I've set up systems for mass managing hundreds of machines in Unix clusters without human intervention, and I know of no one who has ever come close on that level of automation with Windows. Keep away. Even if you're managing one box, it is still too much of a pain. By the way, all this is even ignoring the needless expense of Windows licenses that could be better spent on faster processors or more RAM. I know hedge funds where money is no object and still none of them run Windows on compute clusters. Things are a bit different if you're just buying a personal workstation. In that case, I'd buy a Mac. :) All that said, if you are building a compute cluster, if you use a fairly late model Linux, NetBSD, FreeBSD, etc., you can make it work well. I'm a NetBSD bigot myself, but that is not for reasons that would impact computational clusters substantially. You can do fine with any of them if you're doing what is largely number crunching. The one to pick is the one that you or your admin staff feel most comfortable about managing -- and most importantly, automating the management so you don't ever have to log on to 10 or 50 or even 5 boxes to fix something. A strong recommendation though that I'll bring up here because it is vaguely OS related -- do NOT use more threads than processors in your app if you know what is good for you. Thread context switching is NOT instant, and you do not want to burn up good computation cycles on useless thread switching. If you have one processor machines in your cluster, stick to one computing process/thread on it. If you have dual processor boxes, one process with two threads or two processes with one thread make fine sense, but 40 would not be a good use of your cycles. If you need to talk to 60 TCP sockets to share data between boxes, use event driven code, not 60 threads, if you want performance. A final recommendation about buying stuff. If you are buying one workstation for yourself, buy a Mac. If you are buying just a couple of compute servers to run an open source Unix, buy Dell -- for whatever reason, their prices are now totally insanely below what I can manage anywhere else in low quantities -- but be careful about which of the "small business" and "academic" discounts are lower at the moment. Often the academic price is insanely high for no obvious reason. If you are buying 50 and especially 500 machines, either spec and buy parts and assemble the things, or spec the parts and work with a reputable white box manufacturer to get them built for you. For large clusters, you want to get *exactly* what you want. You especially don't want to find out months down the line that half the machines are subtly different from the other half. Also, for large clusters, the maint. contracts you can get with things like Dells are useless expenses -- just buy spare machines and spare parts, they're cheaper -- and keep in mind that these days, the biggest single limiting factor you'll get in the average machine room for a large cluster is getting enough power in and enough heat out. For truly huge clusters, you can start doing truly odd things to get better price/performance. Google does a couple of rather radical things -- for example they don't put their machines in real cases (it would cost more money and would lower the rate at which their racks can extract heat from the systems, not to mention that it slows down getting at the machines). You don't have to go that far, but even in smaller clusters thinking about mechanics can help. Nylon thumb screws instead of metal screws make getting stuff in and out faster. Velcro wraps instead of nylon tie wraps can make it far easier to pull things in and out. Properly planning your cabling (and labeling it!) so you can be sure that the connectors on the ethernet switch systematically correspond to the machines in the rack yields surprising benefits. Oh, and always remember, automate everything in the systems administration you can possibly automate. Perry From owner-chemistry@ccl.net Fri Sep 30 16:15:00 2005 From: "CCL: peter.gray*|*utt.edu.tt" To: CCL Subject: CCL: FW: QCPE Programs Message-Id: <-29428-050930110059-8667-PAiFTbQbxE7pgptpzKsUmw*|*server.ccl.net> X-Original-From: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 30 Sep 2005 09:52:07 -0400 MIME-Version: 1.0 Sent to CCL by: [peter.gray*|*utt.edu.tt] --Replace strange characters with the "at" sign to recover email address--. Friday, September 30, 2005 DEAR QCPE LIST MEMBERS: At the University of Trinidad and Tobago (UTT), w are trying to develop our software capablities in all areas of science, particlarly relating to the energy sector (primarily petroleum and process/utility engineering). We soon hope to engage in research pertaining to the organic chemistry of petroleum-based structures, using quantitative structure-activity (QSAR) correlations to optimise synthetic strategies, and also to prepare students for studies involving chemisorption of organics onto the interior surfaces of porous rock matrices. To this end, I am writing to request your input in terms of the most appropriate modules that would best serve our needs. Having checked the QCPE catalog listing and found that many of the the programs were not currently available, I think I can guess (from memory) that the basic packages should include: i)a molecular mechanics routine for simple input and display (?) of organic structures(MM2, MM3); ii) a program such as ICON8 or FORTICON for performing Huckel calculations on structures involving heavy atoms (e.g., Ni or V chelated in an asphaltene macomolecule); and perhaps iii) a crystallographic surface modeler to display lattice faces, etc. [this latter functionality also to be applied in materials research pertaining to solar-photovoltaic R&D]. We are also prepared tp purchase commercial packages if thre are any reasonable ones out there, so any feedback you could provide would be greatly appreciated, particularly regarding cost and/or licencing requirements. Thank you very much. Sincerely, Peter Gray Assistant Professor, Energy Programmes Univ. of Trinidad & Tobago (UTT) Esperanza Road, Brechin Castle Couva, Trinidad. (868) 636-4125, ext. 3008, or (868) 740-7568( cell.) From owner-chemistry@ccl.net Fri Sep 30 16:50:01 2005 From: "Curt M. Breneman brenec]_[rpi.edu" To: CCL Subject: CCL: [CCL] Re: CCL: W:Identifying bridgehead atoms Message-Id: <-29429-050930134321-25280-+DaUbu0hRhIbMC+bKOHl2g]_[server.ccl.net> X-Original-From: "Curt M. Breneman" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Date: Fri, 30 Sep 2005 12:28:59 -0400 MIME-Version: 1.0 Sent to CCL by: "Curt M. Breneman" [brenec]_[rpi.edu] --Replace strange characters with the "at" sign to recover email address--. Dear Sukumar, Any suggestions? Curt B> -----Original Message----- > From: owner-chemistry]_[ccl.net [mailto:owner-chemistry]_[ccl.net] Sent: Friday, September 30, 2005 8:25 AM To: Breneman, Curt Subject: CCL: [CCL] Re: CCL: W:Identifying bridgehead atoms Sent to CCL by: Cory Pye [cpye|-|crux.smu.ca] --Replace strange characters with the "at" sign to recover email address--. On Thu, 29 Sep 2005, CCL wrote: > > Sent to CCL by: "Richard Hull" [hull%a%axontologic.com] > > Are there any published algorithms for identifying bridgehead atoms within polycyclic ring systems, particularly for 2-D connection tables? I am most interested in topological properties of the corresponding chemical graph that can be exploited. > > Any pointers would be greatly appreciated. > Hi, I wrote something that can do this a while ago in a different context. Basically the molecular graph (all connections are like single bonds) is pruned, then homeomorphically reduced as much as it can go. What you have left are the bridgehead atoms. Pye and Poirier, J. Comp. Chem. 19, 504-511 (1998) ************* ! Dr. Cory C. Pye ***************** ! Associate Professor *** ** ** ** ! Theoretical and Computational Chemistry ** * **** ! Department of Chemistry, Saint Mary's University ** * * ! 923 Robie Street, Halifax, NS B3H 3C3 ** * * ! cpye]_[crux.stmarys.ca http://apwww.stmarys.ca/~cpye *** * * ** ! Ph: (902)-420-5654 FAX:(902)-496-8104 ***************** ! ************* ! Les Hartree-Focks (Apologies to Montreal Canadien Fans)http://www.ccl.net/cgi-bin/ccl/send_ccl_messagehttp://www.ccl.net/chemistry/sub_unsub.shtmlhttp://www.ccl.net/spammers.txt From owner-chemistry@ccl.net Fri Sep 30 17:25:00 2005 From: "Sebastian Antonio ANDUJAR saanduja(~)unsl.edu.ar" To: CCL Subject: CCL: W:Gaussian calculation Message-Id: <-29430-050930143434-15878-UEaGaJYmKI9SXV2nEY47Bg(~)server.ccl.net> X-Original-From: "Sebastian Antonio ANDUJAR" Sent to CCL by: "Sebastian Antonio ANDUJAR" [saanduja(~)unsl.edu.ar] --Replace strange characters with the "at" sign to recover email address--. I am calculating a big system (number of atoms: 250)with the following keywords ---------------------------------------------------------- opt=(z-matrix,maxcycle=900) rhf/3-21g scf=(maxcycle=900) ---------------------------------------------------------- After to read the initial parameters the program shows the following message: Trust Radius=3.00D-01 FncErr=1.00D-07 GrdErr=1.00D-07 Number of steps in this run= 100 maximum allowed number of steps= 100. The end of the output is the following: Error termination via Lnk1e in /extra/g98/l303.exe. Job cpu time: 0 days 0 hours 1 minutes 31.0 seconds. File lengths (MBytes): RWF= 96 Int= 0 D2E= 0 Chk= 1 Scr= 1 Please, could you help me to find the mistake? Sebastian Antonio ANDUJAR/saanduja(~)unsl.edu.ar 917 Chacabuco, 5700 San Luis, ARGENTINA From owner-chemistry@ccl.net Fri Sep 30 17:59:00 2005 From: "Dr. Alexander Hofmann ah(!)chemie.hu-berlin.de" To: CCL Subject: CCL: Conference announcement ICTAC-11 Message-Id: <-29431-050930143824-17821-gynGQ2pnIlbCNIfo+Slqlw^server.ccl.net> X-Original-From: "Dr. Alexander Hofmann" Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Date: Fri, 30 Sep 2005 16:49:12 +0200 Mime-Version: 1.0 Sent to CCL by: "Dr. Alexander Hofmann" [ah(-)chemie.hu-berlin.de] Dear Colleague, We are pleased to announce the 11th International Conference on Theoretical Aspects of Catalysis (ICTAC-11) to be held at the Teikyo University, German campus, in Schmöckwitz near Berlin (Germany) on June 11-14, 2006. The ICTAC-11 meeting will be organized jointly by Klaus Hermann (Theory Department, Fritz-Haber Institute, Berlin) and Joachim Sauer (Quantum Chemistry Group, Humboldt University, Berlin). It continues a worldwide series of meetings which are held biennially and address recent theoretical developments and applications of theoretical methods to problems of catalytic relevance with special focus on heterogeneous catalysis. While the subject attracts mostly researchers with theoretical background emphasis is also put on the interaction between theory and experiment. Therefore, a few invited lectures given by selected high-caliber experimentalists are always included in the program. The present list of keynote speakers includes - A. Bell, University of California, Berkeley (USA) - G. Ertl, Fritz-Haber Institute, Berlin (Germany) - G. Kresse, University of Vienna, Wien (Austria) - U. Landman, Georgia Tech, Atlanta (USA) - M. Mavrikakis, University of Wisconsin, Madison (USA) - Y. Morikawa, Osaka University, Osaka (Japan) - J. Norskov, CAMP Technical University of Denmark, Lyngby (Denmark) - P. Saalfrank, University of Potsdam, Potsdam (Germany) - M. Scheffler, Fritz-Haber Institute, Berlin (Germany) - R. Schlögl, Fritz-Haber Institute, Berlin (Germany) - B. Smit, University of Amsterdam, Amsterdam (The Netherlands) - W. Thiel, MPI for Carbon Research, Muehlheim (Germany) - P. Ugliengo, University of Torino, Torino (Italy) - E. Wang, Chinese Academy of Sciences, Beijing (China) - T. Ziegler, University of Calgary, Calgary (Canada) There will also be about 12 invited talks of younger outstanding scientists (to be announced). The meeting can accommodate up to 100 participants who are welcome to submit abstracts for poster or oral presentations (20 mins). The number of oral presentations is limited and decisions of acceptance will be made based on quality and suitability. For further details and pre-registration please consult the web at http://www.fhi-berlin.mpg.de/ICTAC-11/ For the organizing committee, Klaus Hermann Joachim Sauer ========================================================================= The ICTAC-11 Organizing Committee: Prof. Dr. K. Hermann | Prof. Dr. J. Sauer Abt. Theorie | Institut fuer Chemie Fritz-Haber-Institut | Humboldt-Universitaet Faradayweg 4-6 | Unter den Linden 6 D-14195 Berlin (Germany) | D-10099 Berlin (Germany) e-mail: hermann_._FHI-Berlin.MPG.DE | e-mail: ICTAC-11_._chemie.hu-berlin.de WWW: http://www.fhi-berlin.mpg.de/ICTAC-11/ ========================================================================= From owner-chemistry@ccl.net Fri Sep 30 18:34:01 2005 From: "janl#%#speakeasy.net" To: CCL Subject: CCL: Current chenges to CCL distribution mode Message-Id: <-29432-050930144119-22277-uPfkYwnZYADwLhRPmDzXkw]![server.ccl.net> X-Original-From: janl-$-speakeasy.net Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 30 Sep 2005 18:41:18 +0000 MIME-Version: 1.0 Sent to CCL by: janl() speakeasy.net Dear CCL Subscribers... Some changes in CCL distribution that you may have noticed and may praise or curse... 1) The From: line should now contain the name (if available on the original From: line) and obfuscated email address of the message author in quotes. The actual From: address is still and this is where the bounces go, but the from line reads as: From: "Info about the author" If you click on REPLY you should be given the "CCL Subscribers" on the To: line that is set in the Reply-To: header line of each CCL messaage. If you get the owner-chemistry%ccl.net on the To: line when replying, check your mail program setting. Note... When you want to reply to (or Cc:) the author directly. you can copy the stuff from the message From: line to the To: line (or to the Cc: line) of your reply and edit it to make it a valid address. The correct To: (or Cc:) (or any address line for that matter) line should have one or more entries like these below separated by commas: "Name and Info" user%some.machine Name and Info (if Name and Info are only letters, digits and spaces) There are other formats, by those are most widely used. Note, email addresses are case insensitive (at least should be). 2) As I told you in the previous message, I changed the scripts that distribute your mail to subscribers to queue the messages so the next message is distributed not earlier than after DELAY minutes after the previous message. The DELAY is now 35 minutes. If many messages are queued for distribution to CCL subscribers, the wait may be quite substantial. The status of the queue is always displayed on the top of CCL Home Page: http://www.ccl.net as something like: Messages waiting in a queue: 5 (approx. wait time: 02:55 hours) So, try to post, when the wait time is small. Why I did it? a) To avoid too many messages appearing on CCL at a given day (yes, I am getting mail from subscribers who complain about load). b) To avoid flame wars and malicious Denial of Service attacks. c) To give a break to CCL server machine. Even if I submit messages for distribution with a sendmail -odq switch, the machine load becomes unacceptable with several messages being distributed at the same time. Once CCL collects enough support I will try to buy hardware and faster Internet connection. Now it is a cheap 2 GHz AMD put together from parts and 768kb up. (Yes, I am cooking the "Support CCL Pages"). Thank you for your attention. Now shoot at: Jan Labanowski CCL Manager Email: jkl%ccl.net (I will not shoot back {;-)} since I do not have a gun...) From owner-chemistry@ccl.net Fri Sep 30 19:09:00 2005 From: "Li qiang cougarhead_2003,yahoo.com" To: CCL Subject: CCL: In gaussian, how to output second derivative (Hessian) matrix in cartesian coordinate? Message-Id: <-29433-050930142758-11367-V2WeDp11svQWSImyjMy7BQ-*-server.ccl.net> X-Original-From: Li qiang Content-Transfer-Encoding: 8bit Content-Type: multipart/alternative; boundary="0-259331066-1128104874=:39953" Date: Fri, 30 Sep 2005 11:27:54 -0700 (PDT) MIME-Version: 1.0 Sent to CCL by: Li qiang [cougarhead_2003__yahoo.com] --0-259331066-1128104874=:39953 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear CLLers, I want to output second derivative matrix(hessian matrix) of energy in cartesian coordinate in gaussian03, how to do it? I found at the end of freq job, g03 will output one matrix, but in interan coordinate. But now I want that in a different coordinate. Thank you for any suggestion in advance! --------------------------------- Yahoo! for Good Click here to donate to the Hurricane Katrina relief effort. --0-259331066-1128104874=:39953 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Dear CLLers,
 
I want to output second derivative matrix(hessian matrix) of energy in cartesian coordinate in gaussian03, how to do it?
I found at the end of freq job, g03 will output one matrix, but in interan coordinate. But now I want that in a different coordinate.
Thank you for any suggestion in advance!

Yahoo! for Good
Click here to donate to the Hurricane Katrina relief effort. --0-259331066-1128104874=:39953-- From owner-chemistry@ccl.net Fri Sep 30 19:45:00 2005 From: "David Santos Carballal spectrum_dav*_*operamail.com" To: CCL Subject: CCL: Periodic boundary conditions Message-Id: <-29434-050930144947-30380-rXia8BH+rVdq9qlwJXAGtQ~~server.ccl.net> X-Original-From: "David Santos Carballal" Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 30 Sep 2005 18:58:57 +0100 MIME-Version: 1.0 Sent to CCL by: "David Santos Carballal" [spectrum_dav[*]operamail.com] Dear CCl members: I am doing some molecular dynamics in TINKER. I made a box of solvent (water) with the program xyzedit. In the keyword file evoke keywords: rattle (the responsible of shake method in order to restrain O-H distances and angles in water); a-axis (to define lattice lenght); octahedron (to simulate a sistem closer to a sphere) and cutoff (to evaluate the integrals in a region smaller than the half of dimension of the box of solvent). My system have 100 water molecules. First of all I made a minimization with a conjugate gradient of 0.01. After it I run dynamic with the Beeman integration method and constant temperature (298K) and pressure (1 atm.). When the dynamic begins temperature stabilizes so fast but pressure is very high, it wuold be around 4000 atm. The pressure fall down at 1 atm. after 12000 steps, but the lattice length grow up so much, the initial lattice length was 14 angstroms and the final is 200 angstroms, with one consecuence: density fall down until 0.0010 grams/cc, that is desagree with water density. I use MM3 force field. My question is I am using correctly periodic boundary conditions? Why this results? Do correspond lattice lenght printed on screen with the computational box or with the box of solvent? By the way, when the system is viewed, water molecules are together in a corner of the octahedron. -- _______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze From owner-chemistry@ccl.net Fri Sep 30 20:20:00 2005 From: "Drew McCormack da.mccormack ~ few.vu.nl" To: CCL Subject: CCL: Cleaning up dusty deck fortran and converting to C/C++ - Wrap up Message-Id: <-29435-050930160353-3195-A9zaZy92RNGKpFWB+QSmbQ.@.server.ccl.net> X-Original-From: Drew McCormack Content-Type: multipart/alternative; boundary=Apple-Mail-1--520490627 Date: Fri, 30 Sep 2005 22:02:44 +0200 Mime-Version: 1.0 (Apple Message framework v734) Sent to CCL by: Drew McCormack [da.mccormack#few.vu.nl] --Apple-Mail-1--520490627 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Bob, > 2) The "array of pointers" implementation of multidimensional > arrays in c is generally not a good approach for numerical s/w for > a variety of reasons, mostly performance but also in regard to > interfacing with numerical analysis libraries that expect real arrays. I am also not a big fan of the approach, but it does seem to be what was taught to generations of programmers, particularly before C99. I can see the problems with performance you refer to, but is there really a problem with libraries? The data itself is stored in a contiguous buffer, and so can just be passed to most libraries (eg BLAS, LAPACK, FFTW etc). (Of course, the library will not use the array of pointers, but so long the ordering is consistent, it shouldn't matter.) > > F90/95 compilers often ship with proprietary build tools that can > handle issues of module dependencies and manage the compilation/ > linking process. That's great, unless you happen to work with just > about every machine and operating system that runs unix (that would > be me). In that case, you want to be able to use something nice > and generic like make that you will find on every system. I indeed > do use make and makefiles, but I include a homebrew perl script > that can be used to sort out the dependencies found in #include > preprocessor statements, in fortran include statements, and in > f90/95 "use" statements. This works reasonably well, but I did not > come upon the solution overnight. I may be able to share the > script with anyone interested, but will have to check. > I have been reasonably impressed by an up-and-coming build system called Scons (http://www.scons.org/). It is a python package, so very portable. The equivalent of a makefile in Scons is actually a special python script, which can be very powerful, because you can do anything you can do in python. It knows Fortran 90 dependencies (as well as C, C++, Java etc). Drew --Apple-Mail-1--520490627 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Hi = Bob,


I am also not a big = fan of the approach, but it does seem to be what was taught to = generations of programmers, particularly before C99.=A0
I can = see the problems with performance you refer to, but is there really a = problem with libraries? The data itself is stored in a contiguous = buffer, and so can just be passed to most libraries (eg BLAS, LAPACK, = FFTW etc). (Of course, the library will not use the array of pointers, = but so long the ordering is consistent, it shouldn't = matter.)

=A0
http://www.scons.org/). It is a python = package, so very portable. The equivalent of a makefile in Scons is = actually a special python script, which can be very powerful, because = you can do anything you can do in python. It knows Fortran 90 = dependencies (as well as C, C++, Java etc).=A0

Drew
= --Apple-Mail-1--520490627-- From owner-chemistry@ccl.net Fri Sep 30 20:55:01 2005 From: "Wayne Steinmetz WES04747!A!pomona.edu" To: CCL Subject: CCL: FW: QCPE Programs Message-Id: <-29436-050930174149-26600-/jgHoIzzWk9UoKMjo01e8g=server.ccl.net> X-Original-From: "Wayne Steinmetz" Content-class: urn:content-classes:message Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="us-ascii" Date: Fri, 30 Sep 2005 14:40:34 -0700 MIME-Version: 1.0 Sent to CCL by: "Wayne Steinmetz" [WES04747=pomona.edu] If you want to perform serious QSAR, you need tools that are not available through QCPE. I would place clogp which is marketed by Biobyte at the top of the list. Beyond that, you want a flexible statistics package. Corwin Hansch uses his own program. I use NCSS. Excel is trash! You will find that a good modeling program is very helpful. If you are working with organic molecules, you will find that the entry-level version of Spartan will cover all your needs. Spartan is competitively priced and is worth the investment. Spartan has a superb GUI. Make sure that the version of Spartan that you purchase has the modules for searching conformational space. Finally, purchase both volumes of C. Hansch and A. Leo, Exploring QSAR. The first volume discusses the methodology and the second is full of tables. Wayne E. Steinmetz Carnegie Professor of Chemistry Woodbadge Course Director Chemistry Department Pomona College 645 North College Avenue Claremont, California 91711-6338 USA phone: 1-909-621-8447 FAX: 1-909-707-7726 Email: wsteinmetz..pomona.edu WWW: pages.pomona.edu/~wsteinmetz -----Original Message----- > From: owner-chemistry..ccl.net [mailto:owner-chemistry..ccl.net] Sent: Friday, September 30, 2005 5:52 AM To: Wayne Steinmetz Subject: CCL: FW: QCPE Programs Sent to CCL by: [peter.gray*|*utt.edu.tt] --Replace strange characters with the "at" sign to recover email address--. Friday, September 30, 2005 DEAR QCPE LIST MEMBERS: At the University of Trinidad and Tobago (UTT), w are trying to develop our software capablities in all areas of science, particlarly relating to the energy sector (primarily petroleum and process/utility engineering). We soon hope to engage in research pertaining to the organic chemistry of petroleum-based structures, using quantitative structure-activity (QSAR) correlations to optimise synthetic strategies, and also to prepare students for studies involving chemisorption of organics onto the interior surfaces of porous rock matrices. To this end, I am writing to request your input in terms of the most appropriate modules that would best serve our needs. Having checked the QCPE catalog listing and found that many of the the programs were not currently available, I think I can guess (from memory) that the basic packages should include: i)a molecular mechanics routine for simple input and display (?) of organic structures(MM2, MM3); ii) a program such as ICON8 or FORTICON for performing Huckel calculations on structures involving heavy atoms (e.g., Ni or V chelated in an asphaltene macomolecule); and perhaps iii) a crystallographic surface modeler to display lattice faces, etc. [this latter functionality also to be applied in materials research pertaining to solar-photovoltaic R&D]. We are also prepared tp purchase commercial packages if thre are any reasonable ones out there, so any feedback you could provide would be greatly appreciated, particularly regarding cost and/or licencing requirements. Thank you very much. Sincerely, Peter Gray Assistant Professor, Energy Programmes Univ. of Trinidad & Tobago (UTT) Esperanza Road, Brechin Castle Couva, Trinidad. (868) 636-4125, ext. 3008, or (868) 740-7568( cell.)http://www.ccl.net/cgi-bin/ccl/send_ccl_messagehttp://www.ccl.net/chemistry/sub_unsub.shtmlhttp://www.ccl.net/spammers.txt------------------------------------------------------------- This message has been scanned by Postini anti-virus software. From owner-chemistry@ccl.net Fri Sep 30 21:30:00 2005 From: "Igor Filippov Contr igorf[]helix.nih.gov" To: CCL Subject: CCL: W:hardware for computational chemistry calculations Message-Id: <-29437-050930175653-2173-Tixf4Kam84fPqpXBXzr6kg++server.ccl.net> X-Original-From: "Igor Filippov [Contr]" Content-Transfer-Encoding: 7bit Content-Type: text/plain Date: Fri, 30 Sep 2005 17:19:00 -0400 Mime-Version: 1.0 Sent to CCL by: "Igor Filippov [Contr]" [igorf|*|helix.nih.gov] Excellent advice. I would agree with everything, except for the "buy Dell" part. If you've bought Dell (and probably any other named brand PC) - be prepared that it won't be upgradable, and after this particular model goes out of fashion it won't be repairable either. Their cases are a nightmare to disassemble - sure, everything opens up by just pushing a little button somewhere or pulling a plastic tab elsewhere, but the time you'll spend looking for those buttons and tabs... And every new model of Dell PC has a different system of things to push and pull just to replace a hard drive. The creative engineering there knows no bounds. I would suggest buying things from a small-time vendor that: a) uses only non-proprietary components - i.e. case, power supply, etc. that you can get at any CompUSA or BestBuy if you ever need to replace them. b) allows you to completely configure the system on their website before you purchase it - by "completely" I mean to the level of specifying what CPU fan you'd prefer to use. Make sure you get a very good CPU fan. This is not something to save money on. This way you'll get exactly what you designed yourself and you'll be able to repair/upgrade/modify it by using a simple Philips screwdriver and parts that you can get at any computer store. And it will be cheaper too - I'm more than a little surprised about the talk about "cheap prices at Dell" - go to pricewatch.com you can find tonnes of places with better deals, where you don't have to pay for the "Dell" sticker on your computer case. Igor On Fri, 2005-09-30 at 11:49 -0400, CCL: Perry E. Metzger perry(-)piermont.com wrote: > Sent to CCL by: "Perry E. Metzger" [perry:piermont.com] > > --Replace strange characters with the "at" sign to recover email address--. > > > "Luis Manuel Simon" writes: > > Probably, there have been many discussions about hardware on this > > list, but somehow I need some update about few questions: > > > > Which is the better performance/price choice for computational > > chemistry (quantum chemistry and mollecular dynamic simulations)? > > Is it better a PC-cluster or a workstation? Several PC nodes in a > > cluster or several processors in a board? > > AMD 64, OPTERON, intel PIV, Xeon, SPARC? Are dual processors worth? > > How important is microprocessor cache size? > > How important is RAM size? And registered DDR modules? > > Is it RAID worth? Does SCSI hard drive really perform better than SATA? > > What about operating system, linux distribution, etc? > > Is there any comparison, next to spec.org, about different configurations? > > > From what I can tell, at the moment (and this could change at any > time), the price/performance of AMD 64 equipment ("Opteron" is just a > model of AMD 64) is by far the best. I know people who do a lot of > number crunching who are buying AMD 64 whiteboxes by the fleet, and > putting them in clusters. > > As to the rest, the Sparc is very very far behind on the > price/performance curve at this point. I wouldn't even vaguely > consider it. > > Cache size is of course quite important on modern machines, because > main memory continues to lag far behind the speed of the cache. Taking > a cache miss means your processor sits around twiddling its thumbs for > a very long time, so you want as few cache misses as possible. That > said, the precise size of cache that is important to you is totally > dependent on the specific problem you are working on. Some problems > fit in fairly small caches, some need very large caches. "It depends." > Of course, since you can't buy cache separately from the processor in > a modern machine, generally speaking this isn't something to do > separately from the processor decision -- if you've benchmarked a > particular processor and it works best, you know the cache it has is > the best for your problem. > > RAM size is also an issue. On a modern machine, you want to avoid ever > getting page faults because paging something in is Very Very Very > Slow. That means you want enough RAM that your entire working set fits > in memory nicely. RAM is also used these days as buffer cache for file > data, so the more RAM you have, the faster file i/o ends up being if > you're doing lots of it. So, again, how much is enough depends a lot > on your problem. Different sized problems will eat different amounts > of RAM successfully. Luckily, these days RAM is dirt cheap. The > biggest issue you will have is in dealing with problems that need very > large memory spaces -- if you need an address space for your problem > with more than a gig or two of memory, you need a 64 bit > processor. (Technically, a 32 bit processor can handle 4G of address > space, but remember that in most OSes, a big chunk (sometimes half) of > the address space (not memory, address space!) is used by the OS, and > mappings for the stack, shared libraries, etc., will make it > impossible to truly use all the rest.) The 32 bit x86 processors can > use more than 4G of RAM, but they can't devote it all to the address > space of one process -- it is only really useful if you have multiple > processes that can make use of it -- so again, if you have a problem > that needs a big address space, you want AMD 64 or the Intel stuff > with the same 64 bit extensions (but those processors aren't as fast.) > > On the question of clusters versus MP in a single machine, again, > "that depends". Multiple processors or machines in general will only > help you if your problem is easily parallelized. If it is easily > parallelized but requires extremely tight coupling (i.e. you've got > some small places where you could vectorize but you'll lose if you > have to take a communications hit), even more than one processor won't > help. If you have somewhat looser communications constraints but need > shared RAM in order to operate effectively, you have no choice but to > use an MP machine. Here again, though, keep in mind that you have > strong limits to where you will get that way -- price/performance of > MP machines goes down sharply with the number of processors, and > affordable MP machines rarely have more than 4. Even in clusters, > though, sometimes dual processor machines make sense if you save > enough on things like power supplies, cases, etc. that you've saved > money over all. If your problem is embarrassingly parallel and you can > put it over a cluster, by all means, use a cluster. Especially with > gig E networking cards as cheap as they are now, you'll win big. > > On disk performance and controllers: in computational problems, it is > very rare that you are actually remotely I/O bound. Most computational > chemistry isn't moving 200G of data set in and out of RAM as fast as > possible, it is loading a problem into memory and the problem then > stays in memory. If your problem is a factor of 2 too big for memory, > don't get a faster disk controller, get more RAM -- it will make far > more of a difference. In other applications -- if you were building a > database server, say, or you have a rare chem problem that actually is > disk bound -- I'd give a different answer. In general, though, these > days I go with SATA when I can -- the price/performance of SCSI > doesn't justify it any more except at the very high end of I/O > needs. RAID is nice on a server because it can save you when you have > trouble and such, but really, RAID or SCSI on machines in your compute > cluster would be silly, since they're not going to do much disk i/o if > you can help it! If your cluster machine isn't doing much disk i/o, > just use the SATA or IDE controller on the mother board and be done > with it. > > On RAM, for large memories, you really *need* ECC. The odds are just > too high that you'll get a single bit error somewhere and ruin days of > number crunching with it. Skimping on fancy cases for your computers > is one thing, skimping on ECC is another. Incidently, not all chip > sets actually pay attention to ECC! Make sure your motherboards do, or > you'll be spending extra money for nothing. > > By the same token, incidently, do not get crappy power supplies -- > they are by far and away (in my experience) the biggest source of > "mysterious trouble" in modern machines. A nice ANTEC or other quality > supply properly rated for the power consumption of your cluster member > will make it a whole lot happier long run, which means less trouble > for you. Similarly, clean AC power going in, and a nice clean machine > room (google for "zinc whiskers" some time) will make you far happier. > > As for operating systems, that's a matter of taste. So long as you > aren't Windows, you'll be fine. And yes, I'm quite serious about "not > Windows". You would imagine that since we're talking about something > compute bound that barely cares about the kernel, all OSes would be > the same, but you would be wrong. > > There are multiple reasons to stay away from Windows for compute > clusters. First, there are dumb architectural mistakes in Windows that > make it do too much I/O -- it pages too often, and doesn't use RAM as > buffer cache efficiently. Linux and BSD also need tuning to minimize > paging, but you at least *can* effectively do the tuning. On Windows, > you'll be fiddling with the registry forever, trying to figure out why > it is that you can't get the buffer cache large enough and can't keep > your executable pages in RAM long enough even though there are gigs of > free memory, and then you'll spend six hours on the phone with > Redmond, and then you'll give up. Give up in advance -- you will be > happier. Also, network I/O performance just can't be tuned up as far > as you want on Windows. Lastly, and almost most significantly, you can > set up Linux or NetBSD or FreeBSD so that you just shove another box > into the rack, let it PXE boot, and walk away from it, never having to > think about it again until the day your management script says you > need to replace it because it died. You just can't do that with > Windows -- it is simply not architected right to allow you to mass > manage that way. I've set up systems for mass managing hundreds of > machines in Unix clusters without human intervention, and I know of no > one who has ever come close on that level of automation with > Windows. Keep away. Even if you're managing one box, it is still too > much of a pain. By the way, all this is even ignoring the needless > expense of Windows licenses that could be better spent on faster > processors or more RAM. I know hedge funds where money is no object > and still none of them run Windows on compute clusters. > > Things are a bit different if you're just buying a personal > workstation. In that case, I'd buy a Mac. :) > > All that said, if you are building a compute cluster, if you use a > fairly late model Linux, NetBSD, FreeBSD, etc., you can make it work > well. I'm a NetBSD bigot myself, but that is not for reasons that > would impact computational clusters substantially. You can do fine > with any of them if you're doing what is largely number crunching. The > one to pick is the one that you or your admin staff feel most > comfortable about managing -- and most importantly, automating the > management so you don't ever have to log on to 10 or 50 or even 5 > boxes to fix something. > > A strong recommendation though that I'll bring up here because it is > vaguely OS related -- do NOT use more threads than processors in your > app if you know what is good for you. Thread context switching is NOT > instant, and you do not want to burn up good computation cycles on > useless thread switching. If you have one processor machines in your > cluster, stick to one computing process/thread on it. If you have dual > processor boxes, one process with two threads or two processes with > one thread make fine sense, but 40 would not be a good use of your > cycles. If you need to talk to 60 TCP sockets to share data between > boxes, use event driven code, not 60 threads, if you want performance. > > A final recommendation about buying stuff. > > If you are buying one workstation for yourself, buy a Mac. > > If you are buying just a couple of compute servers to run an open > source Unix, buy Dell -- for whatever reason, their prices are now > totally insanely below what I can manage anywhere else in low > quantities -- but be careful about which of the "small business" and > "academic" discounts are lower at the moment. Often the academic price > is insanely high for no obvious reason. > > If you are buying 50 and especially 500 machines, either spec and buy > parts and assemble the things, or spec the parts and work with a > reputable white box manufacturer to get them built for you. For large > clusters, you want to get *exactly* what you want. You especially > don't want to find out months down the line that half the machines are > subtly different from the other half. Also, for large clusters, the > maint. contracts you can get with things like Dells are useless > expenses -- just buy spare machines and spare parts, they're cheaper > -- and keep in mind that these days, the biggest single limiting > factor you'll get in the average machine room for a large cluster is > getting enough power in and enough heat out. > > For truly huge clusters, you can start doing truly odd things to get > better price/performance. Google does a couple of rather radical > things -- for example they don't put their machines in real cases (it > would cost more money and would lower the rate at which their racks > can extract heat from the systems, not to mention that it slows down > getting at the machines). You don't have to go that far, but even in > smaller clusters thinking about mechanics can help. Nylon thumb screws > instead of metal screws make getting stuff in and out faster. Velcro > wraps instead of nylon tie wraps can make it far easier to pull things > in and out. Properly planning your cabling (and labeling it!) so you > can be sure that the connectors on the ethernet switch systematically > correspond to the machines in the rack yields surprising benefits. Oh, > and always remember, automate everything in the systems administration > you can possibly automate. > > Perry> From owner-chemistry@ccl.net Fri Sep 30 22:05:00 2005 From: "Eric Bennett ericb-,-pobox.com" To: CCL Subject: CCL: W:hardware for computational chemistry calculations Message-Id: <-29438-050930181926-14475-7mMw069gEBfzsMikenCo0Q#%#server.ccl.net> X-Original-From: Eric Bennett Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Date: Fri, 30 Sep 2005 16:38:41 -0500 MIME-Version: 1.0 Sent to CCL by: Eric Bennett [ericb=-=pobox.com] CCL wrote: >Which is the better performance/price choice for computational chemistry (quantum chemistry and mollecular dynamic simulations)? >Is it better a PC-cluster or a workstation? Several PC nodes in a cluster or several processors in a board? >AMD 64, OPTERON, intel PIV, Xeon, SPARC? Are dual processors worth? > > In testing by various people at the supercomputing center here we've found AMD to be equal to or faster than Intel for QM and MM applications. Both have gotten somewhat faster since we ran our test, but I imagine the trend probably holds. A number of us here are leaning towards purchasing AMD systems as a result of our benchmarks. The benchmarks that I personally ran are belows (all machines have SCSI local scratch disks but I am not sure what the speeds of the drives are). I think some other people here tested Gaussian and CHARMM and also found AMD to be somewhat faster but I do not have their numbers handy at the moment. *** Jaguar 5.5 *** B3LYP single point energy, 393 basis functions SGI Onyx, 750 MHz R16000 x 2 CPUs 5.5 min IBM IntelliStation A Pro, 2400 MHz Opteron 6.9 min HP xw8200 3400 MHz Xeon 7.7 min Dell Precision 670, 3000 MHz Xeon 7.7 min SGI Onyx, 750 MHz R16000 x 1 9.7 min Local MP2 single point energy, 1170 basis functions (uses several GB of scratch space on disk) SGI Onyx, 750 MHz R16000 x 2 545.1 min IBM IntelliStation A Pro, 2400 MHz Opteron 748.7 min HP xw8200 3400 MHz Xeon 899.8 min Dell Precision 670, 3000 MHz Xeon 960.7 min SGI Onyx, 750 MHz R16000 x 1 1051.5 min *** MacroModel 8 *** OPLS force field: restrained minimization of a protein with ~ 3500 atoms IBM 2400 MHz Opteron 16.2 min Dell Precision 670n, 3200 MHz Xeon 18.2 min Dell Prevision 670, 3000 MHz Xeon 20.1 min Sun Fire v440, 1280 MHz UltraSparc IIIi 32.7 min SGI Octane2, 600 MHz R14000 35.3 min The HP system gave surprisingly slow results (~ 26 min) on this last test but it was a loaner system and I did not pinpoint the source of the slowness before returning it. I consider that number an untrustworthy outlier. In other MacroModel tests the HP Xeon system did beat the other Xeon systems as expected. Dual processors are definitely better than single; it's almost always cheaper than two single CPU workstations and with good QM or MD code you should cut your calculation times almost, but not quite, in half. I haven't run calculations that spanned multiple machines in a cluster, so I can't comment on that. >How important is microprocessor cache size? >How important is RAM size? And registered DDR modules? >Is it RAID worth? Does SCSI hard drive really perform better than SATA? > > Having enough RAM is always the most important thing. If you don't have enough memory to hold your software and its working data set in RAM, that will for certain be the limiting factor in your speed. 15,000 RPM drives are only available with SCSI interfaces; the SATA drives, even with their higher data density, don't have performance specs that match up (15K SCSI gets you max sustained transfers of around 90 MB/sec). So if you are doing something disk-intensive like large QM calculations, there are still people who will buy SCSI. QM jobs can end up writing over 10 GB of scratch files. For MM apps like dynamics the disk speed is not critical. Perry Metzger writes: >A strong recommendation though that I'll bring up here because it is >vaguely OS related -- do NOT use more threads than processors in your >app if you know what is good for you. Thread context switching is NOT >instant, and you do not want to burn up good computation cycles on >useless thread switching. Somewhat relevant to this: I have seen about a 25% throughput increase in my MM calculations when using hyperthreading, running four processes on a 2 CPU Xeon machine with hyperthreading on, as compared to two processes with hyperthreading off. In the special case of hyperthreading sometimes you can benefit. -- Eric Bennett, PhD Assistant Director, Center for Drug Design, U of Minnesota I am not a vegetarian because I love animals. I am a vegetarian because I hate plants. - A. Whitney Brown From owner-chemistry@ccl.net Fri Sep 30 22:39:01 2005 From: "Rick Venable rvenable() pollux.cber.nih.gov" To: CCL Subject: CCL: W:hardware for computational chemistry calculations Message-Id: <-29439-050930191441-15334-4xzKZMdWJhGoBVu6HWM1Fg+/-server.ccl.net> X-Original-From: Rick Venable Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Fri, 30 Sep 2005 19:14:14 -0400 MIME-Version: 1.0 Sent to CCL by: Rick Venable [rvenable .. pollux.cber.nih.gov] Actually, many computational chemistry programs are somewhere in between with respect to parallel scaling, particularly MD programs. Naturally, shared memory MP gives the best performance, but a reasonable compromise is a cluster with some form of specialized communications hardware. Some examples are Myrinet, InfiniBand, and EtherFabric; I've recently run some CHARMM benchmarks on all 3 types and the performance and scalability of each seems to be comparable, and much, much better than gigabit ethernet. The rest of the post was very thoughtful, and almost makes up for days of somewhat misguided Fortran and Fortran programmer bashing. ------------------------------------- Rick Venable 29/500 FDA/CBER/OVRR Biophysics Lab 1401 Rockville Pike HFM-419 Rockville, MD 20852-1448 U.S.A. (301) 496-1905 Rick_Venable AT nih*gov ALT email: rvenable AT speakeasy*org ------------------------------------- www.redcross.org On Fri, 30 Sep 2005, CCL: Perry E. Metzger perry(!)piermont.com wrote: > On the question of clusters versus MP in a single machine, again, > "that depends". Multiple processors or machines in general will only > help you if your problem is easily parallelized. If it is easily > parallelized but requires extremely tight coupling (i.e. you've got > some small places where you could vectorize but you'll lose if you > have to take a communications hit), even more than one processor won't > help. If you have somewhat looser communications constraints but need > shared RAM in order to operate effectively, you have no choice but to > use an MP machine. Here again, though, keep in mind that you have > strong limits to where you will get that way -- price/performance of > MP machines goes down sharply with the number of processors, and > affordable MP machines rarely have more than 4. Even in clusters, > though, sometimes dual processor machines make sense if you save > enough on things like power supplies, cases, etc. that you've saved > money over all. If your problem is embarrassingly parallel and you can > put it over a cluster, by all means, use a cluster. Especially with > gig E networking cards as cheap as they are now, you'll win big. From owner-chemistry@ccl.net Fri Sep 30 23:14:01 2005 From: "Joseph Han jhh3851^^^yahoo.com" To: CCL Subject: CCL: W:hardware for computational chemistry calculations Message-Id: <-29440-050930202258-23390-BkHH/lMjD7Z4aERGWsahEg*o*server.ccl.net> X-Original-From: Joseph Han Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Date: Fri, 30 Sep 2005 16:22:50 -0700 (PDT) MIME-Version: 1.0 Sent to CCL by: Joseph Han [jhh3851^yahoo.com] Perry made some good suggestions. I would add a few more. (1) A good compiler with properly chosen optimization flags and a tuned math kernel library can greatly increase the speed of some codes. There are several options for each of those and have some suggestions if you would like to e-mail mail me privately. When benchmarking different platforms (Opteron, Sun, Xeon, etc.), it would be best the run the most optimized code on each. (2) There are vendors who provide turnkey clusters if you do not have the time or inclination to build it yourself. The prices last time I looked were reasonable (about the same as what I could build myself before accounting for labor) and some had really nice features such as only two industrial fans for the entire rack and vertical mounting on aluminium sheets. Some really nice stuff. In my experience, I totally agree with the comment regarding power supplies, but also I've had a signifiant number of fans (both CPU and case) freeze up. Joseph --- "CCL: Perry E. Metzger perry-.-piermont.com" wrote: > > Sent to CCL by: "Perry E. Metzger" [perry:piermont.com] > > --Replace strange characters with the "at" sign to recover email address--. > > > "Luis Manuel Simon" writes: > > Probably, there have been many discussions about hardware on this > > list, but somehow I need some update about few questions: > > > > Which is the better performance/price choice for computational > > chemistry (quantum chemistry and mollecular dynamic simulations)? > > Is it better a PC-cluster or a workstation? Several PC nodes in a > > cluster or several processors in a board? > > AMD 64, OPTERON, intel PIV, Xeon, SPARC? Are dual processors worth? > > How important is microprocessor cache size? > > How important is RAM size? And registered DDR modules? > > Is it RAID worth? Does SCSI hard drive really perform better than SATA? > > What about operating system, linux distribution, etc? > > Is there any comparison, next to spec.org, about different configurations? > > > From what I can tell, at the moment (and this could change at any > time), the price/performance of AMD 64 equipment ("Opteron" is just a > model of AMD 64) is by far the best. I know people who do a lot of > number crunching who are buying AMD 64 whiteboxes by the fleet, and > putting them in clusters. > > As to the rest, the Sparc is very very far behind on the > price/performance curve at this point. I wouldn't even vaguely > consider it. > > Cache size is of course quite important on modern machines, because > main memory continues to lag far behind the speed of the cache. Taking > a cache miss means your processor sits around twiddling its thumbs for > a very long time, so you want as few cache misses as possible. That > said, the precise size of cache that is important to you is totally > dependent on the specific problem you are working on. Some problems > fit in fairly small caches, some need very large caches. "It depends." > Of course, since you can't buy cache separately from the processor in > a modern machine, generally speaking this isn't something to do > separately from the processor decision -- if you've benchmarked a > particular processor and it works best, you know the cache it has is > the best for your problem. > > RAM size is also an issue. On a modern machine, you want to avoid ever > getting page faults because paging something in is Very Very Very > Slow. That means you want enough RAM that your entire working set fits > in memory nicely. RAM is also used these days as buffer cache for file > data, so the more RAM you have, the faster file i/o ends up being if > you're doing lots of it. So, again, how much is enough depends a lot > on your problem. Different sized problems will eat different amounts > of RAM successfully. Luckily, these days RAM is dirt cheap. The > biggest issue you will have is in dealing with problems that need very > large memory spaces -- if you need an address space for your problem > with more than a gig or two of memory, you need a 64 bit > processor. (Technically, a 32 bit processor can handle 4G of address > space, but remember that in most OSes, a big chunk (sometimes half) of > the address space (not memory, address space!) is used by the OS, and > mappings for the stack, shared libraries, etc., will make it > impossible to truly use all the rest.) The 32 bit x86 processors can > use more than 4G of RAM, but they can't devote it all to the address > space of one process -- it is only really useful if you have multiple > processes that can make use of it -- so again, if you have a problem > that needs a big address space, you want AMD 64 or the Intel stuff > with the same 64 bit extensions (but those processors aren't as fast.) > > On the question of clusters versus MP in a single machine, again, > "that depends". Multiple processors or machines in general will only > help you if your problem is easily parallelized. If it is easily > parallelized but requires extremely tight coupling (i.e. you've got > some small places where you could vectorize but you'll lose if you > have to take a communications hit), even more than one processor won't > help. If you have somewhat looser communications constraints but need > shared RAM in order to operate effectively, you have no choice but to > use an MP machine. Here again, though, keep in mind that you have > strong limits to where you will get that way -- price/performance of > MP machines goes down sharply with the number of processors, and > affordable MP machines rarely have more than 4. Even in clusters, > though, sometimes dual processor machines make sense if you save > enough on things like power supplies, cases, etc. that you've saved > money over all. If your problem is embarrassingly parallel and you can > put it over a cluster, by all means, use a cluster. Especially with > gig E networking cards as cheap as they are now, you'll win big. > > On disk performance and controllers: in computational problems, it is > very rare that you are actually remotely I/O bound. Most computational > chemistry isn't moving 200G of data set in and out of RAM as fast as > possible, it is loading a problem into memory and the problem then > stays in memory. If your problem is a factor of 2 too big for memory, > don't get a faster disk controller, get more RAM -- it will make far > more of a difference. In other applications -- if you were building a > database server, say, or you have a rare chem problem that actually is > disk bound -- I'd give a different answer. In general, though, these > days I go with SATA when I can -- the price/performance of SCSI > doesn't justify it any more except at the very high end of I/O > needs. RAID is nice on a server because it can save you when you have > trouble and such, but really, RAID or SCSI on machines in your compute > cluster would be silly, since they're not going to do much disk i/o if > you can help it! If your cluster machine isn't doing much disk i/o, > just use the SATA or IDE controller on the mother board and be done > with it. > > On RAM, for large memories, you really *need* ECC. The odds are just > too high that you'll get a single bit error somewhere and ruin days of > number crunching with it. Skimping on fancy cases for your computers > is one thing, skimping on ECC is another. Incidently, not all chip > sets actually pay attention to ECC! Make sure your motherboards do, or > you'll be spending extra money for nothing. > > By the same token, incidently, do not get crappy power supplies -- > they are by far and away (in my experience) the biggest source of > "mysterious trouble" in modern machines. A nice ANTEC or other quality > supply properly rated for the power consumption of your cluster member > will make it a whole lot happier long run, which means less trouble > for you. Similarly, clean AC power going in, and a nice clean machine > room (google for "zinc whiskers" some time) will make you far happier. > > As for operating systems, that's a matter of taste. So long as you > aren't Windows, you'll be fine. And yes, I'm quite serious about "not > Windows". You would imagine that since we're talking about something > compute bound that barely cares about the kernel, all OSes would be > the same, but you would be wrong. > > There are multiple reasons to stay away from Windows for compute > clusters. First, there are dumb architectural mistakes in Windows that > make it do too much I/O -- it pages too often, and doesn't use RAM as > buffer cache efficiently. Linux and BSD also need tuning to minimize > paging, but you at least *can* effectively do the tuning. On Windows, > you'll be fiddling with the registry forever, trying to figure out why > it is that you can't get the buffer cache large enough and can't keep > your executable pages in RAM long enough even though there are gigs of > free memory, and then you'll spend six hours on the phone with > Redmond, and then you'll give up. Give up in advance -- you will be > happier. Also, network I/O performance just can't be tuned up as far > as you want on Windows. Lastly, and almost most significantly, you can > set up Linux or NetBSD or FreeBSD so that you just shove another box > into the rack, let it PXE boot, and walk away from it, never having to > think about it again until the day your management script says you > need to replace it because it died. You just can't do that with > Windows -- it is simply not architected right to allow you to mass > manage that way. I've set up systems for mass managing hundreds of > machines in Unix clusters without human intervention, and I know of no > one who has ever come close on that level of automation with > Windows. Keep away. Even if you're managing one box, it is still too > much of a pain. By the way, all this is even ignoring the needless > expense of Windows licenses that could be better spent on faster > processors or more RAM. I know hedge funds where money is no object > and still none of them run Windows on compute clusters. > > Things are a bit different if you're just buying a personal > workstation. In that case, I'd buy a Mac. :) > > All that said, if you are building a compute cluster, if you use a > fairly late model Linux, NetBSD, FreeBSD, etc., you can make it work > well. I'm a NetBSD bigot myself, but that is not for reasons that > would impact computational clusters substantially. You can do fine > with any of them if you're doing what is largely number crunching. The > one to pick is the one that you or your admin staff feel most > comfortable about managing -- and most importantly, automating the > management so you don't ever have to log on to 10 or 50 or even 5 > boxes to fix something. > > A strong recommendation though that I'll bring up here because it is > vaguely OS related -- do NOT use more threads than processors in your > app if you know what is good for you. Thread context switching is NOT > instant, and you do not want to burn up good computation cycles on > useless thread switching. If you have one processor machines in your > cluster, stick to one computing process/thread on it. If you have dual > processor boxes, one process with two threads or two processes with > one thread make fine sense, but 40 would not be a good use of your > cycles. If you need to talk to 60 TCP sockets to share data between > boxes, use event driven code, not 60 threads, if you want performance. > > A final recommendation about buying stuff. > > If you are buying one workstation for yourself, buy a Mac. > > If you are buying just a couple of compute servers to run an open > source Unix, buy Dell -- for whatever reason, their prices are now > totally insanely below what I can manage anywhere else in low > quantities -- but be careful about which of the "small business" and > "academic" discounts are lower at the moment. Often the academic price > is insanely high for no obvious reason. > > If you are buying 50 and especially 500 machines, either spec and buy > parts and assemble the things, or spec the parts and work with a > reputable white box manufacturer to get them built for you. For large > clusters, you want to get *exactly* what you want. You especially > don't want to find out months down the line that half the machines are > subtly different from the other half. Also, for large clusters, the > maint. contracts you can get with things like Dells are useless > expenses -- just buy spare machines and spare parts, they're cheaper > -- and keep in mind that these days, the biggest single limiting > factor you'll get in the average machine room for a large cluster is > getting enough power in and enough heat out. > > For truly huge clusters, you can start doing truly odd things to get > better price/performance. Google does a couple of rather radical > things -- for example they don't put their machines in real cases (it > would cost more money and would lower the rate at which their racks > can extract heat from the systems, not to mention that it slows down > getting at the machines). You don't have to go that far, but even in > smaller clusters thinking about mechanics can help. Nylon thumb screws > instead of metal screws make getting stuff in and out faster. Velcro > wraps instead of nylon tie wraps can make it far easier to pull things > in and out. Properly planning your cabling (and labeling it!) so you > can be sure that the connectors on the ethernet switch systematically > correspond to the machines in the rack yields surprising benefits. Oh, > and always remember, automate everything in the systems administration > you can possibly automate. > > Perry> > > > From owner-chemistry@ccl.net Fri Sep 30 23:50:00 2005 From: "Robert Duke rduke,email.unc.edu" To: CCL Subject: CCL: Cleaning up dusty deck fortran and converting to C/C++ - Wrap up Message-Id: <-29441-050930222121-27851-dLRvAMp9GhN1Vt5icqwkTw%server.ccl.net> X-Original-From: "Robert Duke" Content-Type: multipart/alternative; boundary="----=_NextPart_000_012C_01C5C60D.415FA970" Date: Fri, 30 Sep 2005 22:21:08 -0400 MIME-Version: 1.0 Sent to CCL by: "Robert Duke" [rduke*_*email.unc.edu] This is a multi-part message in MIME format. ------=_NextPart_000_012C_01C5C60D.415FA970 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Drew - I am a little chagrinned, and have to admit I did not think this one out = completely, confusing two different implementations of arrays of ptrs. = The classic C array of ptrs is actually a situation where you first = allocate an array of ptrs, and then do separate allocations for each of = those ptrs. This creates something that is logically 2-d but not = contiguous, you track one index in the array of ptrs and the other in = the offset from the ptr. This is the typical c setup, but when the = array of ptrs implementation of a 2d array was brought up, it instead = entailed a block of contiguous space, a separate ptr array, and a fixup = step where you set the ptrs. This is of course logically identical to = the classic c array, but there should not be a problem with library = usage. I was hardwired to whine about this not working because of the = fftw dock talking about how arrays of ptrs were a deathtrap. Depends on = implementation. Thanks for the clarification, and for the tip on build = alternatives! Regards - Bob ----- Original Message -----=20 From: Drew McCormack da.mccormack ~ few.vu.nl=20 To: Duke, Robert E =20 Sent: Friday, September 30, 2005 4:02 PM Subject: CCL: Cleaning up dusty deck fortran and converting to C/C++ - = Wrap up Hi Bob, 2) The "array of pointers" implementation of multidimensional arrays = in c is generally not a good approach for numerical s/w for a variety of = reasons, mostly performance but also in regard to interfacing with = numerical analysis libraries that expect real arrays. I am also not a big fan of the approach, but it does seem to be what = was taught to generations of programmers, particularly before C99.=20 I can see the problems with performance you refer to, but is there = really a problem with libraries? The data itself is stored in a = contiguous buffer, and so can just be passed to most libraries (eg BLAS, = LAPACK, FFTW etc). (Of course, the library will not use the array of = pointers, but so long the ordering is consistent, it shouldn't matter.) F90/95 compilers often ship with proprietary build tools that can = handle issues of module dependencies and manage the compilation/linking = process. That's great, unless you happen to work with just about every = machine and operating system that runs unix (that would be me). In that = case, you want to be able to use something nice and generic like make = that you will find on every system. I indeed do use make and makefiles, = but I include a homebrew perl script that can be used to sort out the = dependencies found in #include preprocessor statements, in fortran = include statements, and in f90/95 "use" statements. This works = reasonably well, but I did not come upon the solution overnight. I may = be able to share the script with anyone interested, but will have to = check. I have been reasonably impressed by an up-and-coming build system = called Scons (http://www.scons.org/). It is a python package, so very = portable. The equivalent of a makefile in Scons is actually a special = python script, which can be very powerful, because you can do anything = you can do in python. It knows Fortran 90 dependencies (as well as C, = C++, Java etc).=20 Drew ------=_NextPart_000_012C_01C5C60D.415FA970 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Drew -
I am a little chagrinned, and have to admit I did = not think=20 this one out completely, confusing two different implementations of = arrays of=20 ptrs.  The classic C array of ptrs is actually a situation where = you first=20 allocate an array of ptrs, and then do separate allocations for each of = those=20 ptrs.  This creates something that is logically 2-d but not = contiguous, you=20 track one index in the array of ptrs and the other in the offset from = the=20 ptr.   This is the typical c setup, but when the array of ptrs = implementation of a 2d array was brought up, it instead entailed a block = of=20 contiguous space, a separate ptr array, and a fixup step where you set = the=20 ptrs.  This is of course logically identical to the classic c = array, but=20 there should not be a problem with library usage.  I was hardwired = to whine=20 about this not working because of the fftw dock talking about how arrays = of ptrs=20 were a deathtrap.  Depends on implementation.  Thanks for the=20 clarification, and for the tip on build alternatives!
Regards - Bob
----- Original Message -----
From:=20 Drew=20 McCormack da.mccormack ~ few.vu.nl
Sent: Friday, September 30, = 2005 4:02=20 PM
Subject: CCL: Cleaning up dusty = deck=20 fortran and converting to C/C++ - Wrap up

Hi Bob,
2)=20 The "array of pointers" implementation of multidimensional arrays in = c is=20 generally not a good approach for numerical s/w for a variety of = reasons,=20 mostly performance but also in regard to interfacing with numerical = analysis=20 libraries that expect real=20 arrays.

I am also not a big = fan of=20 the approach, but it does seem to be what was taught to generations of = programmers, particularly before C99. 
I can see the problems with performance you refer to, but is = there really=20 a problem with libraries? The data itself is stored in a contiguous = buffer,=20 and so can just be passed to most libraries (eg BLAS, LAPACK, FFTW = etc). (Of=20 course, the library will not use the array of pointers, but so long = the=20 ordering is consistent, it shouldn't matter.)

 
F90/95 compilers often ship with = proprietary build=20 tools that can handle issues of module dependencies and manage the=20 compilation/linking process.  That's great, unless you happen = to work=20 with just about every machine and operating system that runs unix = (that=20 would be me).  In that case, you want to be able to use = something nice=20 and generic like make that you will find on every system.  I = indeed do=20 use make and makefiles, but I include a homebrew perl script that = can be=20 used to sort out the dependencies found in #include preprocessor = statements,=20 in fortran include statements, and in f90/95 "use" statements.  = This=20 works reasonably well, but I did not come upon the solution = overnight. =20 I may be able to share the script with anyone interested, but will = have to=20 check.
 
I have=20 been reasonably impressed by an up-and-coming build system called = Scons (http://www.scons.org/). It is a = python=20 package, so very portable. The equivalent of a makefile in Scons is = actually a=20 special python script, which can be very powerful, because you can do = anything=20 you can do in python. It knows Fortran 90 dependencies (as well as C, = C++,=20 Java etc). 

Drew
------=_NextPart_000_012C_01C5C60D.415FA970--