From owner-chemistry@ccl.net Tue Sep 27 08:39:07 2005 From: "CCL" To: CCL Subject: CCL: Open source contributions by pharma. Message-Id: <-29322-050927000041-10891-gPdxW3MWJDw6WRh6ww7CWw^^server.ccl.net> X-Original-From: "Peter Spiro" content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C311.9C552BD8" Date: Mon, 26 Sep 2005 20:14:45 -0700 MIME-Version: 1.0 Sent to CCL by: "Peter Spiro" [spiro^^renovis.com] --Replace strange characters with the "at" sign to recover email address--. This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C311.9C552BD8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, =20 Does anyone know examples of free or open source scientific software contributed by pharmaceutical companies?=20 =20 I ask because I'd like to contribute to certain open source projects, which my co-workers would be more comfortable with if they knew it was an acceptable practice in the pharma industry. (After all, the industry's livelihood depends on protecting IP, so giving something away can seem a bit strange to some, though they do understand the benefits of open source.) =20 Examples I know of directly from pharma are RasMol (GlaxoWellcome), JME molecular editor (Peter Ertl, Novartis; free though not open source), and Ertl et al.'s polar surface area code. Other open source examples I know of from cheminformatics companies include OELib and PyMOL. =20 Are there others? =20 Thanks! =20 Peter Spiro Renovis, Inc. =20 This email may contain material that is confidential and privileged and is for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ------_=_NextPart_001_01C5C311.9C552BD8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

Does anyone know examples of free or open source = scientific software contributed by pharmaceutical companies?

 

I ask because I'd like to contribute to certain open = source projects, which my co-workers would be more comfortable with if they = knew it was an acceptable practice in the pharma industry.  (After all, the industry's livelihood depends on protecting IP, so giving something away = can seem a bit strange to some, though they do understand the benefits of open = source.)

 

Examples I know of directly from pharma are RasMol = (GlaxoWellcome), JME molecular editor (Peter Ertl, Novartis; free though not open = source), and Ertl et al.'s polar surface area code.  Other open source examples I = know of > from cheminformatics companies include OELib and = PyMOL.

 

Are there others?

 

Thanks!

 

Peter Spiro

Renovis, Inc.

 


This email may contain material that is confidential and privileged and is for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

------_=_NextPart_001_01C5C311.9C552BD8-- From owner-chemistry@ccl.net Tue Sep 27 08:39:06 2005 From: "CCL" To: CCL Subject: CCL: Why is there (again) a religious war on FORTRAN vs C++ Message-Id: <-29320-050927061129-13383-h06UuI053JTxeZS6adJuFA+*+server.ccl.net> X-Original-From: Christoph van =?iso-8859-1?Q?W=FCllen?= Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Date: Tue, 27 Sep 2005 10:22:58 +0200 Mime-Version: 1.0 Sent to CCL by: Christoph van =?iso-8859-1?Q?W=FCllen?= [Christoph.vanWullen+*+TU-Berlin.De] --Replace strange characters with the "at" sign to recover email address--. Please, folks, no more religious wars on computer languages. You can build any project in any language, and I know many C++ enthousiasts which still program FORTRAN style (it is just the question of good and bad habits). +---------------------------------+----------------------------------+ | Prof. Christoph van Wüllen | Tele-Phone (+49) (0)30 314 27870 | | Technische Universität Sekr. C3 | Tele-Fax (+49) (0)30 314 23727 | | Straße des 17. Juni 135 | | | D-10623 Berlin, Germany | Christoph.vanWullen+*+TU-Berlin.De | | http://www.chemie.tu-berlin.de/vanwullen | +---------------------------------+----------------------------------+ -- From owner-chemistry@ccl.net Tue Sep 27 08:39:07 2005 From: "CCL" To: CCL Subject: CCL: W:CPMD or PWscf? Message-Id: <-29321-050927073357-25477-cPHtuNqf+Opiw+0j+Sy6nw~~server.ccl.net> X-Original-From: "Rudy Coquet" Sent to CCL by: "Rudy Coquet" [rcoquet_mailing~~fastmail.fm] --Replace strange characters with the "at" sign to recover email address--. Hello, I am going to study periodic systems such as zeolites (zsm-5) and metal oxide surfaces (alumina). I am (for the moment) not interested in doing any molecular dynamics. I am thinking of 2 codes: CPMD (Car-Parrinello MD) and PWscf (similar to abinit in a way). What would be your recommendation? I know CPMD can be turned into a damped second order dynamics scheme by adding a friction term. But is it then "as good as" a code like PWscf, abinit or VASP? I am also interested in transition states search. PWscf has the Nudged Elastic Band method implemented and CPMD can fix a bond length during optimisation, so I guess both could do the job? Then, I will have systems with around 250/300 atoms. I know CPMD can be "fast", what about PWscf? I also consider using SIESTA, but then it's localised basis sets and not planewaves anymore. If anybody has some experience with these 2 codes, used in surface science/physical chemistry, I would really appreciate your input. Thank you, Rudy Coquet JSPS fellow The University of Tokyo rcoquet_mailing~~fastmail.fm From owner-chemistry@ccl.net Tue Sep 27 08:39:11 2005 From: "CCL" To: CCL Subject: CCL: NMR calculation Message-Id: <-29323-050927081630-28589-Zo6vQ/OD0roRXh5/F8VeIQ:-:server.ccl.net> X-Original-From: Dhurairaj Senthilnathan Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Date: Tue, 27 Sep 2005 12:16:25 +0100 (BST) MIME-Version: 1.0 Sent to CCL by: Dhurairaj Senthilnathan [zenthil03:-:yahoo.co.in] --Replace strange characters with the "at" sign to recover email address--. dear sir, i wand to calculate NMR for organic moleculesin computationaly. which is the best theoretical way to calculate NMR for organic molecule. please replay me regards senthilnathan ________________________________________________________________________ Mr.D.SENTHILNATHAN , Research Scholar, School of Chemistry, Bharathidasan University, TIRUCHIRAPPALLI - 620 024, TamilNadu, INDIA Phone : + 91 431 2407053(office) + 94 437 81355 (Mobile) E-mail: zenthil03:-:yahoo.co.in chemthilchem:-:gmail.com __________________________________________________________ Yahoo! India Matrimony: Find your partner now. Go to http://yahoo.shaadi.com From owner-chemistry@ccl.net Tue Sep 27 10:07:42 2005 From: "CCL" To: CCL Subject: CCL: Why is there (again) a religious war on FORTRAN vs C++ Message-Id: <-29324-050927095055-12975-Sw5dK4FzV/WR+ShAlIIT1A===server.ccl.net> X-Original-From: John McKelvey Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Date: Tue, 27 Sep 2005 08:48:49 -0500 MIME-Version: 1.0 Sent to CCL by: John McKelvey [jmmckel===attglobal.net] --Replace strange characters with the "at" sign to recover email address--. All, I had no idea that my original question would generate all this discussion on fortran vs C/C++ and other languages... :-) The solution to my original quandry reflects some of the discussion. My colleague prefers C++ while I only usually program in fortran, and can hack a little in C. So to make things more efficient for both sides I stripped down my the most critical part of the fortran code to it's barest essentials to make the flow as obvious as possible, and thus to make the rewrite in C++ as easy and straight forward as possible for my colleague. Mission accomplished. Best regards, John McKelvey CCL wrote: > > Sent to CCL by: Christoph van =?iso-8859-1?Q?W=FCllen?= > [Christoph.vanWullen+*+TU-Berlin.De] > > --Replace strange characters with the "at" sign to recover email > address--. > > Please, folks, no more religious wars on computer languages. You can > build > any project in any language, and I know many C++ enthousiasts which still > program FORTRAN style (it is just the question of good and bad habits). > > +---------------------------------+----------------------------------+ > | Prof. Christoph van Wüllen | Tele-Phone (+49) (0)30 314 27870 | > | Technische Universität Sekr. C3 | Tele-Fax (+49) (0)30 314 23727 | > | Straße des 17. Juni 135 | | > | D-10623 Berlin, Germany | Christoph.vanWullen===TU-Berlin.De | > | http://www.chemie.tu-berlin.de/vanwullen | > +---------------------------------+----------------------------------+ > --> To send e-mail to subscribers of CCL put the string CCL: on your > Subject: line> > Send your subscription/unsubscription requests to: > CHEMISTRY-REQUEST===ccl.net HOME Page: http://www.ccl.net | Jobs Page: > http://www.ccl.net/jobs> > > > > From owner-chemistry@ccl.net Tue Sep 27 10:24:34 2005 From: "CCL" To: CCL Subject: CCL: Crystal Morphology Software Message-Id: <-29325-050927102212-16497-FkCz/tYjyjhwyw8TFGyrIg*o*server.ccl.net> X-Original-From: Aaron Deskins Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Date: Tue, 27 Sep 2005 09:22:07 -0500 MIME-Version: 1.0 Sent to CCL by: Aaron Deskins [ndeskins*o*purdue.edu] --Replace strange characters with the "at" sign to recover email address--. Hello fellow CCL'ers, I work on modelling surfaces using periodic DFT. I have been thinking of crystal morphology and its relationship to surface area stability. There is a recent paper (Journal of Catalysis 222(2004) 152-166) that calculates some crystal shapes and has some nice pictures of the work. The idea is that the crystal tends to minimize the overall surface energy, and that the Gibbs-Curie-Wulff law can tell you the crystal morphology. Unfortunately the details of finding the crystal shape are left out of the paper. Is there software (hopefully free) that can be used to calculate the crystal shape/morphology from the surface energy of different surfaces? I can calculate the surface energy using my DFT code, and it would be nice to know the relative frequency of the different surfaces based on the energy calculations. Thank you, Aaron Deskins Chemical Engineering Purdue University From owner-chemistry@ccl.net Tue Sep 27 10:46:48 2005 From: "CCL" To: CCL Subject: CCL: Open source contributions by pharma. Message-Id: <-29326-050927101647-30052-U8S5dE6NcecHXrJ3Sk0TsA-#-server.ccl.net> X-Original-From: Steve Bowlus Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Date: Tue, 27 Sep 2005 07:16:28 -0700 MIME-Version: 1.0 Sent to CCL by: Steve Bowlus [chezbowlus-#-goldrush.com] --Replace strange characters with the "at" sign to recover email address--. NEWLEAD (QCPE683) by Vincenzo Tschinko, also of Novartis. I'm sure there are other industry-source programs at QCPE (I did a couple of ports, but not original programming while at Novartis Agro.) Many SPL scripts for Sybyl were developed/contributed by people in industry. Perhaps not "open source" in the usual sense, but SPL lends itself to reuse/translation into other languages. sb CCL wrote: > Hello all, > > > > Does anyone know examples of free or open source scientific software > contributed by pharmaceutical companies? > > > > I ask because I'd like to contribute to certain open source projects, > which my co-workers would be more comfortable with if they knew it was > an acceptable practice in the pharma industry. (After all, the > industry's livelihood depends on protecting IP, so giving something away > can seem a bit strange to some, though they do understand the benefits > of open source.) > > > > Examples I know of directly from pharma are RasMol (GlaxoWellcome), JME > molecular editor (Peter Ertl, Novartis; free though not open source), > and Ertl et al.'s polar surface area code. Other open source examples I > know of > from cheminformatics companies include OELib and PyMOL. > > > > Are there others? > > > > Thanks! > > > > Peter Spiro > > Renovis, Inc. > > > > > > ------------------------------------------------------------------------ > This email may contain material that is confidential and > privileged and is for the sole use of the intended recipient. > Any review, reliance or distribution by others or forwarding > without express permission is strictly prohibited. If you are > not the intended recipient, please contact the sender and > delete all copies. > ------------------------------------------------------------------------ > From owner-chemistry@ccl.net Tue Sep 27 12:13:27 2005 From: "CCL" To: CCL Subject: CCL: W:ESFF force field parameters Message-Id: <-29327-050927121131-21881-uA6x8AHIyhTggIoGkQQnkA-.-server.ccl.net> X-Original-From: "Gustavo A Mercier" Sent to CCL by: "Gustavo A Mercier" [gamercier-.-yahoo.com] --Replace strange characters with the "at" sign to recover email address--. Hi! I am curious about the experience with the ESFF force field: Shi et al. J. Comput. Chem. 24: 1059-1076, 2003 Looks like a pretty "general" force field that may perform better than UFF. I am thinking about implementing this force field into MMTK, although I recognize that this will be a long term project that is likely to be more than I can handle at this time... ;-) However, my concern is that this paper list in reference 15 "Atom type definition and parameters are listed in supplementary materials." There is no reference to this material in the JCC web site and a google search only found a listing of atom types that may come from Accelrys software that implements ESFF. The Accelrys site does not have the supplementary material either. Does anyone know the whereabouts of this supplementary material? Thanks! Gustavo Mercier, MD,PhD gamercier-.-yahoo.com gustavom-.-baylorhealth.edu BUMC From owner-chemistry@ccl.net Tue Sep 27 13:22:11 2005 From: "CCL" To: CCL Subject: CCL: Open source contributions by pharma Message-Id: <-29330-050927123112-2912-CHX/7O48sygNDgN7PGo5Bg|*|server.ccl.net> X-Original-From: "Boyd, D." Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Sep 2005 10:30:48 -0600 MIME-Version: 1.0 Sent to CCL by: "Boyd, D." [boyd|*|chem.iupui.edu] --Replace strange characters with the "at" sign to recover email address--. Merck contributed programs to the Quantum Chemistry Program Exchange back in the 1970s and 1980s. Lilly and Abbott also made some programs available. Check out http://qcpe.chem.indiana.edu/. These companies contributed source code for 20 or so programs. Don Donald B. Boyd, Ph.D. Research Professor of Chemistry Department of Chemistry Indiana University-Purdue University at Indianapolis 402 North Blackford Street Indianapolis, Indiana 46202-3274, U.S.A. Tel. 317-274-6891, Fax 317-274-4701 E-mail boyd|*|chem.iupui.edu Website http://chem.iupui.edu/faculty/boyd.html From owner-chemistry@ccl.net Tue Sep 27 13:08:29 2005 From: "CCL" To: CCL Subject: CCL: Open source contributions by pharma. Message-Id: <-29328-050927130554-12257-5tHrVfTFXE04V4vaWBcYyQ[-]server.ccl.net> X-Original-From: Hans Martin Senn Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Date: Tue, 27 Sep 2005 18:30:32 +0200 Mime-Version: 1.0 (Apple Message framework v734) Sent to CCL by: Hans Martin Senn [senn[-]mpi-muelheim.mpg.de] --Replace strange characters with the "at" sign to recover email address--. Hi all Not open source, but free for academic users: Paul Gerber's Moloc (http://www.moloc.ch), initially started at Roche. Cheers Hans On 27 Sep 2005, at 05:14, CCL wrote: > Hello all, > > Does anyone know examples of free or open source scientific > software contributed by pharmaceutical companies? > > Peter Spiro > > Renovis, Inc. ........................................................................ . Dr. Hans Martin Senn Max-Planck-Institut für Kohlenforschung Kaiser-Wilhelm-Platz 1 Phone +49 (0)208 306 2163 D-45470 Mülheim an der Ruhr Fax +49 (0)208 306 2996 Germany E-mail senn[-]mpi- muelheim.mpg.de From owner-chemistry@ccl.net Tue Sep 27 13:22:11 2005 From: "CCL" To: CCL Subject: CCL: Crystal Morphology Software Message-Id: <-29329-050927131116-13559-Xz6VXRcPom54T6vxWSY95g ~~ server.ccl.net> X-Original-From: TOULHOAT Herve Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 27 Sep 2005 17:43:43 +0200 MIME-Version: 1.0 Sent to CCL by: TOULHOAT Herve [Herve.TOULHOAT ~~ ifp.fr] --Replace strange characters with the "at" sign to recover email address--. Dear Aaron, In that paper, we have used the Morphology module within Cerius 2 of Accelrys. This type of module can be also found in Materials Studio from the same company. Once you have the surface energies by DFT, and using the Gibbs-Curie-Wulff law, I believe you could easily build nice shapes using a free software like POV-Ray (http://www.povray.org/). You could even design any environment to these shapes. Yours Sincerely, Prof. Hervé Toulhoat (Computational Chemistry and Catalysis) Deputy Scientific Director Director of Doctoral Studies Institut Français du Pétrole Tel +33 1 47 52 73 50 Fax +33 1 47 52 70 36 e-mail: herve.toulhoat ~~ ifp.fr Visit IFP web site: http://www.ifp.fr If you are interested in Catalysis, Visit also: http://gdrdmq.ifp.fr READICATS : Research Advances in Rational Design of Catalysts and Sorbents 14-16 December 2005 IFP-Lyon http://events.ifp.fr -----Message d'origine----- De : CCL [mailto:owner-chemistry ~~ ccl.net] Envoyé : mardi 27 septembre 2005 16:22 À : TOULHOAT Herve Objet : CCL: Crystal Morphology Software Sent to CCL by: Aaron Deskins [ndeskins*o*purdue.edu] --Replace strange characters with the "at" sign to recover email address--. Hello fellow CCL'ers, I work on modelling surfaces using periodic DFT. I have been thinking of crystal morphology and its relationship to surface area stability. There is a recent paper (Journal of Catalysis 222(2004) 152-166) that calculates some crystal shapes and has some nice pictures of the work. The idea is that the crystal tends to minimize the overall surface energy, and that the Gibbs-Curie-Wulff law can tell you the crystal morphology. Unfortunately the details of finding the crystal shape are left out of the paper. Is there software (hopefully free) that can be used to calculate the crystal shape/morphology from the surface energy of different surfaces? I can calculate the surface energy using my DFT code, and it would be nice to know the relative frequency of the different surfaces based on the energy calculations. Thank you, Aaron Deskins Chemical Engineering Purdue University__________________________ Ce message (et toutes ses pièces jointes éventuelles) est confidentiel et établi à l'intention exclusive de ses destinataires. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'IFP décline toute responsabilité au titre de ce message. This message and any attachments (the message) are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. IFP should not be liable for this message. Visitez notre site Web / Visit our web site : http://www.ifp.fr __________________________ From owner-chemistry@ccl.net Tue Sep 27 14:08:19 2005 From: "CCL" To: CCL Subject: CCL: W:ESFF force field parameters Message-Id: <-29331-050927134446-21555-IG5AUtvKmGvPVqouAsGBcw%a%server.ccl.net> X-Original-From: Jeff Nauss Content-Type: multipart/alternative; boundary="=_alternative 006178EE88257089_=" Date: Tue, 27 Sep 2005 10:44:40 -0700 MIME-Version: 1.0 Sent to CCL by: Jeff Nauss [jnauss%a%accelrys.com] --Replace strange characters with the "at" sign to recover email address--. This is a multipart message in MIME format. --=_alternative 006178EE88257089_= Content-Type: text/plain; charset="US-ASCII" owner-chemistry%a%ccl.net wrote on 09/27/2005 09:21:52 AM: > Sent to CCL by: "Gustavo A Mercier" [gamercier-.-yahoo.com] > --Replace strange characters with the "at" sign to recover email address--. > > Looks like a pretty "general" force field that may perform better > than UFF. I am thinking about implementing this force field into > MMTK, although I recognize that this will be a long term project > that is likely to be more than I can handle at this time... ;-) > > However, my concern is that this paper list in reference 15 > > "Atom type definition and parameters are listed in supplementary materials." > > There is no reference to this material in the JCC web site and a > google search only found a listing of atom types that may come from > Accelrys software that implements ESFF. The Accelrys site does not > have the supplementary material either. > > Does anyone know the whereabouts of this supplementary material? I believe the supplemental material to which you are referring is Appendix B, Forcefield Terms and Atom Types, in the "Forcefield-Based Simulations" documentation (URL http://www.accelrys.com/doc/life/insight2005/ffbs/FF_SimulTOC.html). Jeff -- Jeffrey L. Nauss, Ph.D. Lead Training Scientist Accelrys 10188 Telesis Court, Suite 100 San Diego, CA 92121-4779 Phone: +1-858-799-5555 Fax: +1-858-799-5100 http://www.accelrys.com/training *AccelrysWorld 2005, London, Nov 14-16. http://www.accelrysworld.com* --=_alternative 006178EE88257089_= Content-Type: text/html; charset="US-ASCII"
owner-chemistry%a%ccl.net wrote on 09/27/2005 09:21:52 AM:

> Sent to CCL by: "Gustavo A Mercier" [gamercier-.-yahoo.com]
> --Replace strange characters with the "at" sign to recover email address--.
>
> Looks like a pretty "general" force field that may perform better
> than UFF. I am thinking about implementing this force field into
> MMTK, although I recognize that this will be a long term project
> that is likely to be more than I can handle at this time... ;-)
>
> However, my concern is that this paper list in reference 15
>
> "Atom type definition and parameters are listed in supplementary materials."
>
> There is no reference to this material in the JCC web site and a
> google search only found a listing of atom types that may come from
> Accelrys software that implements ESFF. The Accelrys site does not
> have the supplementary material either.
>
> Does anyone know the whereabouts of this supplementary material?

I believe the supplemental material to which you are referring is Appendix B, Forcefield Terms and Atom Types, in the "Forcefield-Based Simulations" documentation (URL http://www.accelrys.com/doc/life/insight2005/ffbs/FF_SimulTOC.html).

Jeff
--
Jeffrey L. Nauss, Ph.D.
Lead Training Scientist
Accelrys
10188 Telesis Court, Suite 100
San Diego, CA 92121-4779

Phone: +1-858-799-5555
Fax: +1-858-799-5100
http://www.accelrys.com/training

*AccelrysWorld 2005, London, Nov 14-16. http://www.accelrysworld.com*

--=_alternative 006178EE88257089_=-- From owner-chemistry@ccl.net Tue Sep 27 16:08:59 2005 From: "CCL" To: CCL Subject: CCL: W:ESFF force field parameters Message-Id: <-29332-050927160820-12347-AA+PzJeLLvMgYVhXJU78SQ-,-server.ccl.net> X-Original-From: Jeff Nauss Content-Type: multipart/alternative; boundary="=_alternative 006E9CB188257089_=" Date: Tue, 27 Sep 2005 13:08:11 -0700 MIME-Version: 1.0 Sent to CCL by: Jeff Nauss [jnauss-,-accelrys.com] --Replace strange characters with the "at" sign to recover email address--. This is a multipart message in MIME format. --=_alternative 006E9CB188257089_= Content-Type: text/plain; charset="US-ASCII" owner-chemistry-,-ccl.net wrote on 09/27/2005 10:44:40 AM: > owner-chemistry-,-ccl.net wrote on 09/27/2005 09:21:52 AM: > > > Sent to CCL by: "Gustavo A Mercier" [gamercier-.-yahoo.com] > > --Replace strange characters with the "at" sign to recover email address--. > > > > Looks like a pretty "general" force field that may perform better > > than UFF. I am thinking about implementing this force field into > > MMTK, although I recognize that this will be a long term project > > that is likely to be more than I can handle at this time... ;-) > > > > However, my concern is that this paper list in reference 15 > > > > "Atom type definition and parameters are listed in supplementary materials." > > > > There is no reference to this material in the JCC web site and a > > google search only found a listing of atom types that may come from > > Accelrys software that implements ESFF. The Accelrys site does not > > have the supplementary material either. > > > > Does anyone know the whereabouts of this supplementary material? > > I believe the supplemental material to which you are referring is > Appendix B, Forcefield Terms and Atom Types, in the "Forcefield- > Based Simulations" documentation (URL http://www.accelrys. > com/doc/life/insight2005/ffbs/FF_SimulTOC.html). My apologies, I misread the request. The information given in the documentation are merely the atom types and not the parameters themselves. If you contact the authors Lisa Yan or Jodi Shaulsky, I believe they could provide the information. Jeff -- Jeffrey L. Nauss, Ph.D. Lead Training Scientist Accelrys 10188 Telesis Court, Suite 100 San Diego, CA 92121-4779 Phone: +1-858-799-5555 Fax: +1-858-799-5100 http://www.accelrys.com/training *AccelrysWorld 2005, London, Nov 14-16. http://www.accelrysworld.com* --=_alternative 006E9CB188257089_= Content-Type: text/html; charset="US-ASCII"
owner-chemistry-,-ccl.net wrote on 09/27/2005 10:44:40 AM:
> owner-chemistry-,-ccl.net wrote on 09/27/2005 09:21:52 AM:
>
> > Sent to CCL by: "Gustavo A Mercier" [gamercier-.-yahoo.com]
> > --Replace strange characters with the "at" sign to recover email address--.
> >
> > Looks like a pretty "general" force field that may perform better
> > than UFF. I am thinking about implementing this force field into
> > MMTK, although I recognize that this will be a long term project
> > that is likely to be more than I can handle at this time... ;-)
> >
> > However, my concern is that this paper list in reference 15
> >
> > "Atom type definition and parameters are listed in supplementary materials."
> >
> > There is no reference to this material in the JCC web site and a
> > google search only found a listing of atom types that may come > from
> > Accelrys software that implements ESFF. The Accelrys site does not
> > have the supplementary material either.
> >
> > Does anyone know the whereabouts of this supplementary material?
>
> I believe the supplemental material to which you are referring is
> Appendix B, Forcefield Terms and Atom Types, in the "Forcefield-
> Based Simulations" documentation (URL http://www.accelrys.
> com/doc/life/insight2005/ffbs/FF_SimulTOC.html).

My apologies, I misread the request.  The information given in the documentation are merely the atom types and not the parameters themselves.  If you contact the authors Lisa Yan or Jodi Shaulsky, I believe they could provide the information.

Jeff
--
Jeffrey L. Nauss, Ph.D.
Lead Training Scientist
Accelrys
10188 Telesis Court, Suite 100
San Diego, CA 92121-4779

Phone: +1-858-799-5555
Fax: +1-858-799-5100
http://www.accelrys.com/training

*AccelrysWorld 2005, London, Nov 14-16. http://www.accelrysworld.com*
--=_alternative 006E9CB188257089_=-- From owner-chemistry@ccl.net Tue Sep 27 18:24:36 2005 From: "CCL" To: CCL Subject: CCL: About compiling Gaussian98 Message-Id: <-29333-050927181529-4696-wToFffOt4I6qjERhGllbAg[]server.ccl.net> X-Original-From: "Perry E. Metzger" Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Sep 2005 18:15:26 -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--. > I was trying to compile g98A11.2 on a linux machine(i386). I used > several compilers including g77, ifort, and pgf77. But none of them > working. Until it started to compile g98, it had error message as > shown below. > > g98/gau-cpp -Ig98 -Ig98s -DGAUSS_PAR -DGAUSS_THPAR -DDEFMAXSHL=20000 -DDEFMAXATM=20000 -DDEFMAXNZ=20000 -DDEFNVDIM=257 -DDEFARCREC=1024 -DMERGE_LOOPS -DUSE_ESSL -D_I386_ -DLITTLE_END -DUSING_F2C -DDEFMAXIOP=100 -DDEFMAXCHR=1024 -DDEFLMAX=13 -DDEFN3MIN=10 -DDEFMAXHEV=2000 -DDEFCACHE=64 -DDEFMAXLECP=10 -DDEFMAXFUNIT=5 -DDEFMAXFFILE=10000 -DDEFMAXFPS=1300 -DDEFMAXINFO=200 -DDEFMAXOP=120 -DDEFMAXTIT=100 -DDEFMAXRTE=4000 -DDEFMAXOV=500 -D_ALIGN_CORE_ -DCA1_DGEMM -DCA2_DGEMM -DCAB_DGEMM -DLV_DSP -DO_BKSPEF -DDEFMXTS=1500 -DDEFMXBAS=500 -DDEFMXOPT=50 -DDEFMXBOND=12 -DDEFMXSPH=250 -DDEFMXINV=1500 ml0.F ml0.f > ifort -g -O2 -c ml0.f > make[1]: Leaving directory `g98' > ifort -g -O2 -o g98 ml0.o util.so Here, you are attempting to link the program g98, which consists of the objects "ml0.o" and "util.so". "util.so" is a shared object library built earlier in your compile. > util.so: the use of `tmpnam' is dangerous, better use `mkstemp' The linker is complaining that util.so uses the "tmpnam" function, which is indeed dangerous (but you can ignore that.) > util.so: undefined reference to `__ctype_b' > util.so: undefined reference to `wait_' > util.so: undefined reference to `fork_' Your linker is complaining that several external functions that util.so is expecting are (for some reason) missing. > make: *** [g98] Error 1 > endif > > Can any expert tell me how I should go with this? > Thank you very much in advance! The issue here isn't your Fortran code -- it is probably your link line or the way util.so gets built. The next step for you is to examine what goes into util.so and figure out why it is missing those things. I'll note that the names of those references are suspiciously similar to several basic system calls (wait and fork). Perry From owner-chemistry@ccl.net Tue Sep 27 18:26:52 2005 From: "CCL" To: CCL Subject: CCL: [CCL]: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29334-050927172124-31995-W0q2WdzHLyJvxnhzMYTRRA*|*server.ccl.net> X-Original-From: "Perry E. Metzger" Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Sep 2005 17:21:17 -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--. > It's always discouraging to observe the type of 'language snobbery' that has > been posted on the list the last few days. It isn't snobbery. I've just been mentioning that if you're still using Fortran, you're operating with a hand tied behind your back. If you choose not to believe me, that's fine. It is, however, true. > At the end of the day, it's the preference of the researcher, their facility > with their tools, and the timely attainment of results that is important, > not the type of language, the sex of the person, their height, weight, > width, skin color, or religion. Programming languages are not all created equal. This isn't like saying "there is no effective difference between preferring a blue chair and a red chair". This is like deciding to use an axe vs. a chainsaw. Lets say you were trying to hire a lumberjack. Two applicants arrived. One says "I'm happy with using an axe and using a mule for hauling the logs out. We've done it that way for hundreds of years and it is good enough for me". The other is familiar with how to use a chainsaw, and has no trouble with using modern equipment for removing the cut logs. Would you say "eh, it makes no difference", or would you note that one is likely to be twenty or thirty times more productive and leave the dinosaur on the unemployment line? > The language police should just do their research and stop trying to impose > their will on the rest of the community. I'm not the "language police". I'm a trained computer scientist so I happen to have a bit of perspective you don't, and I chose to share it with you. Keep using Fortran forever if you choose, I don't care. It won't harm me. > If their approach is shown to be demonstrably superior to the rest > of the community, it will be adopted. If not, then it won't. I think we passed the point where Fortran was obsolete around 1970 or so, and yet, individuals like yourself have ignored that evidence since then. Well, go on. No one will stop you. On the other hand, you'll write code much more slowly, it will run much more slowly, and there will be ideas you just can't express, but if that is how you choose to live, fine with me. Perry From owner-chemistry@ccl.net Tue Sep 27 18:31:12 2005 From: "CCL" To: CCL Subject: CCL: [CCL]: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29335-050927174313-2627-S1SbO4EjdgPsVEy21bI3pw.@.server.ccl.net> X-Original-From: "Perry E. Metzger" Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Sep 2005 17:43:10 -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--. > Is English the better language? > No. > Why Esperanto is not used? It should be easier to learn. > But english is the international language. The fallacy here is that the choice of programming language makes no difference in what you can express. I can say the same things in Spanish and French, so there is no particular reason to recommend one over the other. On the other hand, this is simply not true in programming languages. There are ideas I can express in C that I simply cannot express in Fortran. For example, in C I can define a structure containing pointers to functions. I can then treat such a structure as an opaque representation for an entity, and have many different entities behave differently by storing different function pointers inside them, with a generic function that processes entities invoking the appropriate function by its pointer when needed. Now, Fortran and C are both Turing Equivalent, so I could do the same in Fortran by a heroic act that is the moral equivalent of writing a virtual machine interpreter in Fortran and then executing code in the VM, but in practice that is not something anyone can do. The truth is, C lets you do things you just can't even think about in Fortran. I've ignored everyday things you just can't do in Fortran 77. Can I build a set of structures interconnected by pointers to abstractly represent the partitioning of a group of objects in space to increase the efficiency of a calculation to intersect those objects? No, I can't. I can't even start to express the algorithm without heroic efforts. Sure, there is no real reason why a tight loop multiplying two matrices represented as arrays will be any faster in C or Fortran, but if you are smart you can avoid having to multiply as many matrices, and it is harder to be smart in Fortran than in C. *That* is the difference between a non-expressive language and an expressive one. Lisp goes even further -- I can write functions that operate on functions in Lisp, constructing new functions and returning them as the value of other functions, and then applying these functions to yet other pieces of data (which could be functions). You can't do that in C, of course, but you can't even remotely imagine it in Fortran-land. Human languages are all essentially equivalent, but programming languages are *not* equivalent except in the raw sense of Turing Equivalence. This is not surprising. All mechanisms for cutting a tree down are "equivalent" -- a sharp spoon, a stone axe, and a high speed gasoline powered chainsaw are all "equivalent" in some sense. However, you would be an idiot, if you are a professional and trying to cut down a lot of trees, to use a sharp spoon. If you are a restaurant owner and say to your chef "why do you need this expensive Sous Vide system? Why can't you use a Bunsen burner", your chef will laugh at you and then quit. Those of you who think "bah, I know programming, Fortran is just as good as anything else -- all languages are equivalent" are kidding yourselves. Computer Science is no less complicated to learn than Chemistry. If your job really is the intersection of Chemistry and Computer Science, you are not doing yourself a favor by pretending that one part is more important than the other. If you do not understand why all languages are not equivalent, you have neglected part of your profession. Perry From owner-chemistry@ccl.net Tue Sep 27 18:32:31 2005 From: "CCL" To: CCL Subject: CCL: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29336-050927174537-2856-8uvwtQyoolytcVgiM9JNvQ-*-server.ccl.net> X-Original-From: "Perry E. Metzger" Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Sep 2005 17:45:35 -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--. > Sent to CCL by: "TJ O'Donnell" [tjo{:}acm.org] > > Here's the full quote, and a reference. > > I don't know what the language of the year 2000 will look like, > but I know it will be called Fortran. (C A R Hoare, 1982) > http://www.sysprog.net/quothist.html For those that do not know, Tony Hoare was making fun of the Fortran users here, not praising them. Perry From owner-chemistry@ccl.net Tue Sep 27 18:34:56 2005 From: "CCL" To: CCL Subject: CCL: W:CCL: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29337-050927180920-4220-WAUbu9zgoAufRqDIP+UCOg|-|server.ccl.net> X-Original-From: "Perry E. Metzger" Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Sep 2005 18:09:17 -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--. "CCL" writes: >> Believe it or not, I'd actually say that Lisp is a pretty good choice, >> especially the implementations with very good compilers for numerical >> work like CMUCL, SBCL, and various commercial compilers like Allegro >> Common Lisp. Lisp is very alien to non-computer science types, and > > Fine, but are those compilers quickly available for new > architectures? Few computational scientists > would want to limit their code to x86 architectures. Yes. However, I am sad to say that at this point, only x86 and 64 bit extended x86 make any difference. I hate the x86 architecture with a burning passion beyond my ability to express, but the war is over. The last holdout is PowerPC and it is falling behind on the speed curve and it is going to fall behind further now that Motorola has spun out their chip business and IBM has decided that it isn't worth their time keeping up. None the less, if you want a decent lisp compiler for PowerPC or other architectures they are available. >> However, many computational chemists try to "go cheap" on learning >> about their tools and picking good ones. That means the difference > > Indeed. > >> Yup, but if you know what you're doing it pays a dividend in the >> end. There are algorithms you just can't express in Fortran cleanly. I > > I agree, but this is very hard to see if all you have ever used is Fortran. Indeed. Trying to explain a lisp macro that produces an anonymous closure to a Fortran programmer is like trying to explain a power backup system for a cellphone tower to a cave man. There are many basic concepts like "electricity", "telephone", "radio", "phone company", "blackout" all standing in the way. >> In any case, I can't imagine writing most software without real data >> structures. If you don't know why you want to be able to build clean >> hash tables, priority queues, search trees, etc., then you don't know > > That's a nice illustration of the difficulties - I doubt many > computational scientists know much about any of these data structures. And those are the simple things. What happens when you have an algorithm that would save you a lot of compute time but it involves a complicated data structure to represent some abstract space over your entities? I don't even know how to do that sort of thing without the fundamentals of data structures and their associated algorithms firmly implanted in your head. Perry From owner-chemistry@ccl.net Tue Sep 27 20:46:14 2005 From: "CCL" To: CCL Subject: CCL: W:CPMD or PWscf? Message-Id: <-29338-050927145822-1733-f7WBaqZVmoUfBgrx3V2Zkw---server.ccl.net> X-Original-From: heather kulik Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Date: Tue, 27 Sep 2005 10:58:18 -0700 (PDT) MIME-Version: 1.0 Sent to CCL by: heather kulik [heddddr---yahoo.com] --Replace strange characters with the "at" sign to recover email address--. Hi- As a user of CP and PWscf, I thought I'd offer some advice, however as a relatively new graduate student I 'm sure that there are people more informed than I-I'd recommend also reading/writing to the PWscf forum http://www.pwscf.org, since the users there use many solid-state codes like VASP and Ab-init as well and typically provide useful advice. The performance of these solid state codes is highly variable upon several important factors- 1) pseudopotentials - like a RECP, there are many flavors of these and results also depend upon them. PWscf has several pseudopotentials available on its site for each element. Norm-conserving and ultrasoft are two distinctions - the latter being less costly but also less accurate if one is interested in describing at all core-dependent phenomena. PWscf and its own Car-Parrinello molecular dynamics code (which is also free and open source) support both NC pseudopotentials and US pseudopotentials. There is some transferrability between the two codes and I think that permits one to easily compare for a given system whether a SCF or CP code is better suited for calculations. 2) cutoff - these codes obviously use plane waves and the costliness of the calculation is highly dependent upon the number of plane waves required to accurately describe what you'd like to. While higher cutoffs are needed to describe a norm-conserving core, the use of USPP permits cutoffs as low as 20-25 rydbergs, depending upon the element involved. In general, it is viewed in our group - I work for Nicola Marzari - that for large scale simulations the car-parrinello code is more efficient than PWscf. My own experience with PWscf on large systems has involved upwards of 330 atoms - and I managed with that code and norm-conserving pseudopotentials (85 Ry cutoff) to take about 2-4 hrs on 60 processors to complete a single-point energy calculation. I hope some of this was helpful, Heather Kulik hjkulik-at-mit-dot-edu --- CCL wrote: > > Sent to CCL by: "Rudy Coquet" > [rcoquet_mailing~~fastmail.fm] > > --Replace strange characters with the "at" sign to > recover email address--. > > Hello, > > I am going to study periodic systems such as > zeolites (zsm-5) and metal oxide surfaces (alumina). > I am (for the moment) not interested in doing any > molecular dynamics. I am thinking of 2 codes: CPMD > (Car-Parrinello MD) and PWscf (similar to abinit in > a way). > > What would be your recommendation? I know CPMD can > be turned into a damped second order dynamics scheme > by adding a friction term. But is it then "as good > as" a code like PWscf, abinit or VASP? > I am also interested in transition states search. > PWscf has the Nudged Elastic Band method implemented > and CPMD can fix a bond length during optimisation, > so I guess both could do the job? > Then, I will have systems with around 250/300 atoms. > I know CPMD can be "fast", what about PWscf? I also > consider using SIESTA, but then it's localised basis > sets and not planewaves anymore. > > If anybody has some experience with these 2 codes, > used in surface science/physical chemistry, I would > really appreciate your input. > > Thank you, > > Rudy Coquet > JSPS fellow > The University of Tokyo > rcoquet_mailing---fastmail.fm > > > > -= This is automatically added to each message by > the mailing script =- > To send e-mail to subscribers of CCL put the string > CCL: on your Subject: line> > Send your subscription/unsubscription requests to: > CHEMISTRY-REQUEST---ccl.net > HOME Page: http://www.ccl.net | Jobs Page: > http://www.ccl.net/jobs > > If your is mail bouncing from ccl.net domain due to > spam filters, please> > > > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From owner-chemistry@ccl.net Tue Sep 27 22:04:57 2005 From: "CCL" To: CCL Subject: CCL: [CCL]: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29339-050927220345-31788-p1QPwjrIrL314PrmQgs/GA---server.ccl.net> X-Original-From: "Robert Duke" Content-Transfer-Encoding: 7bit Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Date: Tue, 27 Sep 2005 22:03:33 -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--. Okay folks, my apologies to everyone who is getting tired of this thread, myself included, but I think people are really throwing arguments past each other, and missing a few points: 1) When Perry says Fortran, as near as I can tell he really means f77 or earlier versions of fortran. It is to my mind completely disingenuous to say "fortran", referring to the capabilities of these versions of the language, and completely ignore the fact that the fortran language has evolved to a significant extent, and can now come very close to C's ability to handle more sophisticated data structures and algorithms. This is like referring to the capabilities of B, and calling it C. 2) I concur that f90/95 lacks any real object implementation and cannot easily do a number of things that C++ can do; as for lisp, I last dealt with it over 20 years ago, and while I think it is conceptually "way cool", I have not seen a big stampede to implement systems using it for a whole bunch of reasons. I do miss the capabilities of C++ when I program in f90/95, but life is a series of tradeoffs, and if I have to deal with code written by folks who have not spent enough time writing C++, I would rather that they use f90/95, which allows them to write decently structured code with less of a learning curve than C or C++. Just my personal preference, based primarily on three things: a) I have seen incredible mayhem associated with folks writing C or C++ without knowing what they are doing. True, you can get incredible mayhem with bad fortran too, but the learning curve required to really know how to use C or C++ is much steeper, and therefore the probability that the code writer will not have a full grasp of the opportunities and pitfalls offered by the language are greater. Folks deciding to rewrite everything in C or C++ because that is what our computer science departments have recently been teaching and because it is "cool" should be aware of the pitfalls as well as the benefits, and that there are less risky alternatives for some classes of code. b) Sorry, but at least in my experience, f90/95 does a better job dealing with a variety of mathematical issues, with arrays as a really important, if unsatisfyingly simple, data structure (including DYNAMIC multidimensional arrays with decent indexing), and with number crunching performance issues. This may partly reflect the fact that I mostly did systems work with C and C++, so I really never stretched hard to learn all the ins and outs of the mathematical features of the language, but I think I am being reasonably objective in preferring fortran for numerical work. c) There is a smooth migration path from the tons of old f77 code to better code using f90/95. You can choose to make improvements to whatever extent you need, desire, or can afford. If you choose to go the C/C++ route, fine, but just be sure you really understand the tools, and plan on spending perhaps more time than you really have to spare on gaining proficiency. And don't think for a minute that somebody who took one course and has never been in the trenches is going to immediately be a great trailblazer. I would definitely pick it for serious systems work, but that is not what I am currently doing. I also understand folks wanting to work in C/C++ because the probability of finding generic programming work with this skill set is higher; but I presume the average computational chemist is not looking for a generic programming job. Regards - Bob Duke (unless I get unfairly assaulted, I'm done - honest) ----- Original Message ----- > From: "CCL" To: "Duke, Robert E " Sent: Tuesday, September 27, 2005 5:43 PM Subject: CCL: [CCL]: Cleaning up dusty deck fortran and converting to C/C++ > > Sent to CCL by: "Perry E. Metzger" [perry.---.piermont.com] > > --Replace strange characters with the "at" sign to recover email > address--. > > >> Is English the better language? >> No. >> Why Esperanto is not used? It should be easier to learn. >> But english is the international language. > > The fallacy here is that the choice of programming language makes no > difference in what you can express. I can say the same things in > Spanish and French, so there is no particular reason to recommend one > over the other. > > On the other hand, this is simply not true in programming > languages. There are ideas I can express in C that I simply cannot > express in Fortran. For example, in C I can define a structure > containing pointers to functions. I can then treat such a structure as > an opaque representation for an entity, and have many different > entities behave differently by storing different function pointers > inside them, with a generic function that processes entities invoking > the appropriate function by its pointer when needed. > > Now, Fortran and C are both Turing Equivalent, so I could do the same > in Fortran by a heroic act that is the moral equivalent of writing a > virtual machine interpreter in Fortran and then executing code in the > VM, but in practice that is not something anyone can do. The truth is, > C lets you do things you just can't even think about in Fortran. > > I've ignored everyday things you just can't do in Fortran 77. Can I > build a set of structures interconnected by pointers to abstractly > represent the partitioning of a group of objects in space to increase > the efficiency of a calculation to intersect those objects? No, I > can't. I can't even start to express the algorithm without heroic > efforts. Sure, there is no real reason why a tight loop multiplying > two matrices represented as arrays will be any faster in C or Fortran, > but if you are smart you can avoid having to multiply as many > matrices, and it is harder to be smart in Fortran than in C. *That* is > the difference between a non-expressive language and an expressive > one. > > Lisp goes even further -- I can write functions that operate on > functions in Lisp, constructing new functions and returning them as > the value of other functions, and then applying these functions to yet > other pieces of data (which could be functions). You can't do that in > C, of course, but you can't even remotely imagine it in Fortran-land. > > Human languages are all essentially equivalent, but programming > languages are *not* equivalent except in the raw sense of Turing > Equivalence. This is not surprising. All mechanisms for cutting a tree > down are "equivalent" -- a sharp spoon, a stone axe, and a high speed > gasoline powered chainsaw are all "equivalent" in some sense. However, > you would be an idiot, if you are a professional and trying to cut > down a lot of trees, to use a sharp spoon. If you are a restaurant > owner and say to your chef "why do you need this expensive Sous Vide > system? Why can't you use a Bunsen burner", your chef will laugh at > you and then quit. > > Those of you who think "bah, I know programming, Fortran is just as > good as anything else -- all languages are equivalent" are kidding > yourselves. > > Computer Science is no less complicated to learn than Chemistry. If > your job really is the intersection of Chemistry and Computer Science, > you are not doing yourself a favor by pretending that one part is more > important than the other. If you do not understand why all languages > are not equivalent, you have neglected part of your profession. > > Perry> To send e-mail to subscribers of CCL put the string CCL: on your Subject: > line> > Send your subscription/unsubscription requests to: > CHEMISTRY-REQUEST---ccl.net> > > > From owner-chemistry@ccl.net Tue Sep 27 22:17:41 2005 From: "CCL" To: CCL Subject: CCL: input structure creation/editing Message-Id: <-29340-050927213703-29859-Ee3Eb2qxdqCSTljcR9HGDQ]^[server.ccl.net> X-Original-From: Geoffrey Hutchison Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Date: Tue, 27 Sep 2005 21:36:52 -0400 Mime-Version: 1.0 (Apple Message framework v734) Sent to CCL by: Geoffrey Hutchison [grh25]^[cornell.edu] --Replace strange characters with the "at" sign to recover email address--. Sorry for the late reply on this message. I'm not sure why the writer thinks that Ghemical has stopped development. The program is under active development by a number of groups, including GAMESS-US integration. The most recent version of ghemical 1.90 was released on 2005-07-01. http://www.uiowa.edu/~ghemical/ http://www.uku.fi/~thassine/ghemical/ There are a number of other molecular editor programs, some under various stages of development. Gabedit http://lasim.univ-lyon1.fr/allouche/gabedit/ GDIS (better for periodic structures) http://gdis.sourceforge.net/ GAMGI http://www.gamgi.org/ Cheers, -Geoff -- -Dr. Geoffrey Hutchison Cornell University, Department of Chemistry and Chemical Biology Abruña Group http://abruna.chem.cornell.edu/ On Sep 21, 2005, at 12:12 PM, CCL wrote: > Dear CCLers, > > which program running under GNU/Linux would you recommend for the > creation and editing of the input structures > for the quantum-chemical calculations? Molden is good for inputs > using Z-matrices, but is very inconvenient for the free-hand "fine- > tuning" of the guess structures, say for the transition states. > Ghemical is not bad but its development seem to be stopped. > Something as simple as the editor built-in in WebMO would be good... > > Thank you. > > > Best regards, > Konstantin Ivanov From owner-chemistry@ccl.net Tue Sep 27 22:35:27 2005 From: "CCL" To: CCL Subject: CCL: W:ESFF force field parameters Message-Id: <-29341-050927212459-25452-K6On1L9veuAbMNKbMh3bNw;;server.ccl.net> X-Original-From: Gustavo Mercier Content-Transfer-Encoding: 8bit Content-Type: multipart/alternative; boundary="0-842947512-1127867096=:71005" Date: Tue, 27 Sep 2005 17:24:56 -0700 (PDT) MIME-Version: 1.0 Sent to CCL by: Gustavo Mercier [gamercier;;yahoo.com] --Replace strange characters with the "at" sign to recover email address--. --0-842947512-1127867096=:71005 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi! Thanks for the info.... but going to that web site demands a user account and password which i don't have. I will try to contact the authors, but in the past this has not helped with other similar situations. A few years ago I tried to implement a method to generate atomic charges based on electronegativity equalization. This was an improvement in Gastergeist (I may misspell!) charges. The paper did not have the necessary parameters either. I tried contacting the author and got no reply. About 1 year ago the same issued resurfaced in the CCL with another poor soul trying to do the same thing with the same paper. He had the same result I did. In turns out that the missing parameters are listed in a database of software that is proprietary. You can reproduce the method only if you get the parameters in the "black market" or buy the software. Take care! GM CCL wrote: owner-chemistry;;ccl.net wrote on 09/27/2005 09:21:52 AM: > Sent to CCL by: "Gustavo A Mercier" [gamercier-.-yahoo.com] > --Replace strange characters with the "at" sign to recover email address--. > > Looks like a pretty "general" force field that may perform better > than UFF. I am thinking about implementing this force field into > MMTK, although I recognize that this will be a long term project > that is likely to be more than I can handle at this time... ;-) > > However, my concern is that this paper list in reference 15 > > "Atom type definition and parameters are listed in supplementary materials." > > There is no reference to this material in the JCC web site and a > google search only found a listing of atom types that may come from > Accelrys software that implements ESFF. The Accelrys site does not > have the supplementary material either. > > Does anyone know the whereabouts of this supplementary material? I believe the supplemental material to which you are referring is Appendix B, Forcefield Terms and Atom Types, in the "Forcefield-Based Simulations" documentation (URL http://www.accelrys.com/doc/life/insight2005/ffbs/FF_SimulTOC.html). Jeff -- Jeffrey L. Nauss, Ph.D. Lead Training Scientist Accelrys 10188 Telesis Court, Suite 100 San Diego, CA 92121-4779 Phone: +1-858-799-5555 Fax: +1-858-799-5100 http://www.accelrys.com/training *AccelrysWorld 2005, London, Nov 14-16. http://www.accelrysworld.com* -- Gustavo A. Mercier, Jr. MD,PhD Baylor University Medical Center Radiology American Radiology Associates 712 N. Washington, Suite 101 Dallas, TX 75246 214-826-8822 214-826-9792 fax gamercier;;yahoo.com --0-842947512-1127867096=:71005 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi!
 
Thanks for the info.... but going to that web site demands a user account and password which i don't have. I will try to contact the authors, but in the past this has not helped with other similar situations.
 
A few years ago I tried to implement a method to generate atomic charges based on electronegativity equalization. This was an improvement in Gastergeist (I may misspell!) charges. The paper did not have the necessary parameters either. I tried contacting the author and got no reply. About 1 year ago the same issued resurfaced in the CCL with another poor soul trying to do the same thing with the same paper. He had the same result I did. In turns out that the missing parameters are listed in a database of software that is proprietary. You can reproduce the method only if you get the parameters in the "black market" or buy the software.
 
Take care!
GM

CCL <owner-chemistry;;ccl.net> wrote:

owner-chemistry;;ccl.net wrote on 09/27/2005 09:21:52 AM:

> Sent to CCL by: "Gustavo A Mercier" [gamercier-.-yahoo.com]
> --Replace strange characters with the "at" sign to recover email address--.
>
> Looks like a pretty "general" force field that may perform better
> than UFF. I am thinking about implementing this force field into
> MMTK, although I recognize that this will be a long term project
> that is likely to be more than I can handle at this time... ;-)
>
> However, my concern is that this paper list in reference 15
>
> "Atom type definition and parameters are listed in supplementary materials."
>
> There is no reference to this material in the JCC web site and a
> google search only found a listing of atom types that may come from
> Accelrys software that implements ESFF. The Accelrys site does not
> have the supplementary material either.
>
> Does anyone know the whereabouts of this supplementary material?

I believe the supplemental material to which you are referring is Appendix B, Forcefield Terms and Atom Types, in the "Forcefield-Based Simulations" documentation (URL http://www.accelrys.com/doc/life/insight2005/ffbs/FF_SimulTOC.html).

Jeff
--
Jeffrey L. Nauss, Ph.D.
Lead Training Scientist
Accelrys
10188 Telesis Court, Suite 100
San Diego, CA 92121-4779

Phone: +1-858-799-5555
Fax: +1-858-799-5100
http://www.accelrys.com/training

*AccelrysWorld 2005, London, Nov 14-16. http://www.accelrysworld.com*



--
Gustavo A. Mercier, Jr. MD,PhD
Baylor University Medical Center
Radiology
American Radiology Associates
712 N. Washington, Suite 101
Dallas, TX 75246
214-826-8822
214-826-9792 fax
gamercier;;yahoo.com 
--0-842947512-1127867096=:71005-- From owner-chemistry@ccl.net Tue Sep 27 23:16:25 2005 From: "CCL" To: CCL Subject: CCL: W:ESFF force field parameters Message-Id: <-29342-050927221624-11029-4LbMvLQvEjDbrUBflauxDg]"[server.ccl.net> X-Original-From: "Jim Kress" Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C5C382.B931F170" Date: Tue, 27 Sep 2005 16:44:26 -0400 MIME-Version: 1.0 Sent to CCL by: "Jim Kress" [ccl_nospam]"[kressworks.com] --Replace strange characters with the "at" sign to recover email address--. This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C5C382.B931F170 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Given that authentication is required when one follows this url, so the supplementary material is not available to all those who read the CCC article, doesn't this constitute yet another example of "Disclose your data or do not publish?" Jim _____ > From: CCL [mailto:owner-chemistry]"[ccl.net] Sent: Tuesday, September 27, 2005 1:45 PM To: Kress, Jim Subject: CCL: W:ESFF force field parameters owner-chemistry]"[ccl.net wrote on 09/27/2005 09:21:52 AM: > Sent to CCL by: "Gustavo A Mercier" [gamercier-.-yahoo.com] > --Replace strange characters with the "at" sign to recover email address--. > > Looks like a pretty "general" force field that may perform better > than UFF. I am thinking about implementing this force field into > MMTK, although I recognize that this will be a long term project > that is likely to be more than I can handle at this time... ;-) > > However, my concern is that this paper list in reference 15 > > "Atom type definition and parameters are listed in supplementary materials." > > There is no reference to this material in the JCC web site and a > google search only found a listing of atom types that may come from > Accelrys software that implements ESFF. The Accelrys site does not > have the supplementary material either. > > Does anyone know the whereabouts of this supplementary material? I believe the supplemental material to which you are referring is Appendix B, Forcefield Terms and Atom Types, in the "Forcefield-Based Simulations" documentation (URL http://www.accelrys.com/doc/life/insight2005/ffbs/FF_SimulTOC.html). Jeff -- Jeffrey L. Nauss, Ph.D. Lead Training Scientist Accelrys 10188 Telesis Court, Suite 100 San Diego, CA 92121-4779 Phone: +1-858-799-5555 Fax: +1-858-799-5100 http://www.accelrys.com/training *AccelrysWorld 2005, London, Nov 14-16. http://www.accelrysworld.com* ------=_NextPart_000_0003_01C5C382.B931F170 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Given that authentication is required when one = follows this=20 url, so the supplementary material is not available to all those who = read the=20 CCC article, doesn't this constitute yet another example of "Disclose = your data=20 or do not publish?"
 
Jim

From: CCL = [mailto:owner-chemistry]"[ccl.net]=20
Sent: Tuesday, September 27, 2005 1:45 PM
To: = Kress, Jim=20
Subject: CCL: W:ESFF force field=20 parameters


owner-chemistry]"[ccl.net wrote on = 09/27/2005=20 09:21:52 AM:

> Sent to CCL by: "Gustavo A Mercier"=20 [gamercier-.-yahoo.com]
> --Replace strange characters with the = "at"=20 sign to recover email address--.
>
> Looks like a pretty=20 "general" force field that may perform better
> than UFF. I am = thinking=20 about implementing this force field into
> MMTK, although I = recognize=20 that this will be a long term project
> that is likely to be = more than=20 I can handle at this time... ;-)
>
> However, my concern = is that=20 this paper list in reference 15
>
> "Atom type definition = and=20 parameters are listed in supplementary materials."
>
> = There is=20 no reference to this material in the JCC web site and a
> = google search=20 only found a listing of atom types that may come from
> = Accelrys=20 software that implements ESFF. The Accelrys site does not
> = have the=20 supplementary material either.
>
> Does anyone know the=20 whereabouts of this supplementary material?

I believe the supplemental material to which you are = referring is=20 Appendix B, Forcefield Terms and Atom Types, in the "Forcefield-Based=20 Simulations" documentation (URL=20 = http://www.accelrys.com/doc/life/insight2005/ffbs/FF_SimulTOC.html).= =20

Jeff
--
Jeffrey L. Nauss, Ph.D.
Lead Training=20 Scientist
Accelrys
10188 Telesis Court, Suite 100
San Diego, = CA=20 92121-4779

Phone: +1-858-799-5555
Fax:=20 = +1-858-799-5100
http://www.accelrys.com/training

*AccelrysWorld= =20 2005, London, Nov 14-16. http://www.accelrysworld.com*=20

------=_NextPart_000_0003_01C5C382.B931F170-- From owner-chemistry@ccl.net Tue Sep 27 23:16:25 2005 From: "CCL" To: CCL Subject: CCL: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29343-050927213500-28940-ZWRW2t5blh62dMU1PTqiKw__server.ccl.net> X-Original-From: "Dr. N. SUKUMAR" Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain Date: Tue, 27 Sep 2005 20:25:29 -0400 MIME-Version: 1.0 Sent to CCL by: "Dr. N. SUKUMAR" [nagams__rpi.edu] --Replace strange characters with the "at" sign to recover email address--. ==============Original message text=============== On Tue, 27 Sep 2005 17:45:35 EDT "CCL" wrote: Sent to CCL by: "Perry E. Metzger" [perry-*-piermont.com] For those that do not know, Tony Hoare was making fun of the Fortran users here, not praising them. Perry ===========End of original message text=========== Fortran users (and scientists in general) write programs to get the job done, not for the "praise" of comp-sci.folks or for the philosophical satisfaction of "dreaming up abstractions" Perhaps CCL should set aside one month every year (maybe around Christmas?) as bash-Fortran month. Dr. N. Sukumar Center for Biotechnology and Interdisciplinary Studies Rensselaer Polytechnic Institute From owner-chemistry@ccl.net Tue Sep 27 23:59:07 2005 From: "CCL" To: CCL Subject: CCL: [CCL]: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29344-050927235607-29009-kE6HsFgQB4BnX5brtgHYUA : server.ccl.net> X-Original-From: "Perry E. Metzger" Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Sep 2005 23:56:01 -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--. > 1) When Perry says Fortran, as near as I can tell he really means > f77 or earlier versions of fortran. It is to my mind completely > disingenuous to say "fortran", referring to the capabilities of > these versions of the language, and completely ignore the fact that > the fortran language has evolved to a significant extent, and can > now come very close to C's ability to handle more sophisticated data > structures and algorithms. This is like referring to the > capabilities of B, and calling it C. Er, C has more or less been the same language for more than 30 years. The declaration syntax got improved a bit and a few other tricks like void arrived, but you could write more or less the same stuff in it in 1977 that you can today. But, yes, it is true that F90/F95/F2003 are substantially better languages than F77. They do in fact have the ability to handle substantially more sophisticated data structures and types. However, if you have a "dusty deck" (the topic that started us off here), and you have the opportunity to start afresh, you're still better off moving to something else. > 2) I concur that f90/95 lacks any real object implementation and cannot > easily do a number of things that C++ can do; I'd like to be clear that I don't like C++ -- it is far too large a language, and is almost impossible even for a professional to keep fully in mind. It is poorly designed in many ways -- bloated and yet still dangerous. However, if one sticks to a small subset of its capabilities and is careful one can achieve reasonable results. > as for lisp, I last dealt with it over 20 years ago, and while I > think it is conceptually "way cool", I have not seen a big stampede > to implement systems using it for a whole bunch of reasons. Well, the biggest reason is that it is just plain too weird for most people who haven't made a substantial effort with the language. First of all, the syntax is alien to most people -- and as with APL, that alone keeps people far away. Then the language is filled with meta-level programming concepts like programs operating on data structures that happen to be other programs (such as macros) which are quite alien in and of themselves. Scheme, a dialect of lisp, allows you to do even odder things than most lispers are used to -- including the fact that the state of the program (a "continuation") is a first class data type, which may be captured and operated on the way other languages allow you to, say, capture the location of a data structure in a pointer. I'm not per se advocating that people use lisp -- I think the culture shock would be pretty high, you'll have a lot of trouble finding other people who can read your code, and you won't find large libraries of pre-written numerical routines. It is, however, an extremely high productivity environment. Once you get used to it, you can throw systems together orders of magnitude faster. A good essay on the topic: http://www.paulgraham.com/iflisp.html > b) Sorry, but at least in my experience, f90/95 does a better job dealing > with a variety of mathematical issues, with arrays as a really important, if > unsatisfyingly simple, data structure (including DYNAMIC multidimensional > arrays with decent indexing), You can allocate a multidimensional array dynamically in C and index it just like you index any other array. > and with number crunching performance issues. In general, that's at worst a compiler issue. There is nothing inherent to either language that gives it an advantage in compiling numeric code. Modern C compilers do very well on numerical performance, though. People with substantial numerical performance demands use them for writing things like video games, and they can't afford second rate code. One does, however, have to know one's tools. For example, if you don't know to use stuff options like -mfpmath=sse when compiling GCC, you won't get SSE vectorized code on a modern Pentium, and that makes a big difference in performance. You also want to tell the compiler to inline transcendental functions as FPU instructions or it won't. Proper use of "inline" and other declarations also helps. Many systems programmers don't care about this stuff so they won't know to tell you to do it, but a quick read of your documentation will tell you about it. Most importantly, though, it is important to profile performance critical code and to understand what actually is the bottleneck. That is true whether you're writing Fortran, C or anything else. You can't fix what you don't understand. > If you choose to go the C/C++ route, fine, but just be sure you really > understand the tools, and plan on spending perhaps more time than you really > have to spare on gaining proficiency. And don't think for a minute that > somebody who took one course and has never been in the trenches is going to > immediately be a great trailblazer. That's excellent advice in general. You have to know your tools well in order to use them well. A five star chef has to spend years learning technique in order get to the point that he can consistently turn what's in his head into something on a plate. That means knowing his equipment intimately. The non-professional neither has the equipment nor would have the skill if he did have it. Someone doing serious (not casual, serious) work on computers has to expect the same sort of effort is involved. The good part is that if you learn your craft well, you can produce things that normal people simply cannot because they don't understand their tools. Perry