From owner-chemistry@ccl.net Wed Sep 28 02:33:06 2005 From: "CCL" To: CCL Subject: CCL: using the aug-cc-pv6z basis set Message-Id: <-29345-050928011013-5662-oiVVbgUq5mRy/5YzCcHa4g~!~server.ccl.net> X-Original-From: "Guha, Sujata" Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C3C9.7C9E2018" Date: Tue, 27 Sep 2005 20:10:59 -0500 MIME-Version: 1.0 Sent to CCL by: "Guha, Sujata" [sguha~!~tnstate.edu] --Replace strange characters with the "at" sign to recover email address--. This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C3C9.7C9E2018 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear CCL Users, =20 I'm trying to perform a ccsd(t)/aug-cc-pV6Z calculation (on a molecule = containing aluminum) with the G03 software. The job runs for about 2 = seconds and crashes giving the message:=20 Standard basis: Aug-CC-pV6Z (5D, 7F)=20 Atomic number out of range in CCPV6Z.=20 =20 The input line of my data file is: =20 #p ccsd(maxcyc=3D600,t)/aug-cc-pv6z scfcyc=3D600 optcyc=3D100 = opt=3Dz-matrix scf=3Ddirect TRANS=3DIABC geom=3Dcheck guess=3Dread=20 =20 Any suggestions on how I could approach the problem? Thanks. S. Guha=20 =20 Sujata Guha, Ph.D. =20 Assistant Professor of Chemistry=20 Tennessee State University=20 3500 John Merritt Blvd.=20 Nashville, TN 37209=20 Phone: (615)963-5334=20 Fax: (615)963-5326=20 E-mail: sguha~!~tnstate.edu =20 =20 =20 ------_=_NextPart_001_01C5C3C9.7C9E2018 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear CCL Users,
=0A=
 
=0A=
I’m trying to perform =0A= a ccsd(t)/aug-cc-pV6Z calculation (on a molecule containing = aluminum) with =0A= the  G03 software. The job runs for about 2 seconds = and crashes =0A= giving the message: =0A=
Standard = basis: =0A= Aug-CC-pV6Z (5D, 7F) =0A=
Atomic = number out of =0A= range in CCPV6Z.
=0A=
 
=0A=
The input line of my data file is:
=0A=
 
#p ccsd(maxcyc=3D600,t)/aug-cc-pv6z = scfcyc=3D600 =0A= optcyc=3D100 opt=3Dz-matrix scf=3Ddirect = TRANS=3DIABC geom=3Dcheck guess=3Dread
=0A=
 
=0A=
Any suggestions on how I could approach the problem? = Thanks.
=0A=
 S. Guha
=0A=
 
=0A=
Sujata Guha, Ph.D.  
=0A= Assistant Professor of Chemistry
=0A=
Tennessee State University 
3500 =0A= John Merritt Blvd. 
Nashville, TN =0A= 37209 
Phone: (615)963-5334 =
Fax: (615)963-5326
=0A=
E-mail: sguha~!~tnstate.edu

=0A=

 

=0A=

=0A=
 
=0A=
 
------_=_NextPart_001_01C5C3C9.7C9E2018-- From owner-chemistry@ccl.net Wed Sep 28 02:33:06 2005 From: "CCL" To: CCL Subject: CCL: CCL Manager lecture on list distribution and sensitivities Message-Id: <-29346-050928023145-24791-78Oaq1Brrno49z4xyhxwuA^^server.ccl.net> X-Original-From: janl^^speakeasy.net Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 28 Sep 2005 06:31:40 +0000 MIME-Version: 1.0 Sent to CCL by: janl^^speakeasy.net --Replace strange characters with the "at" sign to recover email address--. The tale of your beloved CCL administrator continues... 1st... Thank you for your personal mail... I WILL ANSWER IT, JUST GIVE ME A DAY OR THREE {:-)}. I want to make some disclaimers first... 1) The list operates within the US, i.e., is subject to US laws. Even lawyers do not know the US laws and have problems understanding it, since its quality is inversely proportional to its production rate. If I operated CCL from Bahamas, it would be better off since they have different laws or none at all. But this is not a case... Support me, maybe one day... {:-)} 2) I am not a lawyer, and anything I say about the law is irrelevant, and you should not trust it. My comments and understanding is most likely wrong... But I am not paranoid, and I have reasons for saying what I say. 3) What I say in public, is what I can say in public... It may be a part of the whole story... And I am saying too much... 4) I registered CCL as a Limited Liability Company to protect the list. This protection is Limited mostly to creditors (that I do not have...) and does not protect me from personal misdeeds, like knowingly performing illegal acts against the laws of the United States of America. I added Web forms that allow you to instantly subscribe and unsubscribe to CCL list. You can do it everyday if you wish, but be considerate... I am getting all copies of your automatic responses from Web forms. On related topic... Some of you expressed anxiety that it is possible to anonymously post to the list. It depends on what you consider anonymous. The CCL e-mail discussion forum has two parts: 1) Receiving messages from CCL. You need to subscribe to CCL to get E-mail messages from CCL. If you are not subscribed, you can read CCL messages on the Web at: http://www.ccl.net/chemistry/resources/messages/ in real time as they are posted to the list (note the [Raw Text] link in the upper left when you view the message). 2) Sending messages to CCL. Anyone can post to CCL. The only condition is that his/her e-mail address is valid and that their address is "blessed" (later what it means). Before message is posted, the sender has to confirm that he/she had sent the message, i.e., his/her address has to be able to receive the mail, what in most cases mean that it is real. Why so? a) I have several e-mail addresses and twenty aliases in various places. The era of one_address/one_person is over. I belong to several mailing lists, and it is annoying, when I have to go to the specific machine, from which I originally subscribed to a list, to post the message. If it is annoying for me, it is annoying for you. And beside, forging From: address in the e-mail message is trivial... b) With the advent of gmails, hotmails, yahoomails, roadrunner mails, etc... you can be pretty anonymous. Many email providers will allow you NOT TO HAVE your name appear on the From line. It is impractical to require institutional address for posting. And beside, many companies and government labs have STRICT policies discouraging use of company address for anything but official communications. Moreover, it is also prudent to use your "private" address for legal reasons. c) I have no resources to perform background checks of people subscribing to CCL, and definitely NO CRITERIA as to who should be allowed to post to CCL. Even if I had the CRITERIA then how do I check the compliance? d) While I can easily block certain addresses from posting, it is mostly irrelevant. Not only it is trivial to forge the address, but with thousands of e-mail service providers, one can post from a different address every day. e) For legal reasons (later...) I cannot moderate the list. The current system is that the first post from the given address is reviewed by me. If it is accepted, the address gets "blessed" and gets appended to "previous successful posters" file. From this moment, the address can post to the list without my approval. I can change this policy to first two, three, etc. posts needed for "blessing". But does it really make a difference? I try to be a phone company that does not approve what is being said and who talks to whom. Moreover, your communications can be heard by EVERYONE. Otherwise, I would be responsible for everything that gets posted. We all know that the 'freedom of speech" slogan was reduced to a verbiage by case law. f) All messages sent to CCL are displayed on the Web at http://www.ccl.net/chemistry/resources/messages/ Please make a note of it: -- you do not have to be a subscriber to CCL to read CCL messages -- if you post to CCL then EVERYONE in the world (including police, mafia, department X and your boss) can read it (and find it on Google!!!). The Internet Mail protocol is what it is... It is as good as the regular paper mail. The From: address may be absent, forged or illegible, and if you are lucky you may find from the rubber stamp of the Post Office (i.e., in our case the IP address) from which the letter was sent. But you can drive a few miles (on Internet, you can crack some home computer or sign up to a "Free Email in Exchange for Free Advertising" place...) and post it from a random Post Office. And you can go to a StarBucks coffee place and post from the random IP address from your laptop that can send mail fine... In the CCL case, you still need a fully qualified domain name (I do not allow mail > from IP addresses that do not resolve) to post, but in many countries of the world you can register a domain without giving your name, and there are companies that allow you to house the Name Server for this domain via simple Web interface. And they do not keep any logs. Terrorist have their Web sites, and even the mighty CIA can do nothing... At the same time, you may have noticed that there is not much spam on the list. There is too much of "Thank you" notes that increase unnecessarily the volume on the list what probably infuriate those who are "Thanked". Please read the rules: http://www.ccl.net/chemistry/aboutccl/rules/ NOTE: Short commercial posting are allowed, but they need to be short, informative and useful. This is a long standing policy, and majority of CCL subscribers opted to have useful news from vendors at one point. Vendors are well aware of the fact that posting "crappe" on the list makes them look bad, and image is "everything". And this leads us to another topic. The US has Export Control laws. Certain kinds of software are "munition". For example: cryptographic software that can be used to hide information from the big brother, or the computational chemistry software that can be used for design of agents, explosives, or materials that can have "dual use" cannot be "exported". Not only that, but aiding the parties in the countries that are on the black list in using and operating such software is also considered "exporting". Also note that some of this software could not have had beed legally obtained of purchased. Obviously, this is a major dilemma for someone who runs the public discussion forum. While we all know that as scientistc we all belong to the brotherhood of science and we help people, but some people think differently and protect us. What I am trying to do is to make sure that I do not control who says what to whom. I am not the guy to tell you what to write... The same also applies to trade secrets. If you divulge information about some supersecret molecule that is not yet patented, or the algorithm that is commonly known, but someone thinks that he/she invented it, I do not want to be blamed. So I do not moderate/censor the CCL and I make sure that the WHOLE DAMNED WORLD can read what you say. Otherwise, I would have to check your credentials, collect oaths > from all of you, and keep my servers in the vault and grant access on the "need-to-know" basis. I already said too much, but you can figure out the rest. Do I agree with this? Do I think that all scientists are brothers and ambassadors of tranquility, freedom, democracy, and that they are the future leaders of piece loving nations? No, I do not... Some of them are, and some of them are not... And beside, I do not know all of them well enough, and I know from experience that they also change with time and under "extenuating circumstances" {;-)}. At the same time, with my lack of censorship you do not see much spam. I try to block it using software. Software cannot be sued and cannot have lapses of judgment. It can be good or bad, but does not have the conscience and is not legal personality of its own. Now... On a positive note... Some of you are annoyed with the fact that you "cannot respond" to the author and the e-mail addresses of authors are messed-up. While not many people are doing it yet, but the fact is that 90% of computers are infected with some kind of spyware. There are different spywares, but there is a growth of spyware that, among other things, collects email addresses, i.e., the things in the text that e.g., satisfy the following regular expression: /[a-z0-9._+-]+\^^[a-z0-9._-]+/i Then, they send the stuff around the ^^ characters that they find in your mail, addressbooks and web pages stored in your browser cache to the "collection points" in countries where you can do on the Internet what you wish. Then the lists of addresses are sold on CDs and DVDs to spammers and general public. So what I am trying to do is to make sure that I am one step ahead of the spyware. By necessity, the spyware has to be short, simple and efficient and while you, humans, will easily correct the messed-up addresses to good ones, the spyware cannot do it yet. While humans can also do what spyware does, they are too inefficient and too expensive. Sorry about it, but I really care. And I also know that some of you have spyware on your Windoz machines. Please trust me... It is not to make your life miserable, but just the opposite. We are all victims of this spam-craze and there is no light at the end of the tunnel. While we may some day go to cryptographically signing our mail, we are nowhere near, and with current architectural flaws of the most popular operating system on the Planet, the secret keys will be sold on DVDs in the future, like the email addresses are now. And beside, it will be the end of our privacy and we will all have numbers tattooed on our forearms. Jan -- Jan labanowski CCL Manager jkl^^ccl.net From owner-chemistry@ccl.net Wed Sep 28 04:16:24 2005 From: "CCL" To: CCL Subject: CCL: using the aug-cc-pv6z basis set Message-Id: <-29347-050928040700-801-4WsU4UxCjX2QjprIVdbniA[a]server.ccl.net> X-Original-From: Marcel Swart Content-Type: multipart/alternative; boundary=Apple-Mail-1--736304343 Date: Wed, 28 Sep 2005 10:05:50 +0200 Mime-Version: 1.0 (Apple Message framework v623) Sent to CCL by: Marcel Swart [m.swart[a]few.vu.nl] --Replace strange characters with the "at" sign to recover email address--. --Apple-Mail-1--736304343 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; format=flowed I guess one of the atoms in your molecule is not (yet) present in the=20 aug-cc-pV6Z basis. On Sep 28, 2005, at 3:10 AM, CCL wrote: > Dear CCL Users, > =A0 > I=92m trying to perform a ccsd(t)/aug-cc-pV6Z calculation (on a = molecule=20 > containing aluminum)=A0with the=A0 G03 software.=A0The job runs for = about 2=20 > seconds and crashes giving the message: > Standard basis: Aug-CC-pV6Z (5D, 7F) > Atomic number out of range in CCPV6Z. > =A0 =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-(0)20-5987619 Fax +31-(0)20-5987629 E-mail m.swart[a]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-1--736304343 Content-Transfer-Encoding: quoted-printable Content-Type: text/enriched; charset=WINDOWS-1252 I guess one of the atoms in your molecule is not (yet) present in the aug-cc-pV6Z basis. On Sep 28, 2005, at 3:10 AM, CCL wrote: ArialDear CCL Users, =A0 Times New RomanI=92m trying to perform a ccsd(t)/aug-cc-pV6Z calculation (on a molecule containing aluminum)=A0with the=A0 G03 software.=A0The job runs for = about 2 seconds and crashes giving the = message:Times New Roman Times New = RomanStandard basis: Aug-CC-pV6Z (5D, = 7F)<= param>Times New Roman Times New = RomanAtomic number out of range in CCPV6Z. = Ti= mes New Roman =A0 = Helvetica=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 = Papyrusdr. Marcel Swart = Papyrus = OsakaTheoretische Chemie Vrije Universiteit Amsterdam Faculteit der Exacte Wetenschappen De Boelelaan 1083 1081 HV Amsterdam The Netherlands Tel +31-(0)20-5987619 Fax +31-(0)20-5987629 E-mail m.swart[a]few.vu.nl Web http://www.few.vu.nl/~swart = Helvetica=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-1--736304343-- From owner-chemistry@ccl.net Wed Sep 28 04:18:36 2005 From: "CCL" To: CCL Subject: CCL: Open source contributions by pharma. Message-Id: <-29349-050928035131-29408-2GIVVYHsUIbjHQPY3Vakwg{:}server.ccl.net> X-Original-From: Miklos Vargyas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Date: Wed, 28 Sep 2005 08:54:19 +0200 MIME-Version: 1.0 Sent to CCL by: Miklos Vargyas [miklos.vargyas{:}chemaxon.hu] --Replace strange characters with the "at" sign to recover email address--. Dear all, open source java programs are found in ChemAxon's User forum area, partly given away by ChemAxon and contributed by users. http://www.chemaxon.com/forum/forum10.html Also note, that all ChemAxon software are free for academic users. http://www.chemaxon.com/forum/ftopic193.html Regards, Miklos CCL wrote: > > 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. > > > ....................................................................... From owner-chemistry@ccl.net Wed Sep 28 04:17:53 2005 From: "CCL" To: CCL Subject: CCL: W:ESFF force field parameters Message-Id: <-29348-050928041714-3958-fh1ZCi+j4gZsvO4qTr/p7w===server.ccl.net> X-Original-From: Marcel Swart Content-Type: multipart/alternative; boundary=Apple-Mail-2--735683384 Date: Wed, 28 Sep 2005 10:16:11 +0200 Mime-Version: 1.0 (Apple Message framework v623) 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--735683384 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Dear all, the supplementary info are a bit hidden at the J.Comp.Chem. website, but by Googling (with supplementary "journal of computational =20 chemistry") you'll get there if you try some things; for this specific paper, the supp.info can be found at: http://www.mrw.interscience.wiley.com/suppmat/0192-8651/suppmat/=20 aid.0064.html and in general, for all online issues of JCC: http://www.mrw.interscience.wiley.com/suppmat/0192-8651/suppmat/ On Sep 27, 2005, at 6:20 PM, CCL wrote: > > Sent to CCL by: "Gustavo A Mercier" [gamercier-.-yahoo.com] > > --Replace strange characters with the "at" sign to recover email =20 > 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 = =20 > UFF. I am thinking about implementing this force field into MMTK, =20 > although I recognize that this will be a long term project that is =20 > 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 =20 > materials." > > There is no reference to this material in the JCC web site and a =20 > google search only found a listing of atom types that may come from =20= > Accelrys software that implements ESFF. The Accelrys site does not =20 > 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 > > > > -=3D This is automatically added to each message by the mailing script = =3D- > To send e-mail to subscribers of CCL put the string CCL: on your =20 > Subject: line > and send your message to: CHEMISTRY===ccl.net > > Send your subscription/unsubscription requests to: =20 > 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, =20 > please > use the Web based form from CCL Home Page > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= > +-+ > > > > =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-(0)20-5987619 Fax +31-(0)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--735683384 Content-Transfer-Encoding: quoted-printable Content-Type: text/enriched; charset=WINDOWS-1252 Dear all, the supplementary info are a bit hidden at the J.Comp.Chem. website, but by Googling (with supplementary "journal of computational chemistry") you'll get there if you try some things; for this specific paper, the supp.info can be found at: = http://www.mrw.interscience.wiley.com/suppmat/0192-8651/suppmat/aid.0064.h= tml and in general, for all online issues of JCC: http://www.mrw.interscience.wiley.com/suppmat/0192-8651/suppmat/ On Sep 27, 2005, at 6:20 PM, CCL wrote: 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 -=3D This is automatically added to each message by the mailing script = =3D- To send e-mail to subscribers of CCL put the string CCL: on your Subject: line and send your message to: CHEMISTRY===ccl.net Send your subscription/unsubscription requests to: CHEMISTRY-REQUEST===ccl.net=20 HOME Page: http://www.ccl.net | Jobs Page: http://www.ccl.net/jobs=20 If your is mail bouncing from ccl.net domain due to spam filters, please use the Web based form from CCL Home Page=20= Helvetica=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 = Papyrusdr. Marcel Swart = Papyrus = OsakaTheoretische Chemie Vrije Universiteit Amsterdam Faculteit der Exacte Wetenschappen De Boelelaan 1083 1081 HV Amsterdam The Netherlands Tel +31-(0)20-5987619 Fax +31-(0)20-5987629 E-mail m.swart===few.vu.nl Web http://www.few.vu.nl/~swart = Helvetica=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--735683384-- From owner-chemistry@ccl.net Wed Sep 28 06:53:19 2005 From: "CCL" To: CCL Subject: CCL: using the aug-cc-pv6z basis set Message-Id: <-29350-050928064859-4400-a2w7CLyZGNSYvIJ4aplLeg=-=server.ccl.net> X-Original-From: Tanja van Mourik Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Sep 2005 10:50:46 +0100 (BST) MIME-Version: 1.0 Sent to CCL by: Tanja van Mourik [t.vanmourik=-=ucl.ac.uk] --Replace strange characters with the "at" sign to recover email address--. Dear Sujata, > I'm trying to perform a ccsd(t)/aug-cc-pV6Z calculation (on a molecule = > containing aluminum) with the G03 software. The job runs for about 2 = > seconds and crashes giving the message:=20 > Standard basis: Aug-CC-pV6Z (5D, 7F)=20 > Atomic number out of range in CCPV6Z.=20 > =20 It sounds like the Al aug-cc-pV6Z basis set is not (yet) implemented as a standard basis set in Gaussian. Just download it from the EMSL basis set order form: http://www.emsl.pnl.gov/forms/basisform.html and input it as a general basis set. Hope that helps, Tanja -- ================================================================= Tanja van Mourik Royal Society University Research Fellow Chemistry Department University College London phone: +44 (0)20-7679-4663 20 Gordon Street e-mail: work: T.vanMourik=-=ucl.ac.uk London WC1H 0AJ, UK home: tanja=-=van-mourik.me.uk http://www.chem.ucl.ac.uk/people/vanmourik/index.html ================================================================= From owner-chemistry@ccl.net Wed Sep 28 07:33:03 2005 From: "CCL" To: CCL Subject: CCL: using the aug-cc-pv6z basis set Message-Id: <-29351-050928073231-22484-0VWsJTv4lzsK8bcFsMsvJA() server.ccl.net> X-Original-From: "Pablo Vitoria" Content-Transfer-Encoding: 7bit Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Date: Wed, 28 Sep 2005 13:32:07 +0200 MIME-Version: 1.0 Sent to CCL by: "Pablo Vitoria" [pablo.vitoria() ehu.es] --Replace strange characters with the "at" sign to recover email address--. Hi, In EMSL aug-cc-PV6Z is defined for: H He B C N O F Ne Al Si P S Cl Ar, but in Gaussian 03 is only defined for H B C N O F Ne. Pablo ----- Original Message ----- > From: "CCL" To: "Vitoria, Pablo " Sent: Wednesday, September 28, 2005 11:50 AM Subject: CCL: using the aug-cc-pv6z basis set > > Sent to CCL by: Tanja van Mourik [t.vanmourik=-=ucl.ac.uk] > > --Replace strange characters with the "at" sign to recover email > address--. > > Dear Sujata, > >> I'm trying to perform a ccsd(t)/aug-cc-pV6Z calculation (on a molecule = >> containing aluminum) with the G03 software. The job runs for about 2 = >> seconds and crashes giving the message:=20 >> Standard basis: Aug-CC-pV6Z (5D, 7F)=20 >> Atomic number out of range in CCPV6Z.=20 >> =20 > > It sounds like the Al aug-cc-pV6Z basis set is not (yet) implemented > as a standard basis set in Gaussian. Just download it from the EMSL > basis set order form: > > http://www.emsl.pnl.gov/forms/basisform.html > > and input it as a general basis set. > > Hope that helps, > > Tanja > -- > ================================================================= > Tanja van Mourik > Royal Society University Research Fellow > Chemistry Department > University College London phone: +44 (0)20-7679-4663 > 20 Gordon Street e-mail: work: T.vanMourik() ucl.ac.uk > London WC1H 0AJ, UK home: tanja() van-mourik.me.uk > > http://www.chem.ucl.ac.uk/people/vanmourik/index.html > =================================================================> > From owner-chemistry@ccl.net Wed Sep 28 09:28:44 2005 From: "CCL" To: CCL Subject: CCL: NMR calculation Message-Id: <-29352-050928043629-6958-FkCz/tYjyjhwyw8TFGyrIg(!)server.ccl.net> X-Original-From: Adan Gonzalez Perez Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Date: Wed, 28 Sep 2005 09:49:54 +0200 MIME-Version: 1.0 Sent to CCL by: Adan Gonzalez Perez [adagonzalez(!)alumnos.uvigo.es] --Replace strange characters with the "at" sign to recover email address--. CCL wrote: >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>To send e-mail to subscribers of CCL put the string CCL: on your Subject: line >and send your message to: CHEMISTRY(!)ccl.net > >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 >use the Web based form from CCL Home Page> > > > > Hi Senthilnathan; I use to calculate NMR of organic compounds in gaussian03, (I think that in g98 exist the keyword too) , I don't know whether it's the best theoretical method to this kind of calculation but I work with it and it works. Put NMR=giao at the input file after the method and basis set . You can find more information about this method and other similar in the gaussian home page http://www.gaussian.com/g_ur/k_nmr.htm . Best regards From owner-chemistry@ccl.net Wed Sep 28 09:28:47 2005 From: "CCL" To: CCL Subject: CCL: [CCL]: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29353-050928051457-9229-ydYI9r1F1OvkpDM+uEj6Qg[A]server.ccl.net> X-Original-From: Drew McCormack Content-Type: multipart/alternative; boundary=Apple-Mail-1--737272058 Date: Wed, 28 Sep 2005 09:49:43 +0200 Mime-Version: 1.0 (Apple Message framework v734) Sent to CCL by: Drew McCormack [da.mccormack[A]few.vu.nl] --Replace strange characters with the "at" sign to recover email address--. --Apple-Mail-1--737272058 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > >> 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. You can, but it is not easy. First you call malloc to create a buffer; then you use embedded loops to assign pointers to the beginning of each row. It is considerably more difficult that Fortran 90's "allocate( array(1,2,3) )". I don't think there is any question that Fortran 90's array features are vastly superior to C's. For example, being able to add local arrays to the stack ('automatic objects' is the Fortran terminology), and deciding dimensions at run time, are very useful. C's array support is primitive, but that is not true of C++. Although the C++ language doesn't improve on the situation, it is possible to write classes in C++ that parallel Fortran 90's arrays. You can also simply use a library that already includes this support (eg Blitz++, POOMA). Not only that, but C++ can go further than Fortran 90; you can write classes that abstract data structures not supported by Fortran 90, like sparse arrays and matrices. I have a C++ class for a multidimensional array (tensor) in which rank is determined at run time; this is not trivial to do in Fortran 90, where array ranks must be known at compile time. In summary, for array support, Fortran 90 beats C, but C++ beats Fortran 90 when appropriate libraries are used. Drew --------------------------------------------------------- Drew McCormack www.maniacalextent.com --Apple-Mail-1--737272058 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII

=
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
arrays with decent = indexing),


You can allocate a = multidimensional array dynamically in C and index
it just like you index any other = array.

You can, but it is not easy. First you call = malloc to create a buffer; then you use embedded loops to assign = pointers to the beginning of each row. It is considerably more difficult = that Fortran 90's "allocate( array(1,2,3) )".

I don't think there is any = question that Fortran 90's array features are vastly superior to C's. = For example, being able to add local arrays to the stack ('automatic = objects' is the Fortran terminology), and deciding dimensions at run = time, are very useful.

C's array support is = primitive, but that is not true of C++. Although the C++ language = doesn't improve on the situation, it is possible to write classes in C++ = that parallel Fortran 90's arrays. You can also simply use a library = that already includes this support (eg Blitz++, POOMA). Not only that, = but C++ can go further than Fortran 90; you can write classes that = abstract data structures not supported by Fortran 90, like sparse arrays = and matrices. I have a C++ class for a multidimensional array (tensor) = in which rank is determined at run time; this is not trivial to do in = Fortran 90, where array ranks must be known at compile = time.

In = summary, for array support, Fortran 90 beats C, but C++ beats Fortran 90 = when appropriate libraries are used.

Drew

= =

= --Apple-Mail-1--737272058-- From owner-chemistry@ccl.net Wed Sep 28 09:49:25 2005 From: "CCL" To: CCL Subject: CCL: W:CCL: Why is there (again) a religious war on FORTRAN vs C++ Message-Id: <-29354-050928094220-19498-FTtaKQ2a6xfrUo7w0B13iA(-)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 27, 2005, at 10:22, Christoph van Wullen wrote: > 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). This is a good occasion to examine what makes those discussions often look like "religious wars", but before getting to that, I would like to disagree with your statement that one "can build any project in any language". That's not true and anyone who has used more than one language seriously is aware of it. You cannot, in practice, write GUI code in Fortran, operating systems in APL, real-time hardware control software in Python, or artificial intelligence systems in C. Programming languages are tools that were designed for some applications and are usually limited to those plus similar ones, even though every now and then someone makes a huge effort to do something very different just to prove a point. However, if there were nothing but pragmatic choices involved in using programming languages, we would have calm and informative exchanges on this topic rather than somewhat heated debates. The truth is that programming language choice depends on personal preferences much more than on technicalities. But the culture of science does not admit the subjectivity of personal preferences, which makes us all hide them behind "objective" and "rational" arguments that we are more at ease with in communication, even though they are of rather secondary importance. That's what psychologists call rationalization. The biggest personal factor in the game is someone's attitude towards programming. I, for example, happen to like it. I like to figure out programming solutions to hard problems, and I like to find "elegant" solutions as well. That also means that I like using good programming tools. Learning another programming language that offers new forms of expression is fun for me, not work. I could even pick one research topic over another because it provides me the opportunity to learn another programming tool, even though I would never write that into a grant application. It shouldn't be surprising that I am more likely to know a good tool for a job and get the (programming) job done quickly and well than someone for whom programming is a chore that just needs to be done, someone for whom the fun part is using, rather than writing, the program. Moreover, such a person is more likely to prefer a language with an easy learning curve to an expressive one. Next, each of us has different priorities with respect to language features. Some go for comfort (good tool and library support), others for safety nets (typechecking etc.), yet others for brevity, legibility, maximum control, or something else again. While each of these characteristics can be analyzed "objectively" to some point, the final compromise is personal and subjective. The same holds for syntactic preferences, which are often more esthetic than pragmatic. Finally, we are all attached to communities that have certain preferences, and for many people it is important to respect the habits of their community, either because they count on support from that community, or because they fear being seen as a rebel or outsider if they make a different choice. -- --------------------------------------------------------------------- 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 Wed Sep 28 11:10:57 2005 From: "CCL" To: CCL Subject: CCL: [CCL]: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29355-050928110207-23616-muUhq9lqRFcM+CVXcES3tw * 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: Wed, 28 Sep 2005 11:01:56 -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, one last round of clarifications, really, with emphasis on issues of multidimensional arrays in C vs. Fortran. Comments embedded below as appropriate. Regards - Bob Duke ----- Original Message ----- > From: "CCL" To: "Duke, Robert E " Sent: Tuesday, September 27, 2005 11:56 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--. > > >> 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. That was a simile. B was the precursor to C, and B itself was preceded by BCPL; this was the evolutionary sequence for C, and the precedents were in no way as desirable to use as C. > > 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. Really? Doesn't it depend on a number of factors as to whether you are better off moving to something else? Isn't that a lot of what this discussion is about? > >> 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. > Well, I do very much like C++, but otherwise I totally agree with what you say here, and I have always advocated that an appropriate subset of the language be used, and that the language be used by individuals who are focused purely on software development. I used it a lot through much of the 90's while working on both Windows NT and Exchange development at Microsoft. It was very nice to use in that environment, and despite initial performance concerns, we worked out ways to insure the high levels of performance required for OS dev. A real pain, however, is subtle differences in the meaning of some things, like const, in C vs. C++. >> 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. > Okay, maybe there is something I don't know here, so feel free to enlighten me, but I think setup is a bit more complex, and the potential for screwups is higher. Let's go through my understanding of the differences between the two languages in this domain. My understanding of C/C++ may be a little dated in this regard, so inform me if c99 has introduced new capabilities that make this less onerous. My standard c/c++ references are: K & R - of course Plum - "Reliable Data Structures in C" Ellis & Stroustrup - "The Annotated C++ Reference Manual" - This was the C++ bible when I was at Microsoft, and for those that don't know C++ is Stroustrup's baby. Multidimensional C arrays Static arrays are of course easy. You declare something like: float a[200][3]; and off you go, able to index into this array with the 3 subscript varying most rapidly. Of course this is the reverse of the more common fortran index order, and array subscripts start at 0, and both of these facts have a certain amount of nuisance value that should not be overlooked as a point of pain in a port. There is a common trick in the scientific community of overallocating by 1 in all dimensions and starting your indexing at 1 (ie., don't use the 0 element). Aside from wasting space (probably not a huge deal in many domains), this practice creates C that is not idiomatic, and when a real C programmer comes along s/he will be driven nuts, and worse, may mix conventions on you, resulting in a number of interesting problems down the line (it may be inferred that I am not behind this practice - if you are going to write C, learn to write C, darn it). However, say you don't know ahead of time what the dimensions for the array will be. Well, of course you just malloc() (ie., allocate) an array and use it, right? Well, yes, but if you want to use the array in the same scope (function) that you allocated it, then you have to do the indexing arithmetic yourself. Not a huge deal, but for the a array above, if you want to look at what would logically be a[i][j], then you would reference a[i * 3 + j], which is not as array-intuitive as a[i][j], and adding more indices makes things worse. Note that if you overdimension to be able to use your scientific c programmer trick, then you have to keep track of the real dimension used here. I have done a bunch of fft programming in c (sinking into fftw), and all this great stuff can be a pain. Okay, so what if you want to use a[i][j] instead? Well, to my knowledge, and loosely based on an example in Plum's book, you go through all the following: 1) Don't declare function prototypes (you can, but you will get a bunch of warnings). 2) Allocate the array in some outer scope (function) 3) Call a function of the form below, passing in the dimensions you want to use; I show a triple index example, just to stretch things, where the last index is a known constant, but the other two dimensions are derived from the caller. void do_something(i, j, array) int i, j; float array[i][j][3]; { reference array[ii][jj][0 to 2] over the range of ii = 0 to i-1 and jj = 0 to j-1 } Then there are the issues of confusion caused by situations where a[][] really is referencing an array of pointers. Now, this array of pointers data structure is a neat type of data structure, and it is sometimes pointed out that indexing arithmetic is simpler because you just indirect through the pointer and add the second index. True, but the novice user may not realize that is what is being done when s/he sees a ref of form a[][], and I guarantee that if you pass such an array to linear algebra, fft, or what have you library functions, you may not get exactly what you had in mind. So maybe there are things I don't know about all this, but from my perspective, this is all not exactly smooth and transparent for someone trying to do a bit of numeric array manipulation. I would concede that for many arrays that I use, the problem is relatively easy to solve through use of arrays of structures (say for coords, forces, or what have you), where the second C dimension is basically constant and implemented through a structure (say struct { float x, y, z }; ). However, there are a lot of things not covered by this. Allright, what does f90 look like in this regard? Well f77 was a pain because you could not do proper allocation, so you ended up allocating blocks of storage via an OS mechanism (say malloc) and passing the address of this stuff to subroutines or functions that referenced it as arrays. You could be unknowledgeable about the last array dimension instead of the first, but otherwise had to know how things were laid out in advance (works fine for 2d arrays of coords and what have you, but not everything). With f90, however, in any scope you can create an array to be indexed however you would like, of whatever dimensions you would like by specifying: real, allocatable :: array(:,:,:) and then calling: allocate(array(i,j,k), stat = statvar) This is perfectly general, and you can get i,j,k however you like whenever you like, and index this thing intuitively wherever you like. It is also possible to use what are called automatic arrays within a subroutine or function scope to essentially get scratch space of a size specified in the call interface. So, a subroutine of the general form: subroutine dosomething(i, j) implicit none real :: scratch(i, j) has an array of size i * j allocated on the stack or heap, depending on the compiler implementation, and this space will be automatically released on return (this is somewhat true for the allocate() statement too unless you specify save in the array declaration). The one problem with this mechanism is that if the stack is used, on some systems with a small stacksize limit you may get memory exceptions (so do a "limit stacksize unlimited" in your .login for csh, or what have you). This all seems a bit more intuitive and bulletproof to me, and I learned the other stuff first. I absolutely love the art and science of more complex data structures, and have been schooled in this area; a good array implementation is the appropriate data structure, however, in many instances in scientific code. >> 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. > Well, I pretty much make my living by making code fast for folks that care about such things, like the amber group. So I am aware of all these issues and basically agree. I think C can be less efficient in some scenarios if there is extensive use of indirection (pointers), depending somewhat on the architecture. I have particularly seen 2-fold differences in itanium performance caused by algorithms that don't stride regularly through arrays, but have to do some sort of indirection (pointer or offset) to get the next chunk of work. I agree that with care and a good compiler implementation you should come close with either language; the thing is that novices more often do something in C/C++ that screws up the performance. For somebody like me I guess it is an opportunity... Regards - Bob Duke> the strange characters on the top line to the * sign.> > E-mail to administrators: CHEMISTRY-REQUEST * ccl.net or us> > > > From owner-chemistry@ccl.net Wed Sep 28 12:14:53 2005 From: "CCL" To: CCL Subject: CCL: [CCL]: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29356-050928121137-18667-SaYOmtiFoITEvETWnau7Gg*_*server.ccl.net> X-Original-From: "Perry E. Metzger" Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Sep 2005 12:11:30 -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--. >>> 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. > > You can, but it is not easy. First you call malloc to create a > buffer; then you use embedded loops to assign pointers to the > beginning of each row. That is not true. I don't know why you would do what you say you have to do. It would be silly. You treat a dynamically allocated N by N array the way you treat a dynamically allocated struct or anything else. It is perfectly valid to do this: typedef double matrix[4][4]; matrix *foo; [...] foo = (matrix *)malloc(sizeof(matrix)); (*foo)[3][1] = 10.0; If you want, the [4][4] can be variables provided the typedef is inside a function declaration. Of course, it is very rare that you would want to do this anyway, since generally you would want an array to be part of a larger structure or to be dynamically allocated on the stack, but there is no reason you can't do it if you want to. > I don't think there is any question that Fortran 90's array features > are vastly superior to C's. For example, being able to add local > arrays to the stack ('automatic objects' is the Fortran terminology), > and deciding dimensions at run time, are very useful. You mean like this?: void foo(int i, int j) { double array[i][j]; ... } That's the allocation of an array at run time on the stack with whatever dimensions you like (passed at run time.) Could you please explain what it is that Fortran lets you do that C does not again? > C's array support is primitive, In what way, exactly? Is the issue here that you don't know enough C to know how to do this stuff? Perry From owner-chemistry@ccl.net Wed Sep 28 12:49:02 2005 From: "CCL" To: CCL Subject: CCL: Madelung or Klechkovski ? Message-Id: <-29357-050928120819-18489-dMQiKXppMqcjAdo/pg+6zw]*[server.ccl.net> X-Original-From: "Xavier ASSFELD" Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 28 Sep 2005 18:07:45 +0200 MIME-Version: 1.0 Sent to CCL by: "Xavier ASSFELD" [Xavier.Assfeld]*[cbt.uhp-nancy.fr] --Replace strange characters with the "at" sign to recover email address--. Dear CCLers, This is not a scientific question. This is an historico-scientific question! In france, in freshman chemistry, we teach that the energetic order of the atomic orbitals is given by the "Klechkovski rules" (or Klechkowski, or Klechkovsky, or even Klechkowsky). That is to say, the enegy increases as (n+l) increases and for a given value of (n+l) the energy increases as n, where n and l are the principal and azimutal quantum number. After a quick search, I've discovered that this name is also used in Belgium, in Swizterland, and in Canada. Surprizingly three french speaking countries... I have found from a Belarus site that it is the Madelung-Klechkovski rules! And in fact most english speaking countries seems to use the Madelung rules! I've found the Madelung ref : E. Madelung "Die Mathemaitschen Hilfsmittel des Physikers" 3rd ed. Springer, Berlin, 1936. Does someone knows the Klechkowski ref? Who is the "father" of the rules? Klechkovski or Madelung? Which name is used in orther countries for these rules? Yours. ...Xav Pr. Xavier Assfeld Xavier.Assfeld]*[cbt.uhp-nancy.fr Chimie et Biochimie théoriques T: (33) 3 83 68 43 82 Faculté des Sciences F: (33) 3 83 68 43 71 54506 Vandoeuvre, France http://www.cbt.uhp-nancy.fr From owner-chemistry@ccl.net Wed Sep 28 13:15:26 2005 From: "CCL" To: CCL Subject: CCL: About compiling Gaussian98 Message-Id: <-29358-050928131334-24513-W6JwP/u5Itz7S7Bx7y0iGQ[*]server.ccl.net> X-Original-From: "Fernando D. Vila" Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Date: Wed, 28 Sep 2005 09:26:53 -0700 (PDT) MIME-Version: 1.0 Sent to CCL by: "Fernando D. Vila" [fer[*]tiziano.phys.washington.edu] --Replace strange characters with the "at" sign to recover email address--. Look in the make you are using (likely i386.make). You should find a line that links g98, (something like g98: $(SOMETHING) $(SOMETHINGELSE)).In one of the following lines you should find one that has a "-o g98". Right before the "-o g98" add the following: -L/usr/lib/gcc-lib/i386-redhat-linux/3.2.3 -lg2c Check to see that you have the correct path to the path for the g2c library. It's likely that this will solve your problem with g98, but it will likely show up when you link the exe's. Try the same trick. Cheers, Fer. On Mon, 26 Sep 2005, CCL wrote: > Dear CLLers > 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 > util.so: the use of `tmpnam' is dangerous, better use `mkstemp' > util.so: undefined reference to `__ctype_b' > util.so: undefined reference to `wait_' > util.so: undefined reference to `fork_' > make: *** [g98] Error 1 > endif > > Can any expert tell me how I should go with this? > Thank you very much in advance! > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com Ubi dubium ibi libertas. ******************************************************************************* Fernando D. Vila Voice (206)543-9697 Department of Physics Fax (206)685-0635 University of Washington E-mail fdv[*]u.washington.edu Seattle, WA 98195, USA WWW http://faculty.washington.edu/fdv ******************************************************************************* From owner-chemistry@ccl.net Wed Sep 28 13:24:04 2005 From: "CCL" To: CCL Subject: CCL: Open source contributions by pharma. Message-Id: <-29359-050928132259-1885-QFVkWDEHn2hdPvFzobcALA- -server.ccl.net> X-Original-From: "Peter Spiro" content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C451.3A62BB52" Date: Wed, 28 Sep 2005 10:22:40 -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_01C5C451.3A62BB52 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Many thanks to those who sent examples of software contributed by pharma, and for the many thoughtful comments on the issue. =20 A number of you asked to see the final list. Below is the list of software, followed by a summary of people's comments. =20 Application Contributing Company Author Availability URL=20 RasMol GlaxoWellcome Roger Sayle open source http://www.umass.edu/microbio/rasmol/index2.htm OELib OpenEye, others Matt Stahl open source http://www.eyesopen.com/products/toolkits/oelib.html JME Novartis Peter Ertl free http://www.molinspiration.com/jme/ tpsa.c Novartis Ertl et al. open source http://www.daylight.com/meetings/emug00/Ertl/ =20 NEWLEAD Novartis Vincenzo Tschinko free http://www.ccl.net/cca/software/SGI/newlead/README.shtml Moloc Roche Paul Gerber fee (non-academics) http://www.moloc.ch MMFF94 Merck Thomas Halgren free http://ccl.net/cca/data/MMFF94/ Pgchem::tigress Bayer Ernst-Georg Schmid http://pgfoundry.org/projects/pgchem/ OpenBabel Merck (provided financial support) open source http://sourceforge.net/mailarchive/forum.php?thread_id=3D8125020&forum_id= =3D 3042 PyMOL Delano Scientific Warren DeLano open source http://pymol.sourceforge.net/ various java programs ChemAxon, others open source http://www.chemaxon.com/forum/ftopic193.html =20 Programs available for a "nominal" fee from the Quantum Chemistry Program Exchange ( http://qcpe.chem.indiana.edu), contributed form the 1970s through 2000s. Source code for 20 or so programs reportedly were contributed by industry.=20 PRODIS Abbott Low-Energy Conformations of Flexible Molecules=20 MOLSV Merck Molecular Volume and Surface Area Calculation=20 RNGCFM Merck Exploration of Medium-Size Ring Conformations=20 BIGSTRN-3 Merck General-Purpose Empirical Force-Field Program=20 SEA Merck Steric and Electrostatic Alignment Molecular Superposition Program=20 SEAL Merck An Alternate Method for the Alignment of Molecular Structures=20 SAMPLS Merck Sample Distance Partial Least Squares Program ("used to develop a structure-activity relationship (SAR) for any single response (i.e., biological activity), based on the "distance" between samples (e.g., chemical compounds) in a training set.")=20 NEWLEAD Novartis Generation of Candidte Structures=20 DGEOM DuPont,Chiron Distance Geomerty Program ("DGEOM is a distance geometry program for molecular model-building, receptor modeling, conformational analysis, and NMR solution structure determination")=20 MOLAREA Lilly Calculation of the Surface Area of a Non-Spherical Molecule or Molecular Cavity in a Fluid from the Van der Waals Radii of Component Atoms=20 USURF Upjohn Generation of Smooth Molecular Dot Surfaces=20 TRIBL DuPont (no longer available) A Complete Molecular Modeling Software System=20 =20 It was also noted that: - Many SPL scripts for Sybyl were developed/contributed by people in industry. These may not be "open source" in the usual sense, but SPL lends itself to reuse/translation into other languages. - Pharma has also provided significant contributions to bioinformatics open source projects.=20 =20 To summarize (and plagiarize) people's comments: =20 Benefits of contributing to open source: =20 - External improvements on contributed code -- if the code remains in-house, no external review or improvement is possible. This "piling on" effect is significant. - Control over product development -- does a particular software project meet your needs? Contribution to open software allows you to better address specific issues and target your projects. - Benefits from external maintenance -- if you maintain your own internal version, you will be constantly trying to keep up with the external official version. - Good publicity in the community, possible tax write-off benefits for charitable contributions. - Improved return on investment of resources:=20 - Increased benefit to the company when code is contributed to the community, since the company has use of the code, whether left in-house or donated. Thus others' contributions add value. =20 - It's easier to let an external group enhance and maintain it. - Open source fixes bugs better than commercial vendors, so presumably better than in-house code too.=20 - Continuity: Very often the code is associated with an individual.=20 - Maintenance can be continued when the developer leaves, benefitting the originating company. - This also benefits the developer, who can continue to use and develop the code afterwards.=20 =20 Possible concerns: =20 - reputation (the code could be seen to reflect on the company) - liability - maintenance (this is impossible to guarantee) - distribution - it is not always easy to find a site where the material can be mounted. - license (supporting Open source might be seen to be undermining their commercial vendors) - loss of IP =20 Counter-arguments: =20 - Reputation:=20 - The flip side is free advertising. - Contributions can always come from an isolated individual rather than being publicly blessed by the company. (However, initial software development is often done on company time, so belongs to the company.) =20 - Liability:=20 - The open source license itself restricts liability -- because the program is licensed free of charge, no warranty is express or implied. =20 - A code repository could be established where it was made it clear that there was no further implied commitment and that donation was accepted as a final act.=20 - Maintenance and distribution is handled by existing frameworks (i.e., the project you're contributing to).=20 - License: If a commercial software vendor is concerned about being undermined by an open source solution, then they have not made their case to clients. A commercial solution should provide a clear advantage over an open source solution.=20 - IP:=20 - Contributing software is no different from publishing scientific papers describing syntheses and new techniques, which pharma does all the time. =20 - There's very little IP "loss" in open source contributions. You or your company retains the original copyright. You can still sell commercial versions of that code. =20 - Many projects, while quite useful, don't make much use of proprietary knowledge, so the value of the protected IP would likely not be high.=20 =20 =20 -----Original Message----- > From: Peter Spiro=20 Sent: Monday, September 26, 2005 8:15 PM To: 'OpenBabel-discuss- -lists.sourceforge.net'; 'chminf-l- -listserv.indiana.edu'; 'chemistry- -server.ccl.net'; 'qsar_society- -accelrys.com' Subject: Open source contributions by pharma. 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_01C5C451.3A62BB52 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Many thanks to those = who sent=20 examples of software contributed by pharma, and for the many thoughtful = comments=20 on the issue.
 
A number of you asked = to see the=20 final list.  Below is the list of software, followed by a summary = of=20 people's comments.
 
Application Contributing Company Author        &nbs= p;    =20 Availability     URL 

RasMol     =20 GlaxoWellcome        = Roger=20 Sayle         = open=20 source      http://www.umass.edu/microbio/rasmol/index2.htm
OELib       = OpenEye,=20 others      = Matt=20 Stahl          = open=20 source      http://www.eyesopen.com/products/toolkits/oelib.html<= BR>JME        =20 Novartis        &nbs= p;   =20 Peter Ertl         =20 free        &nbs= p;    http://www.molinspiration.com/jme/
tpsa.c      = Novartis        &nbs= p;   =20 Ertl et al.         = open=20 source      http://www.daylight.com/meetings/emug00/Ertl/  
NEWLEAD     Novartis        &nbs= p;   =20 Vincenzo = Tschinko   free        &nbs= p;http://www.ccl.net/cca/software/SGI/newlead/README.shtml<= /A>
Moloc       Roche        &nbs= p;      =20 Paul Gerber        =20 fee (non-academics) http://www.moloc.ch
MMFF94      Merck&nbs= p;       &nbs= p;       Thomas=20 Halgren     =20 free        &nbs= p;    http://ccl.net/cca/data/MMFF94/
Pgchem::tigress Bayer        &nbs= p;  =20 Ernst-Georg Schmid         &nbs= p;         http://pgfoundry.org/projects/pgchem/
OpenBabel   Merck (provided financial=20 support)      =20 open source      http://sourceforge.net/mailarchive/forum.php?thread_id=3D8125020= &forum_id=3D3042
PyMOL       Delano=20 Scientific    = Warren=20 DeLano      =20 open source      http://pymol.sourceforge.net/
various java programs ChemAxon,=20 others        &nbs= p;     =20 open source      http://www.chemaxon.com/forum/ftopic193.html
 
Programs available for = a "nominal"=20 fee from the Quantum Chemistry Program Exchange (http://qcpe.chem.indiana.edu), = contributed form the 1970s through 2000s.  Source code for 20 or so = programs reportedly were contributed by industry. 
PRODIS    Abbott        =20 Low-Energy Conformations of Flexible = Molecules 
MOLSV     Merck        &nbs= p;=20 Molecular Volume and Surface Area = Calculation 
RNGCFM    Merck        &nbs= p;=20 Exploration of Medium-Size Ring=20 Conformations 
BIGSTRN-3 Merck        &nbs= p;=20 General-Purpose Empirical Force-Field=20 Program 
SEA       = Merck        &nbs= p;=20 Steric and Electrostatic Alignment Molecular Superposition=20 Program 
SEAL      = Merck        &nbs= p;=20 An Alternate Method for the Alignment of Molecular=20 Structures 
SAMPLS   =20 Merck        &nbs= p;=20 Sample Distance Partial Least Squares Program ("used to develop a = structure-activity relationship (SAR) for any single response (i.e., = biological=20 activity), based on the "distance" between samples (e.g., chemical = compounds) in=20 a training set.") 
NEWLEAD  =20 Novartis       Generation of = Candidte=20 Structures 
DGEOM    =20 DuPont,Chiron  = Distance=20 Geomerty Program ("DGEOM is a distance geometry program for molecular=20 model-building, receptor modeling, conformational analysis, and NMR = solution=20 structure determination") 
MOLAREA   Lilly        &nbs= p;=20 Calculation of the Surface Area of a Non-Spherical Molecule or = Molecular=20 Cavity in a Fluid from the Van der Waals Radii of Component=20 Atoms 
USURF    =20 Upjohn        &nbs= p;Generation=20 of Smooth Molecular Dot Surfaces 
TRIBL     DuPont (no longer available) A Complete = Molecular=20 Modeling Software System 
 
It was also noted = that:
- Many SPL scripts for = Sybyl were=20 developed/contributed by people in industry.  These may not be = "open=20 source" in the usual sense, but SPL lends itself to reuse/translation = into other=20 languages.
- Pharma has also provided significant contributions to=20 bioinformatics open source projects. 
 

To summarize (and plagiarize) people's comments:
 
Benefits of contributing to open source:
 
- External improvements on contributed code -- if the code remains=20 in-house, no external review or improvement is possible. This "piling = on" effect=20 is significant.
- Control over product development -- does a = particular=20 software project meet your needs? Contribution to open software allows = you to=20 better address specific issues and target your projects.
- Benefits = > from=20 external maintenance -- if you maintain your own internal version, you = will be=20 constantly trying to keep up with the external official version.
- = Good=20 publicity in the community, possible tax write-off benefits for = charitable=20 contributions.
- Improved return on investment of resources: =
  -=20 Increased benefit to the company when code is contributed to the = community,=20 since the company has use of the code, whether left in-house or = donated. =20 Thus others' contributions add value. 
  - It's easier to = let an=20 external group enhance and maintain it.
  - Open source fixes = bugs=20 better than commercial vendors, so presumably better than in-house code = too.=20
- Continuity: Very often the code is associated with an individual.=20
  - Maintenance can be continued when the developer leaves, = benefitting=20 the originating company.
  - This also benefits the developer, = who can=20 continue to use and develop the code afterwards.
 
Possible concerns:
 
- reputation (the code could be seen to reflect on the = company)
-=20 liability
- maintenance (this is impossible to guarantee)
- = distribution -=20 it is not always easy to find a site where the material can be = mounted.
-=20 license (supporting Open source might be seen to be undermining their = commercial=20 vendors)
- loss of IP
 
Counter-arguments:
 
- Reputation:
  - The flip side is free = advertising.
  -=20 Contributions can always come from an isolated individual rather than = being=20 publicly blessed by the company.  (However, initial software = development is=20 often done on company time, so belongs to the company.) 
- = Liability:=20
  - The open source license itself restricts liability -- = because the=20 program is licensed free of charge, no warranty is express or = implied. =20
  - A code repository could be established where it was made it = clear=20 that there was no further implied commitment and that donation was = accepted as a=20 final act.
- Maintenance and distribution is handled by existing = frameworks=20 (i.e., the project you're contributing to).
- License: If a = commercial=20 software vendor is concerned about being undermined by an open source = solution,=20 then they have not made their case to clients.  A commercial = solution=20 should provide a clear advantage over an open source solution.
- IP: =
  - Contributing software is no different from publishing = scientific=20 papers describing syntheses and new techniques, which pharma does all = the=20 time. 
  - There's very little IP "loss" in open source=20 contributions. You or your company retains the original copyright. You = can still=20 sell commercial versions of that code. 
  - Many projects, = while=20 quite useful, don't make much use of proprietary knowledge, so the value = of the=20 protected IP would likely not be high.
 

 
-----Original Message-----
From: Peter Spiro =
Sent:=20 Monday, September 26, 2005 8:15 PM
To:=20 'OpenBabel-discuss- -lists.sourceforge.net'; = 'chminf-l- -listserv.indiana.edu';=20 'chemistry- -server.ccl.net'; = 'qsar_society- -accelrys.com'
Subject:=20 Open source contributions by pharma.

Hello = all,

 

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

 

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

 

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

 

Are there=20 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_01C5C451.3A62BB52-- From owner-chemistry@ccl.net Wed Sep 28 14:09:18 2005 From: "CCL" To: CCL Subject: CCL: NMR calculation Message-Id: <-29360-050928124056-12392-6wh0IGZ9or7AyzimESmmTg:+:server.ccl.net> X-Original-From: "J.Aires de Sousa" Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=windows-1252; format=flowed Date: Wed, 28 Sep 2005 16:40:47 +0100 MIME-Version: 1.0 Sent to CCL by: "J.Aires de Sousa" [jas:+:fct.unl.pt] --Replace strange characters with the "at" sign to recover email address--. Dear Senthilnathan the SPINUS web service generates fast predictions of H NMR chemical shifts from the molecular structure: http://www.dq.fct.unl.pt/spinus http://www2.chemie.uni-erlangen.de/services/spinus It is a neural networks-based method. For references about the method please see J. Aires-de-Sousa, M. Hemmer, J. Gasteiger, “Prediction of 1H NMR Chemical Shifts Using Neural Networks”, Analytical Chemistry, 2002, 74(1), 80-90. Y. Binev, J. Aires-de-Sousa, "Structure-Based Predictions of 1H NMR Chemical Shifts Using Feed-Forward Neural Networks", J. Chem. Inf. Comp. Sci., 2004, 44(3), 940-945. Y. Binev, M. Corvo, J. Aires-de-Sousa, "The Impact of Available Experimental Data on the Prediction of 1H NMR Chemical Shifts by Neural Networks", J. Chem. Inf. Comp. Sci., 2004, 44(3), 946-949. For standalone versions please contact MolNet (http://www.mol-net.com) -- Dr. Joao Aires de Sousa Departamento de Quimica, Faculdade de Ciencias e Tecnologia, Universidade Nova de Lisboa, 2829-516 Caparica, Portugal Tel: (+351) 21 2948300 x10986 Fax: (+351) 21 2948550 Email: jas_at_fct.unl.pt www: http://www.dq.fct.unl.pt/staff/jas/ CCL wrote: > 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 From owner-chemistry@ccl.net Wed Sep 28 14:25:07 2005 From: "CCL" To: CCL Subject: CCL: [CCL]: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29361-050928141314-3744-iBf92X4AFubLX7Dx+3n0BQ\a/server.ccl.net> X-Original-From: "Perry E. Metzger" Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Sep 2005 14:13:10 -0400 MIME-Version: 1.0 Sent to CCL by: "Perry E. Metzger" [perry\a/piermont.com] --Replace strange characters with the "at" sign to recover email address--. One lst round here. >> You can allocate a multidimensional array dynamically in C and index >> it just like you index any other array. > > Okay, maybe there is something I don't know here, so feel free to > enlighten me, but I think setup is a bit more complex, and the > potential for screwups is higher. Let's go through my understanding > of the differences between the two languages in this domain. Okay... > Multidimensional C arrays > > Static arrays are of course easy. You declare something like: > > float a[200][3]; > > and off you go, able to index into this array with the 3 subscript > varying most rapidly. Of course this is the reverse of the more > common fortran index order, Actually, the Fortran order is used mostly by Fortran at this point. It doesn't really matter though in the sense that you don't have to actually care which subscript varies most rapidly in most numerical algorithms. The only time I've had to care was 25 years ago when I had an array in memory simulating a huge frame buffer (far bigger than RAM) and if you strode the array the wrong way you took a page fault for every stride. That sort of thing doesn't happen any more and if it did, it is easily understood and avoided. > and array subscripts start at 0, and both of these facts have a > certain amount of nuisance value that should not be overlooked as a > point of pain in a port. It is true that C arrays start at 0. I don't think that's an inherent issue, that's just a matter of taste. The reason for the definition makes sense when you consider that [] is an operator. > However, say you don't know ahead of time what the dimensions for the > array will be. Well, of course you just malloc() (ie., allocate) an > array and use it, right? Or use a dynamic array on the stack, yes. > Well, yes, but if you want to use the array in the same scope > (function) that you allocated it, then you have to do the indexing > arithmetic yourself. No, you don't. Really. I understand that your references told you that you did, but for malloc that's never been true and for allocations on the stack that hasn't been true in some time. There are two ways to deal with this. First, there is the way if you want to do something that doesn't live beyond the current scope: void foo(int i, int j) { double a[i][j]; /* and then just use a the way you like... */ a[3][2] = 10.3; /* bad code, since i and j might be, say 1, but it demonstrates my pont. */ } That's been around for quite some time but it has only recently been burned into the standard. Every compiler you can get supports it -- try it on a late model gcc or Microsoft C or whatever and it will just work. "Try it." Then there is what happens if you want to dynamically allocate an array at run time using malloc. Recall that what malloc returns to you is a POINTER to an object. Thus, if you were going to malloc a struct, you would do: struct stype { int a; int b}; struct stype *foo; foo = malloc(sizeof(struct stype)) and you would do (*foo).a or foo->a to get at the a member of the dynamically allocated structure. Therefore, the equivalent for an array is: typedef float dynarray[10][10][10]; dynarray d; d = malloc(sizeof(dynarray)); and later f = (*d)[5][5][5]; will work just fine. Always has -- probably would work on the oldest C compilers you could possibly run. One problem is many programmers don't understand the difference between C's arrays and pointers -- they think of arrays as pointers and pointers as arrays merely because you can apply the [] operator to a pointer. (I try to explain this explicitly when I'm teaching someone.) As a result, some folks don't get that to do the indexing correctly the machine has to be informed of the type. It can be informed at run time -- you can do that typedef with variables as indexes inside a function declaration -- but you can't lie to the compiler or it will take its revenge. If you tell the truth to the compiler, it will do what you want. People that don't understand this would try d[5][5][5]; which does not mean the same thing at all! Extra credit for readers who can articulate what it does mean. (Hint -- there are implied arrays of "dynarray"s in this example.) You can argue that needing to do (*d)[5][5][5] instead of d[5][5][5] is a defect in the language. I'd disagree -- if you are fussing with pointers and heap allocation, you want pointers and pointer dereference, and if you aren't explicit about that you're not telling the computer what you want it to do (or, more to the point, preventing it from doing what you actually want). That's the price you pay when you allocate a struct, too. If you are looking for allocating a temporary dynamic array on the stack, of course, you get an array, not a pointer to an array. > Well, to my knowledge, and loosely based on an example in Plum's book, > you go through all the following: That's not strictly correct. I've appended a sample program at the end. Compile it and run it on your favorite C compiler. You will get the expected output when you run it. > So maybe there are things I don't know about all this, but from my > perspective, this is all not exactly smooth and transparent for > someone trying to do a bit of numeric array manipulation. Well, see my attached sample. > With f90, however, in any scope you can create an array to be indexed > however you would like, of whatever dimensions you would like by > specifying: C isn't particularly different. The syntax is just a bit different (as seen above and below). > It is also possible to use what are called automatic arrays within a > subroutine or function scope to essentially get scratch space of a > size specified in the call interface. So, a subroutine of the general > form: > > subroutine dosomething(i, j) > > implicit none > > real :: scratch(i, j) C lets you do exactly the same (see above and below). >>> 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. > > Well, I pretty much make my living by making code fast for folks that > care about such things, like the amber group. So I am aware of all > these issues and basically agree. I think C can be less efficient in > some scenarios if there is extensive use of indirection (pointers), > depending somewhat on the architecture. Yup, you're right. You have to be careful not to confuse the compiler with excessive pointer aliasing. If you do, you lose. You can get around it with "restrict", but it is certainly a defect of weak typing. That's one reason I don't claim C is my favorite language for this sort of thing -- just better (IMHO) than many other beasts. > I have particularly seen 2-fold differences in itanium performance > caused by algorithms that don't stride regularly through arrays, but > have to do some sort of indirection (pointer or offset) to get the > next chunk of work. Be careful there. Consider how inconsistent and bad Itanium compilers are. (It is the problem with having an architecture that throws so much work onto the compiler writer. There is a reason the architecture has died.) There is also the issue of whether you're getting cache misses -- that's always a bad one. However, I agree that if you ask the compiler to do something foolish you can hurt yourself -- but that's true of any language including Fortran. One favorite example of mine is this: Teachers often (mistakenly) teach their students to build hash tables by making the table length a prime number to exploit the same properties linear congruential number generators exploit. Thus, you would make your table, say, 97 buckets long and do: hashval = foo % 97; to calculate the bucket you want. This is, in fact, a bad idea. It is true that you get somewhat better distribution of buckets by doing the mod prime operation, but under the covers, mod requires that you do an integer division, which often takes close to 20 cycles. Doing a simple shift takes one cycle. Thus, doing a table that is an exact power of 2 means that your hash function takes 15 or 25 times less time to compute. That is usually a big win in terms of constant factors, even if you have to climb a link or two extra in an open hash table. What's the problem here? Assuming that just because % and >> are single operators that they both take the same length of time. Perry -------------------- Sample C program #include #include typedef float dynarray[10][10][10]; void testme(int i, int j) { double a[i][j]; a[1][2] = 5.0; printf("double is: %f\n", a[1][2]); } int main(int argc, char **argv) { dynarray *d; float f; d = malloc(sizeof(dynarray)); (*d)[5][5][5] = 10.0; f = (*d)[5][5][5]; printf("float is: %f\n", f); testme(6, 6); } -------------------- Sample Output: $ cc -o foo foo.c $ ./foo float is: 10.000000 double is: 5.000000 $ From owner-chemistry@ccl.net Wed Sep 28 15:00:00 2005 From: "CCL" To: CCL Subject: CCL: Fortran vs. C - when will it end? Message-Id: <-29362-050928131555-25455-UGblJhHCRhLlm/aY0tUb9g_-_server.ccl.net> X-Original-From: Heidi Rohwer Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Date: Wed, 28 Sep 2005 18:13:04 +0200 MIME-Version: 1.0 Sent to CCL by: Heidi Rohwer [heidi.rohwer_-_aci.uni-heidelberg.de] --Replace strange characters with the "at" sign to recover email address--. The issue is not whether Fortran is better or worse than C, C++ or whatever else you want to bring into the whole argument, but whether this whole discussion is (a) productive and (b) relevant to this mailing list. It would seem to be the answer to both questions is no. How about we get back to relevant and productive discussions about computational chemistry? At the very least continue the discussion via private emails and don't clutter up the rest of our mailboxes. Regards Heidi From owner-chemistry@ccl.net Wed Sep 28 15:00:10 2005 From: "CCL" To: CCL Subject: CCL: NMR calculation Message-Id: <-29364-050928130920-24310-1wCKvmSnU7tlag1c+f4wEQ[]server.ccl.net> X-Original-From: zborowsk[]chemia.uj.edu.pl Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-2 Date: Wed, 28 Sep 2005 18:21:20 +0200 (CEST) MIME-Version: 1.0 Sent to CCL by: zborowsk[]chemia.uj.edu.pl --Replace strange characters with the "at" sign to recover email address--. Hi > > Sent to CCL by: Adan Gonzalez Perez [adagonzalez(!)alumnos.uvigo.es] > > --Replace strange characters with the "at" sign to recover email > address--. > > CCL wrote: > >>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>To send e-mail to subscribers of CCL put the >> string CCL: on your Subject: line and send your message to: >> CHEMISTRY[]ccl.net >> >>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 use the Web based form from CCL Home Page> >> >> >> >> > Hi Senthilnathan; > > I use to calculate NMR of organic compounds in gaussian03, (I think that > in g98 exist the keyword too) , I don't know whether it's the best > theoretical method to this kind of calculation but I work with it and it > works. Put NMR=giao at the input file after the method and basis set . GIAO is default method for NMR calculations in Gaussian So you can write NMR only (without giao) and the output should be the same Maybe this method is not the best but it is quite good But before you have to optimize the geometry of your molecules Best regards > > You can find more information about this method and other similar in the > gaussian home page http://www.gaussian.com/g_ur/k_nmr.htm . > > Best regards> the strange characters on the top line to the [] sign.> > E-mail to administrators: CHEMISTRY-REQUEST[]ccl.net or us-- Krzysztof Zborowski Faculty of Chemistry Jagiellonian University 3 Ingardena Street 30-060 Krakow Poland phone: +48(12)632-4888 ext. 2064 or 2067 fax: +48(12)634-05-15 email: zborowsk[]chemia.uj.edu.pl ICQ 158385743 gg 3817259 skype kzys70 From owner-chemistry@ccl.net Wed Sep 28 15:00:10 2005 From: "CCL" To: CCL Subject: CCL: [CCL]: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29367-050928145644-25803-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: Wed, 28 Sep 2005 14:56:32 -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--. In response to Perry's response to Drew's email..., embedded again. Regards - Bob Duke ----- Original Message ----- > From: "CCL" To: "Duke, Robert E " Sent: Wednesday, September 28, 2005 12:11 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--. > > >>>> 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. >> >> You can, but it is not easy. First you call malloc to create a >> buffer; then you use embedded loops to assign pointers to the >> beginning of each row. > > That is not true. It is not true that it is the only way to solve the problem. It is, however, a mechanism suggested in books and on the web for solving the c multidimensional array problem, so it may seem a little silly at some levels, but at other levels it is in perfect keeping with the c idiom of arrays of pointers. > > I don't know why you would do what you say you have to do. It would be > silly. You treat a dynamically allocated N by N array the way you > treat a dynamically allocated struct or anything else. > > It is perfectly valid to do this: > > typedef double matrix[4][4]; > > matrix *foo; > > [...] > > foo = (matrix *)malloc(sizeof(matrix)); > > (*foo)[3][1] = 10.0; > > If you want, the [4][4] can be variables provided the typedef is > inside a function declaration. This just moves the mechanism I showed into a typedef, though it allows use of the fully indexed, but still a little awkward reference style shown above in the scope in which the array was created. Fortran still is easier to read. > > Of course, it is very rare that you would want to do this anyway, > since generally you would want an array to be part of a larger > structure or to be dynamically allocated on the stack, but there is no > reason you can't do it if you want to. > Very rare? I need really big dynamic arrays at various scope levels all the time. I prefer to not have to worry about all this stuff right at the various levels, and all these mechanisms are subject to the index limits getting modified, which will screw things up nicely. This is of course also true of auto arrays, be it in c or fortran. >> I don't think there is any question that Fortran 90's array features >> are vastly superior to C's. For example, being able to add local >> arrays to the stack ('automatic objects' is the Fortran terminology), >> and deciding dimensions at run time, are very useful. > > You mean like this?: > > void foo(int i, int j) > { > double array[i][j]; > > .. > } > Yes, good point above, that the auto array facility is essentially available in c, though I think I only found it doc'd in a compiler manual sometime in the late '90's, and I also remember that there were c compilers somewhere in my past on which I could not do this (ancient irrelevant history, I admit, but I didn't bring up the c auto arrays parallel because I was fuzzy about the extent of support; if gcc does it, that is pretty much all it takes). > That's the allocation of an array at run time on the stack with > whatever dimensions you like (passed at run time.) > > Could you please explain what it is that Fortran lets you do that C > does not again? > As I recall, the original thrust of this conversation was the other way around - look at what you can do in c that you cannot do in fortran; my point was that for numeric programming, there is very little that I can do in c that I cannot do as well or better in fortran 90/95, and the pain involved in porting the code is significantly less. I have no argument with anyone about other domains; just domains where numeric processing predominates and efficiency matters. I had rather work in c/c++ from the perspective of future job prospects in the general computing milieux; however I choose to evaluate each project in terms of its unique characteristics, and access the benefits and detriments of porting to different languages based on that and not on whether I want to write in a particular language. >> C's array support is primitive, > > In what way, exactly? > > Is the issue here that you don't know enough C to know how to do this > stuff? Well, not to get personal here, but I will take exception to you saying that to Drew; the Stroustrup c++ bible goes on for about a half page (fine type) about how low-level, or primitive, the notion of the array is in c, and I can find similar statements in other books on the subject. It is a bare-bones facility. If you revel in writing something closer to assembler, fine. If you really like c++, you can create classes to cover the weaknesses, but they will most likely not be as efficient as an embedded implementation where the compiler generates the assembler. If you just want to get the job done, it will be both easier and less error prone with a more complete array implementation. It should not be difficult to figure out how to do this stuff in a language intended for numeric computation, and it IS difficult, a number of the things we have discussed aren't covered in K&R, Stroustrup, or a variety of texts. I am done flooding the list with this stuff; I'll reply to anything further directly. Bob > > Perry> > > > From owner-chemistry@ccl.net Wed Sep 28 15:00:12 2005 From: "CCL" To: CCL Subject: CCL: Crystal Morphology Software Message-Id: <-29366-050928133952-14052-cKmcLDjeBa4+HagYXhcEfA(_)server.ccl.net> X-Original-From: Aaron Deskins Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Date: Wed, 28 Sep 2005 12:39:47 -0500 MIME-Version: 1.0 Sent to CCL by: Aaron Deskins [ndeskins(_)purdue.edu] --Replace strange characters with the "at" sign to recover email address--. CCL wrote: >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 > > Thank you for the information. I'll have to see if someone here at our University has access to the software. Does anyone by chance know a free software that will do something similar? Aaron Deskins Chemical Engineering Purdue University From owner-chemistry@ccl.net Wed Sep 28 15:00:11 2005 From: "CCL" To: CCL Subject: CCL: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29365-050928143152-12477-vtWbBYciVCbXBg/QELHZqA++server.ccl.net> X-Original-From: Matthew Sundling Content-Disposition: inline Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Sep 2005 13:17:39 -0400 Mime-Version: 1.0 Sent to CCL by: Matthew Sundling [sundlm++rpi.edu] --Replace strange characters with the "at" sign to recover email address--. > Sent to CCL by: "Dr. N. SUKUMAR" [nagams__rpi.edu] > > 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" "Dreaming" up abstractions, especially when they are functional, flexible, useful and fast, is not just for the praise of comp-sci. folks (though, that alone is prize enough), but for the ability to have robust, trustworthy and effective [scientific] software to help solve your chemistry needs. If you are interested in quickly attacking a chemistry problem, for proof of concept or other reasons, I agree sometimes too much focus is placed on the elegance of the software, rather than what it is supposed to do. On the other hand, having [advanced] knowledge on several programming languages (perl, C/C++, fortran, java, Python, etc...) and [advanced] knowledge of practical computer science, you can simultaneously solve your problem and make the software elegant, functional, portable, and efficient. I'm not talking about dinky scripts meant to do housekeeping and minor operations... use whatever you need to complete the job ASAP. But there is value in doing more than the bare minimum to just "get the job done", regardless of the programming language. (P.S. To all, I was trained as a computer scientist (B.S./M.S.), and am now earning my Ph.D in chemistry partially under the guidance of Dr. N. Sukumar...) From owner-chemistry@ccl.net Wed Sep 28 15:00:11 2005 From: "CCL" To: CCL Subject: CCL: [CCL]: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29368-050928134310-15867-byAiheIJ0PvtLKwabX0OQA{:}server.ccl.net> X-Original-From: Paul.M.Mathias{:}fluor.com Content-Type: multipart/alternative; boundary="=_alternative 005D2C698825708A_=" Date: Wed, 28 Sep 2005 09:58:54 -0700 MIME-Version: 1.0 Sent to CCL by: Paul.M.Mathias{:}fluor.com --Replace strange characters with the "at" sign to recover email address--. This is a multipart message in MIME format. --=_alternative 005D2C698825708A_= Content-Type: text/plain; charset="us-ascii" The discussion into the arcane issues of computer science highlights the truth of Tip O'Neill's observation: "All politics is local." For non-Americans, Tip O'Neill, is a famous congressman from Massachusetts: http://bioguide.congress.gov/scripts/biodisplay.pl?index=o000098 For those of us who use computers as a tool and do less and less of detailed programming, much the discussion gets lost in the fog of arcane details. Nevertheless, the important interplay among value, familiarity, timing and subjective preference has been nicely revealed. It may be useful to put the discussion in a larger context and come up with a list of successful technologies. My partial list of successful technologies: - Electricity (Questioner: "What good is it?" Faraday: "Someday, Sir Prime Minister, you will be able to generate substantial revenues by taxing it.") - Telephone (talking is our best communication; cell phones have provided "anywhere" access) - TV - Email (works from informal hellos to formal communication) - English (Yes! the criteria of success have been ability to expand and universal acceptance) - Office software (what did we do without it; the hated MS has created the tools so that I can send sophisticated electronic communication to just about anyone on the planet) If 10 people are asked to list 6 successful technologies, there will likely be 50 different answers. But a common thread will be that all entries on the list will be some combination of sound thinking, hard word, good business acumen, timing and luck. The other conclusion, I guess, will be that the successful technologies will have a clear win that can be easily perceived by the generalist. By this criterion, C and Fortran are equally successful, or there is a clear win for computer science and molecular modeling. To paraphrase Tip: "All differences between C and Fortran are local." Paul Mathias "CCL" Sent by: owner-chemistry{:}ccl.net 09/28/2005 08:01 AM Please respond to "CCL Subscribers" To: "Mathias, Paul M. " cc: Subject: CCL: [CCL]: Cleaning up dusty deck fortran and converting to C/C++ . Sent to CCL by: "Robert Duke" [rduke * email.unc.edu] --Replace strange characters with the "at" sign to recover email address--. Okay, folks, one last round of clarifications, really, with emphasis on issues of multidimensional arrays in C vs. Fortran. Comments embedded below as appropriate. Regards - Bob Duke ----- Original Message ----- > From: "CCL" To: "Duke, Robert E " Sent: Tuesday, September 27, 2005 11:56 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--. > > >> 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. That was a simile. B was the precursor to C, and B itself was preceded by BCPL; this was the evolutionary sequence for C, and the precedents were in no way as desirable to use as C. > > 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. Really? Doesn't it depend on a number of factors as to whether you are better off moving to something else? Isn't that a lot of what this discussion is about? > >> 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. > Well, I do very much like C++, but otherwise I totally agree with what you say here, and I have always advocated that an appropriate subset of the language be used, and that the language be used by individuals who are focused purely on software development. I used it a lot through much of the 90's while working on both Windows NT and Exchange development at Microsoft. It was very nice to use in that environment, and despite initial performance concerns, we worked out ways to insure the high levels of performance required for OS dev. A real pain, however, is subtle differences in the meaning of some things, like const, in C vs. C++. >> 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. > Okay, maybe there is something I don't know here, so feel free to enlighten me, but I think setup is a bit more complex, and the potential for screwups is higher. Let's go through my understanding of the differences between the two languages in this domain. My understanding of C/C++ may be a little dated in this regard, so inform me if c99 has introduced new capabilities that make this less onerous. My standard c/c++ references are: K & R - of course Plum - "Reliable Data Structures in C" Ellis & Stroustrup - "The Annotated C++ Reference Manual" - This was the C++ bible when I was at Microsoft, and for those that don't know C++ is Stroustrup's baby. Multidimensional C arrays Static arrays are of course easy. You declare something like: float a[200][3]; and off you go, able to index into this array with the 3 subscript varying most rapidly. Of course this is the reverse of the more common fortran index order, and array subscripts start at 0, and both of these facts have a certain amount of nuisance value that should not be overlooked as a point of pain in a port. There is a common trick in the scientific community of overallocating by 1 in all dimensions and starting your indexing at 1 (ie., don't use the 0 element). Aside from wasting space (probably not a huge deal in many domains), this practice creates C that is not idiomatic, and when a real C programmer comes along s/he will be driven nuts, and worse, may mix conventions on you, resulting in a number of interesting problems down the line (it may be inferred that I am not behind this practice - if you are going to write C, learn to write C, darn it). However, say you don't know ahead of time what the dimensions for the array will be. Well, of course you just malloc() (ie., allocate) an array and use it, right? Well, yes, but if you want to use the array in the same scope (function) that you allocated it, then you have to do the indexing arithmetic yourself. Not a huge deal, but for the a array above, if you want to look at what would logically be a[i][j], then you would reference a[i * 3 + j], which is not as array-intuitive as a[i][j], and adding more indices makes things worse. Note that if you overdimension to be able to use your scientific c programmer trick, then you have to keep track of the real dimension used here. I have done a bunch of fft programming in c (sinking into fftw), and all this great stuff can be a pain. Okay, so what if you want to use a[i][j] instead? Well, to my knowledge, and loosely based on an example in Plum's book, you go through all the following: 1) Don't declare function prototypes (you can, but you will get a bunch of warnings). 2) Allocate the array in some outer scope (function) 3) Call a function of the form below, passing in the dimensions you want to use; I show a triple index example, just to stretch things, where the last index is a known constant, but the other two dimensions are derived from the caller. void do_something(i, j, array) int i, j; float array[i][j][3]; { reference array[ii][jj][0 to 2] over the range of ii = 0 to i-1 and jj = 0 to j-1 } Then there are the issues of confusion caused by situations where a[][] really is referencing an array of pointers. Now, this array of pointers data structure is a neat type of data structure, and it is sometimes pointed out that indexing arithmetic is simpler because you just indirect through the pointer and add the second index. True, but the novice user may not realize that is what is being done when s/he sees a ref of form a[][], and I guarantee that if you pass such an array to linear algebra, fft, or what have you library functions, you may not get exactly what you had in mind. So maybe there are things I don't know about all this, but from my perspective, this is all not exactly smooth and transparent for someone trying to do a bit of numeric array manipulation. I would concede that for many arrays that I use, the problem is relatively easy to solve through use of arrays of structures (say for coords, forces, or what have you), where the second C dimension is basically constant and implemented through a structure (say struct { float x, y, z }; ). However, there are a lot of things not covered by this. Allright, what does f90 look like in this regard? Well f77 was a pain because you could not do proper allocation, so you ended up allocating blocks of storage via an OS mechanism (say malloc) and passing the address of this stuff to subroutines or functions that referenced it as arrays. You could be unknowledgeable about the last array dimension instead of the first, but otherwise had to know how things were laid out in advance (works fine for 2d arrays of coords and what have you, but not everything). With f90, however, in any scope you can create an array to be indexed however you would like, of whatever dimensions you would like by specifying: real, allocatable :: array(:,:,:) and then calling: allocate(array(i,j,k), stat = statvar) This is perfectly general, and you can get i,j,k however you like whenever you like, and index this thing intuitively wherever you like. It is also possible to use what are called automatic arrays within a subroutine or function scope to essentially get scratch space of a size specified in the call interface. So, a subroutine of the general form: subroutine dosomething(i, j) implicit none real :: scratch(i, j) has an array of size i * j allocated on the stack or heap, depending on the compiler implementation, and this space will be automatically released on return (this is somewhat true for the allocate() statement too unless you specify save in the array declaration). The one problem with this mechanism is that if the stack is used, on some systems with a small stacksize limit you may get memory exceptions (so do a "limit stacksize unlimited" in your .login for csh, or what have you). This all seems a bit more intuitive and bulletproof to me, and I learned the other stuff first. I absolutely love the art and science of more complex data structures, and have been schooled in this area; a good array implementation is the appropriate data structure, however, in many instances in scientific code. >> 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. > Well, I pretty much make my living by making code fast for folks that care about such things, like the amber group. So I am aware of all these issues and basically agree. I think C can be less efficient in some scenarios if there is extensive use of indirection (pointers), depending somewhat on the architecture. I have particularly seen 2-fold differences in itanium performance caused by algorithms that don't stride regularly through arrays, but have to do some sort of indirection (pointer or offset) to get the next chunk of work. I agree that with care and a good compiler implementation you should come close with either language; the thing is that novices more often do something in C/C++ that screws up the performance. For somebody like me I guess it is an opportunity... Regards - Bob Duke> the strange characters on the top line to the {:} sign.> > E-mail to administrators: CHEMISTRY-REQUEST{:}ccl.net or ushttp://www.ccl.net/cgi-bin/ccl/send_ccl_message----------------------------------------------------------------------------------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, business-confidential and/or privileged material. If you are not the intended recipient of this message you are hereby notified that any use, review, retransmission, dissemination, distribution, reproduction or any action taken in reliance upon this message is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Any views expressed in this message are those of the individual sender and may not necessarily reflect the views of the company. ------------------------------------------------------------------------------------------------------- --=_alternative 005D2C698825708A_= Content-Type: text/html; charset="us-ascii"
The discussion into the arcane issues of computer science highlights the truth of Tip O'Neill's observation: "All politics is local."

For non-Americans, Tip O'Neill, is a famous congressman from Massachusetts:

http://bioguide.congress.gov/scripts/biodisplay.pl?index=o000098

For those of us who use computers as a tool and do less and less of detailed programming, much the discussion gets lost in the fog of arcane details.  Nevertheless, the important interplay among value, familiarity, timing and subjective preference has been nicely revealed.  It may be useful to put the discussion in a larger context and come up with a list of successful technologies.  

My partial list of successful technologies:

-  Electricity (Questioner: "What good is it?"  Faraday:  "Someday, Sir Prime Minister, you will be able to generate substantial revenues by taxing it.")
-  Telephone (talking is our best communication; cell phones have provided "anywhere" access)
-  TV
-  Email (works from informal hellos to formal communication)
-  English (Yes! the criteria of success have been ability to expand and universal acceptance)
-  Office software (what did we do without it; the hated MS has created the tools so that I can send sophisticated electronic communication to just about anyone on the planet)

If 10 people are asked to list 6 successful technologies, there will likely be 50 different answers.  But a common thread will be that all entries on the list will be some combination of sound thinking, hard word, good business acumen, timing and luck.  The other conclusion, I guess, will be that the successful technologies will have a clear win that can be easily perceived by the generalist.  By this criterion, C and Fortran are equally successful, or there is a clear win for computer science and molecular modeling.  To paraphrase Tip: "All differences between C and Fortran are local."

Paul Mathias




"CCL" <owner-chemistry{:}ccl.net>
Sent by: owner-chemistry{:}ccl.net
09/28/2005 08:01 AM
Please respond to "CCL Subscribers"
       
        To:        "Mathias, Paul M. " <paul.m.mathias{:}fluor.com>

        cc:        

        Subject:        CCL: [CCL]: Cleaning up dusty deck fortran and converting to C/C++

.





Sent to CCL by: "Robert Duke" [rduke * email.unc.edu]

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

Okay, folks, one last round of clarifications, really, with emphasis on
issues of multidimensional arrays in C vs. Fortran.  Comments embedded below
as appropriate.
Regards - Bob Duke

----- Original Message -----
> From: "CCL" <owner-chemistry{:}ccl.net>
To: "Duke, Robert E " <rduke{:}email.unc.edu>
Sent: Tuesday, September 27, 2005 11:56 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--.
>
>
>> 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.

That was a simile.  B was the precursor to C, and B itself was preceded by
BCPL; this was the evolutionary sequence for C, and the precedents were in
no way as desirable to use as C.

>
> 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.

Really?  Doesn't it depend on a number of factors as to whether you are
better off moving to something else?  Isn't that a lot of what this
discussion is about?

>
>> 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.
>

Well, I do very much like C++, but otherwise I totally agree with what you
say here, and I have always advocated that an appropriate subset of the
language be used, and that the language be used by individuals who are
focused purely on software development.  I used it a lot through much of the
90's while working on both Windows NT and Exchange development at Microsoft.
It was very nice to use in that environment, and despite initial performance
concerns, we worked out ways to insure the high levels of performance
required for OS dev.  A real pain, however, is subtle differences in the
meaning of some things, like const, in C vs. C++.

>> 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.
>

Okay, maybe there is something I don't know here, so feel free to enlighten
me, but I think setup is a bit more complex, and the potential for screwups
is higher.  Let's go through my understanding of the differences between the
two languages in this domain.  My understanding of C/C++ may be a little
dated in this regard, so inform me if c99 has introduced new capabilities
that make this less onerous.  My standard c/c++ references are:
K & R - of course
Plum - "Reliable Data Structures in C"
Ellis & Stroustrup - "The Annotated C++ Reference Manual" - This was the C++
bible when I was at Microsoft, and for those that don't know C++ is
Stroustrup's baby.

Multidimensional C arrays

Static arrays are of course easy.  You declare something like:

float    a[200][3];

and off you go, able to index into this array with the 3 subscript varying
most rapidly.  Of course this is the reverse of the more common fortran
index order, and array subscripts start at 0, and both of these facts have a
certain amount of nuisance value that should not be overlooked as a point of
pain in a port.  There is a common trick in the scientific community of
overallocating by 1 in all dimensions and starting your indexing at 1 (ie.,
don't use the 0 element).  Aside from wasting space (probably not a huge
deal in many domains), this practice creates C that is not idiomatic, and
when a real C programmer comes along s/he will be driven nuts, and worse,
may mix conventions on you, resulting in a number of interesting problems
down the line (it may be inferred that I am not behind this practice - if
you are going to write C, learn to write C, darn it).

However, say you don't know ahead of time what the dimensions for the array
will be.  Well, of course you just malloc() (ie., allocate) an array and use
it, right?  Well, yes, but if you want to use the array in the same scope
(function) that you allocated it, then you have to do the indexing
arithmetic yourself.  Not a huge deal, but for the a array above, if you
want to look at what would logically be a[i][j], then you would reference
a[i * 3 + j], which is not as array-intuitive as a[i][j], and adding more
indices makes things worse.  Note that if you overdimension to be able to
use your scientific c programmer trick, then you have to keep track of the
real dimension used here.  I have done a bunch of fft programming in c
(sinking into fftw), and all this great stuff can be a pain.  Okay, so what
if you want to use
a[i][j] instead?

Well, to my knowledge, and loosely based on an example in Plum's book, you
go through all the following:

1) Don't declare function prototypes (you can, but you will get a bunch of
warnings).
2) Allocate the array in some outer scope (function)
3) Call a function of the form below, passing in the dimensions you want to
use; I show a triple index example, just to stretch things, where the last
index is a known constant, but the other two dimensions are derived from the
caller.

void
do_something(i, j, array)
 int i, j;
 float array[i][j][3];
{
 reference array[ii][jj][0 to 2] over the range of ii = 0 to i-1 and jj = 0
to j-1
}

Then there are the issues of confusion caused by situations where a[][]
really is referencing an array of pointers.  Now, this array of pointers
data structure is a neat type of data structure, and it is sometimes pointed
out that indexing arithmetic is simpler because you just indirect through
the pointer and add the second index.  True, but the novice user may not
realize that is what is being done when s/he sees a ref of form a[][], and I
guarantee that if you pass such an array to linear algebra, fft, or what
have you library functions, you may not get exactly what you had in mind.

So maybe there are things I don't know about all this, but from my
perspective, this is all not exactly smooth and transparent for someone
trying to do a bit of numeric array manipulation.

I would concede that for many arrays that I use, the problem is relatively
easy to solve through use of arrays of structures (say for coords, forces,
or what have you), where the second C dimension is basically constant and
implemented through a structure (say struct { float x, y, z }; ).  However,
there are a lot of things not covered by this.

Allright, what does f90 look like in this regard?  Well f77 was a pain
because you could not do proper allocation, so you ended up allocating
blocks of storage via an OS mechanism (say malloc) and passing the address
of this stuff to subroutines or functions that referenced it as arrays.  You
could be unknowledgeable about the last array dimension instead of the
first, but otherwise had to know how things were laid out in advance (works
fine for 2d arrays of coords and what have you, but not everything).

With f90, however, in any scope you can create an array to be indexed
however you would like, of whatever dimensions you would like by specifying:
real, allocatable    ::    array(:,:,:)

and then calling:

allocate(array(i,j,k), stat = statvar)

This is perfectly general, and you can get i,j,k however you like whenever
you like, and index this thing intuitively wherever you like.

It is also possible to use what are called automatic arrays within a
subroutine or function scope to essentially get scratch space of a size
specified in the call interface.  So, a subroutine of the general form:

subroutine dosomething(i, j)

 implicit none

 real    :: scratch(i, j)

has an array of size i * j allocated on the stack or heap, depending on the
compiler implementation, and this space will be automatically released on
return (this is somewhat true for the allocate() statement too unless you
specify save in the array declaration).  The one problem with this mechanism
is that if the stack is used, on some systems with a small stacksize limit
you may get memory exceptions (so do a "limit stacksize unlimited" in your
.login for csh, or what have you).

This all seems a bit more intuitive and bulletproof to me, and I learned the
other stuff first.  I absolutely love the art and science of more complex
data structures, and have been schooled in this area; a good array
implementation is the appropriate data structure, however, in many instances
in scientific code.

>> 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.
>
Well, I pretty much make my living by making code fast for folks that care
about such things, like the amber group.  So I am aware of all these issues
and basically agree.  I think C can be less efficient in some scenarios if
there is extensive use of indirection (pointers), depending somewhat on the
architecture.  I have particularly seen 2-fold differences in itanium
performance caused by algorithms that don't stride regularly through arrays,
but have to do some sort of indirection (pointer or offset) to get the next
chunk of work.  I agree that with care and a good compiler implementation
you should come close with either language; the thing is that novices more
often do something in C/C++ that screws up the performance.  For somebody
like me I guess it is an opportunity...

Regards - Bob Duke> the strange characters on the top line to the {:} sign.>
> E-mail to administrators: CHEMISTRY-REQUEST{:}ccl.net or us>
>
>
>


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



-----------------------------------------------------------------------------------------------------
The information transmitted is intended only for the person
or entity to which it is addressed and may contain proprietary,
business-confidential and/or privileged material.
If you are not the intended recipient of this message you
are hereby notified that any use, review, retransmission,
dissemination, distribution, reproduction or any action taken
in reliance upon this message is prohibited. If you received
this in error, please contact the sender and delete the
material from any computer. Any views expressed in this message
are those of the individual sender and may not necessarily reflect
the views of the company.
-------------------------------------------------------------------------------------------------------
 --=_alternative 005D2C698825708A_=-- From owner-chemistry@ccl.net Wed Sep 28 16:11:22 2005 From: "CCL" To: CCL Subject: CCL: [CCL]: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29372-050928160621-12781-Iy2XdyyYuzVn9VL/n29VOg^server.ccl.net> X-Original-From: Drew McCormack Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Date: Wed, 28 Sep 2005 22:05:15 +0200 Mime-Version: 1.0 (Apple Message framework v734) Sent to CCL by: Drew McCormack [da.mccormack^few.vu.nl] --Replace strange characters with the "at" sign to recover email address--. > >>>> 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. >>> >> >> You can, but it is not easy. First you call malloc to create a >> buffer; then you use embedded loops to assign pointers to the >> beginning of each row. >> > > That is not true. > > I don't know why you would do what you say you have to do. I've looked into this some more. What I suggested is the common way of treating multidimensional arrays allocated at run time in C. See, for example: http://www.eskimo.com/~scs/cclass/int/sx9b.html > > >> I don't think there is any question that Fortran 90's array features >> are vastly superior to C's. For example, being able to add local >> arrays to the stack ('automatic objects' is the Fortran terminology), >> and deciding dimensions at run time, are very useful. >> > > You mean like this?: > > void foo(int i, int j) > { > double array[i][j]; > > .. > } > > That's the allocation of an array at run time on the stack with > whatever dimensions you like (passed at run time.) > > Could you please explain what it is that Fortran lets you do that C > does not again? It seems like the reason I wasn't aware of the above construction is that it is a relatively new addition to C. It was added in C99. Before that, it was not legal C, though it was supported by gcc as an extension. (See http://www.eskimo.com/~scs/cclass/int/sx9a.html for more info). > > Is the issue here that you don't know enough C to know how to do > this stuff? No, I am just a little out-of-date when it comes to raw C programming. In 1998, you couldn't do this 'stuff' in C. (Most of my programming time is spent with C++, so I don't spend much time working with C arrays these days.) Drew --------------------------------------------------------- Drew McCormack www.maniacalextent.com From owner-chemistry@ccl.net Wed Sep 28 15:50:02 2005 From: "CCL" To: CCL Subject: CCL: Fortran vs. C - when will it end? Message-Id: <-29370-050928154338-21601-8bfiS8nOZVYQF0AvdkhSyA]^[server.ccl.net> X-Original-From: jle]^[TheWorld.com Content-Transfer-Encoding: 8bit Content-Type: text/plain;charset=iso-8859-1 Date: Wed, 28 Sep 2005 15:43:28 -0400 (EDT) MIME-Version: 1.0 Sent to CCL by: jle]^[TheWorld.com --Replace strange characters with the "at" sign to recover email address--. > > Sent to CCL by: Heidi Rohwer [heidi.rohwer_-_aci.uni-heidelberg.de] > > --Replace strange characters with the "at" sign to recover email > address--. > > The issue is not whether Fortran is better or worse than C, C++ or > whatever else you want to bring into the whole argument, but whether > this whole discussion is (a) productive and (b) relevant to this mailing > list. It would seem to be the answer to both questions is no. How about > we get back to relevant and productive discussions about computational > chemistry? At the very least continue the discussion via private emails > and don't clutter up the rest of our mailboxes. I think that a discussion as to how our tools are constructed, and how people in our business should be trained is productive. At least as productive as blasting questions about the building and use of Gaussian Inc. products is, given that they have a support mechanism as I recall. As I stated previously, this is why delete keys were invented. I'm sure people have updated their spam filters after the last week or two here. Naturally, all discussions have to be conducted in a civil and professional manner. I have tried to adhere to this, but I find it frustrating when people try to wave away discussions they don't find interesting, rather than merely ignoring them. I'm sure those of us not using Gaussian code have been ignoring a WHOLE lot of emails over the years. I seem to recall years ago CCL had a set of common prefixes to use in headers, so that a quick skim indicated whether it was worth opening the email or not. Is this still in place, because prefixing CS-related emails with CS: (and Gaussian related emails with G03, or Gxx or something like that) would do the trick. I will try to do this in the future, and ask that others consider doing so as well. Jan, if I'm remembering correctly, is there a set of prefixes we should use - QM:, MD:, ?? Joe > > Regards > Heidi> > > From owner-chemistry@ccl.net Wed Sep 28 15:00:10 2005 From: "CCL" To: CCL Subject: CCL: [CCL]: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29363-050928141131-1267-/kftxhU/CjB0ACoR5KYaOQ#%#server.ccl.net> X-Original-From: Ivan Tubert-Brohman Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Date: Wed, 28 Sep 2005 13:37:15 -0400 MIME-Version: 1.0 Sent to CCL by: Ivan Tubert-Brohman [ivan.tubert-brohman#%#yale.edu] --Replace strange characters with the "at" sign to recover email address--. CCL wrote: > Sent to CCL by: "Perry E. Metzger" [perry*_*piermont.com] >>I don't think there is any question that Fortran 90's array features >>are vastly superior to C's. For example, being able to add local >>arrays to the stack ('automatic objects' is the Fortran terminology), >>and deciding dimensions at run time, are very useful. > > > You mean like this?: > > void foo(int i, int j) > { > double array[i][j]; > > .. > } > > That's the allocation of an array at run time on the stack with > whatever dimensions you like (passed at run time.) > > Could you please explain what it is that Fortran lets you do that C > does not again? > It should be pointed out that variable arrays are a relatively new feature, introduced with the C99 standard, and therefore not very widely used yet (and probably not supported by some compilers). -- Ivan From owner-chemistry@ccl.net Wed Sep 28 16:07:41 2005 From: "CCL" To: CCL Subject: CCL: [CCL]: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29371-050928154319-21384-9OeGQDXYSB7/5Iq4tU1rtQ|-|server.ccl.net> X-Original-From: Drew McCormack Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Date: Wed, 28 Sep 2005 21:42:11 +0200 Mime-Version: 1.0 (Apple Message framework v734) Sent to CCL by: Drew McCormack [da.mccormack|-|few.vu.nl] --Replace strange characters with the "at" sign to recover email address--. > > >>>> 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. >>> >>> >> >> You can, but it is not easy. First you call malloc to create a >> buffer; then you use embedded loops to assign pointers to the >> beginning of each row. >> >> > > That is not true. > > I don't know why you would do what you say you have to do. It would be > silly. You treat a dynamically allocated N by N array the way you > treat a dynamically allocated struct or anything else. > > It is perfectly valid to do this: > > typedef double matrix[4][4]; > > matrix *foo; > > [...] > > foo = (matrix *)malloc(sizeof(matrix)); > > (*foo)[3][1] = 10.0; > This is not the same, because the dimensions must be known at compile time. The buffer is dynamically allocated, but the dimensions are not dynamically determined. > > If you want, the [4][4] can be variables provided the typedef is > inside a function declaration. > > Of course, it is very rare that you would want to do this anyway, > since generally you would want an array to be part of a larger > structure or to be dynamically allocated on the stack, but there is no > reason you can't do it if you want to. > I must concede that I didn't know you could do this, but the reason I didn't know is probably because it is not very useful in general. How do you put your 'matrix' type in a struct, for example (where the dimensions are dynamically determined)? I suspect you end up just storing a double* or double**, right? If you opt for double**, you end up doing what I suggested earlier. Using the trick I described of assigning double** to the beginning of rows is the only way to end up with a variable that can be indexed anywhere without typedefs and casts. > > > >> I don't think there is any question that Fortran 90's array features >> are vastly superior to C's. For example, being able to add local >> arrays to the stack ('automatic objects' is the Fortran terminology), >> and deciding dimensions at run time, are very useful. >> >> > > You mean like this?: > > void foo(int i, int j) > { > double array[i][j]; > > .. > } > > That's the allocation of an array at run time on the stack with > whatever dimensions you like (passed at run time.) > > Could you please explain what it is that Fortran lets you do that C > does not again? > OK, I stand corrected on this one. As for what you can do in F90 that you can't do in C, how long have you got? - Direct allocation of multidimensional arrays without hacks like the one described above ( allocate( a(1,2,3) ) ) - Arrays know their dimensions. You can query size of any dimension, as well as lower and upper bounds. (size(a,1)) - You can pass arrays to functions without passing their dimensions in separate variables, because the arrays know their own dimensions. - Arrays can have strides ( allocate( a(1:6:2) ) ) - Fortran supports elementwise ops ( a = sin(b) * c, where a, b and c are arrays) - Arrays can be indexed by slices ( a(1:5,:) = b(5:10,:) ) - Arrays can be indexed by index arrays, creating permutations ( a ( (/1,4,2,5/) ) ) - You can generate temporary arrays in nearly any context ( c = sin ( (/1.0, 2.0, 3.0/) ) ) - You can similarly create temporary arrays with implied loops ( c = ( sin( a(i) ), i=1,10 ) ) - Fortran has array pointers ( a => b(1:5:2) ) > > > >> C's array support is primitive, >> >> > > In what way, exactly? > The ways described above. C arrays are basically pointers to memory. They are dumb. > > Is the issue here that you don't know enough C to know how to do > this stuff? > Is the issue here that you don't know enough Fortran 90 to know how to do this stuff? Drew From owner-chemistry@ccl.net Wed Sep 28 15:24:42 2005 From: "CCL" To: CCL Subject: CCL: Open source contributions by pharma. Message-Id: <-29369-050928152152-17145-l7JbWj9EZhG5U+EyJp+mmw- -server.ccl.net> X-Original-From: john furr Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Date: Wed, 28 Sep 2005 15:21:47 -0400 MIME-Version: 1.0 Sent to CCL by: john furr [john.furr- -gmail.com] --Replace strange characters with the "at" sign to recover email address--. Peter might I ask what area you are interested in contributing to? I have been toying with the idea of open sourcing parts of Dynamol under an LGPL style license. Feel free to e-mail me directly if you would like. John Furr john.furr- -gmail.com On 9/28/05, CCL wrote: > > Many thanks to those who sent examples of software contributed by pharma, > and for the many thoughtful comments on the issue. > > A number of you asked to see the final list. Below is the list of software, > followed by a summary of people's comments. > > Application Contributing Company Author Availability URL > > RasMol GlaxoWellcome Roger Sayle open source > http://www.umass.edu/microbio/rasmol/index2.htm > OELib OpenEye, others Matt Stahl open source > http://www.eyesopen.com/products/toolkits/oelib.html > JME Novartis Peter Ertl free > http://www.molinspiration.com/jme/ > tpsa.c Novartis Ertl et al. open source > http://www.daylight.com/meetings/emug00/Ertl/ > NEWLEAD Novartis Vincenzo Tschinko free > http://www.ccl.net/cca/software/SGI/newlead/README.shtml > Moloc Roche Paul Gerber fee (non-academics) > http://www.moloc.ch > MMFF94 Merck Thomas Halgren free > http://ccl.net/cca/data/MMFF94/ > Pgchem::tigress Bayer Ernst-Georg Schmid > http://pgfoundry.org/projects/pgchem/ > OpenBabel Merck (provided financial support) open source > http://sourceforge.net/mailarchive/forum.php?thread_id=8125020&forum_id=3042 > PyMOL Delano Scientific Warren DeLano open source > http://pymol.sourceforge.net/ > various java programs ChemAxon, others open source > http://www.chemaxon.com/forum/ftopic193.html > > Programs available for a "nominal" fee from the Quantum Chemistry Program > Exchange (http://qcpe.chem.indiana.edu), contributed form the 1970s through > 2000s. Source code for 20 or so programs reportedly were contributed by > industry. > PRODIS Abbott Low-Energy Conformations of Flexible Molecules > MOLSV Merck Molecular Volume and Surface Area Calculation > RNGCFM Merck Exploration of Medium-Size Ring Conformations > BIGSTRN-3 Merck General-Purpose Empirical Force-Field Program > SEA Merck Steric and Electrostatic Alignment Molecular > Superposition Program > SEAL Merck An Alternate Method for the Alignment of Molecular > Structures > SAMPLS Merck Sample Distance Partial Least Squares Program > ("used to develop a structure-activity relationship (SAR) for any single > response (i.e., biological activity), based on the "distance" between > samples (e.g., chemical compounds) in a training set.") > NEWLEAD Novartis Generation of Candidte Structures > DGEOM DuPont,Chiron Distance Geomerty Program ("DGEOM is a distance > geometry program for molecular model-building, receptor modeling, > conformational analysis, and NMR solution structure determination") > MOLAREA Lilly Calculation of the Surface Area of a Non-Spherical > Molecule or Molecular Cavity in a Fluid from the Van der Waals Radii of > Component Atoms > USURF Upjohn Generation of Smooth Molecular Dot Surfaces > TRIBL DuPont (no longer available) A Complete Molecular Modeling > Software System > > It was also noted that: > - Many SPL scripts for Sybyl were developed/contributed by people in > industry. These may not be "open source" in the usual sense, but SPL lends > itself to reuse/translation into other languages. > - Pharma has also provided significant contributions to bioinformatics open > source projects. > > > To summarize (and plagiarize) people's comments: > > Benefits of contributing to open source: > > - External improvements on contributed code -- if the code remains in-house, > no external review or improvement is possible. This "piling on" effect is > significant. > - Control over product development -- does a particular software project > meet your needs? Contribution to open software allows you to better address > specific issues and target your projects. > - Benefits > from external maintenance -- if you maintain your own internal > version, you will be constantly trying to keep up with the external official > version. > - Good publicity in the community, possible tax write-off benefits for > charitable contributions. > - Improved return on investment of resources: > - Increased benefit to the company when code is contributed to the > community, since the company has use of the code, whether left in-house or > donated. Thus others' contributions add value. > - It's easier to let an external group enhance and maintain it. > - Open source fixes bugs better than commercial vendors, so presumably > better than in-house code too. > - Continuity: Very often the code is associated with an individual. > - Maintenance can be continued when the developer leaves, benefitting the > originating company. > - This also benefits the developer, who can continue to use and develop > the code afterwards. > > Possible concerns: > > - reputation (the code could be seen to reflect on the company) > - liability > - maintenance (this is impossible to guarantee) > - distribution - it is not always easy to find a site where the material can > be mounted. > - license (supporting Open source might be seen to be undermining their > commercial vendors) > - loss of IP > > Counter-arguments: > > - Reputation: > - The flip side is free advertising. > - Contributions can always come from an isolated individual rather than > being publicly blessed by the company. (However, initial software > development is often done on company time, so belongs to the company.) > - Liability: > - The open source license itself restricts liability -- because the > program is licensed free of charge, no warranty is express or implied. > - A code repository could be established where it was made it clear that > there was no further implied commitment and that donation was accepted as a > final act. > - Maintenance and distribution is handled by existing frameworks (i.e., the > project you're contributing to). > - License: If a commercial software vendor is concerned about being > undermined by an open source solution, then they have not made their case to > clients. A commercial solution should provide a clear advantage over an > open source solution. > - IP: > - Contributing software is no different from publishing scientific papers > describing syntheses and new techniques, which pharma does all the time. > - There's very little IP "loss" in open source contributions. You or your > company retains the original copyright. You can still sell commercial > versions of that code. > - Many projects, while quite useful, don't make much use of proprietary > knowledge, so the value of the protected IP would likely not be high. > > > > > -----Original Message----- > From: Peter Spiro > Sent: Monday, September 26, 2005 8:15 PM > To: 'OpenBabel-discuss- -lists.sourceforge.net'; > 'chminf-l- -listserv.indiana.edu'; 'chemistry- -server.ccl.net'; > 'qsar_society- -accelrys.com' > Subject: Open source contributions by pharma. > > > > > 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 Wed Sep 28 17:16:22 2005 From: "CCL" To: CCL Subject: CCL: [CCL]: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29373-050928171300-12948-pBE16VptIvxoaHeQ43/5yQ%%server.ccl.net> X-Original-From: "Perry E. Metzger" Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Sep 2005 17:12:52 -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: >> Is the issue here that you don't know enough C to know how to do >> this stuff? > > Well, not to get personal here, but I will take exception to you > saying that to Drew; I didn't mean to be insulting. I apologize if it was taken that way -- I got far too sharp there. >> It is perfectly valid to do this: >> >> typedef double matrix[4][4]; >> >> matrix *foo; >> >> [...] >> >> foo = (matrix *)malloc(sizeof(matrix)); >> >> (*foo)[3][1] = 10.0; >> >> If you want, the [4][4] can be variables provided the typedef is >> inside a function declaration. > > This just moves the mechanism I showed into a typedef You don't need the typedef. I just put it in to make the code clearer. I usually typedef just about everything, for the same reason one #defines or const's all constants -- so there is one point where an abstract type id defined. If you wanted to simply declare a pointer to MxN arrays directly without the intervening typedef that will work just fine, too. > though it allows use of the fully indexed, but still a little > awkward reference style shown above in the scope in which the array > was created. Fortran still is easier to read. Well, keep in mind what it is that you're doing here -- you're accessing a array via a pointer, not directly. If you want an array that you're accessing directly, use a dynamic array (i.e. an automatic variable containing an array who's dimensions are defined by variables), not a malloc'ed array. malloc is for doing things like building data structures on the heap. Incidently, the way C is built, if you pass a pointer to an MxN array to a function, C can't distinguish it from an MxN array being passed directly -- all array passes are by reference, and one address of an MxN array is pretty much the same as another. That means you don't actually need to use the (*foo)[a][b] notation either if you want to avoid it, but the code becomes more prone to confusion by novices in that case so I wouldn't "pun" things that way. You could if you wanted to though. >> Of course, it is very rare that you would want to do this anyway, >> since generally you would want an array to be part of a larger >> structure or to be dynamically allocated on the stack, but there is no >> reason you can't do it if you want to. > > Very rare? I need really big dynamic arrays at various scope levels > all the time. Sure, but you usually don't want them constructed *this way*. There are other ways. I'm just pointing out that you don't have to do the arithmetic yourself for the array indexing. > I am done flooding the list with this stuff; I'll reply to anything > further directly. Agreed. This is probably just annoying everyone at this point. I'll try to confine any further replies to very specific points, though if anyone has specifics that aren't of general interest to discuss with me, they can send them to me directly. Perry From owner-chemistry@ccl.net Wed Sep 28 17:57:45 2005 From: "CCL" To: CCL Subject: CCL: [CCL]: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29374-050928175454-10497-zLrP9BhtLs7d5nt59tzycA::server.ccl.net> X-Original-From: "Alex. A. Granovsky" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 29 Sep 2005 01:59:28 +0400 MIME-Version: 1.0 Sent to CCL by: "Alex. A. Granovsky" [gran::classic.chem.msu.su] --Replace strange characters with the "at" sign to recover email address--. Just curious, what is C/C++ version, both in the terms of simplicity and _efficiency_, of the following elementary Fortran sample: subroutine test(a,b,m,n) implicit none integer m, n double precision a(m,n), b(m,n) integer i do i=1,n a(:,i) = dble(i)*b(:,i) end do return end Regards, Alex ----- Original Message ----- > From: "CCL" To: "Granovsky, Alex, A. " Sent: Wednesday, September 28, 2005 10:13 PM Subject: CCL: [CCL]: Cleaning up dusty deck fortran and converting to C/C++ > > Sent to CCL by: "Perry E. Metzger" [perry\a/piermont.com] > > --Replace strange characters with the "at" sign to recover email address--. > > > One lst round here. > >> You can allocate a multidimensional array dynamically in C and index > >> it just like you index any other array. > > > > Okay, maybe there is something I don't know here, so feel free to > > enlighten me, but I think setup is a bit more complex, and the > > potential for screwups is higher. Let's go through my understanding > > of the differences between the two languages in this domain. > > Okay... > > > Multidimensional C arrays > > > > Static arrays are of course easy. You declare something like: > > > > float a[200][3]; > > > > and off you go, able to index into this array with the 3 subscript > > varying most rapidly. Of course this is the reverse of the more > > common fortran index order, > > Actually, the Fortran order is used mostly by Fortran at this > point. It doesn't really matter though in the sense that you don't have > to actually care which subscript varies most rapidly in most numerical > algorithms. The only time I've had to care was 25 years ago when I had > an array in memory simulating a huge frame buffer (far bigger than > RAM) and if you strode the array the wrong way you took a page fault > for every stride. That sort of thing doesn't happen any more and if it > did, it is easily understood and avoided. > > > and array subscripts start at 0, and both of these facts have a > > certain amount of nuisance value that should not be overlooked as a > > point of pain in a port. > > It is true that C arrays start at 0. I don't think that's an inherent > issue, that's just a matter of taste. The reason for the definition > makes sense when you consider that [] is an operator. > > > However, say you don't know ahead of time what the dimensions for the > > array will be. Well, of course you just malloc() (ie., allocate) an > > array and use it, right? > > Or use a dynamic array on the stack, yes. > > > Well, yes, but if you want to use the array in the same scope > > (function) that you allocated it, then you have to do the indexing > > arithmetic yourself. > > No, you don't. Really. I understand that your references told you that > you did, but for malloc that's never been true and for allocations on > the stack that hasn't been true in some time. > > There are two ways to deal with this. > > First, there is the way if you want to do something that doesn't live > beyond the current scope: > > void foo(int i, int j) > { > double a[i][j]; > > /* and then just use a the way you like... */ > > a[3][2] = 10.3; /* bad code, since i and j might be, say 1, > but it demonstrates my pont. */ > } > > That's been around for quite some time but it has only recently been > burned into the standard. Every compiler you can get supports it -- > try it on a late model gcc or Microsoft C or whatever and it will just > work. "Try it." > > Then there is what happens if you want to dynamically allocate an > array at run time using malloc. > > Recall that what malloc returns to you is a POINTER to an > object. Thus, if you were going to malloc a struct, you would do: > > struct stype { int a; int b}; > > struct stype *foo; > > foo = malloc(sizeof(struct stype)) > > and you would do > > (*foo).a > > or > > foo->a > > to get at the a member of the dynamically allocated structure. > > Therefore, the equivalent for an array is: > > typedef float dynarray[10][10][10]; > > dynarray d; > > d = malloc(sizeof(dynarray)); > > and later > > f = (*d)[5][5][5]; > > will work just fine. Always has -- probably would work on the oldest C > compilers you could possibly run. > > One problem is many programmers don't understand the difference > between C's arrays and pointers -- they think of arrays as pointers > and pointers as arrays merely because you can apply the [] operator to > a pointer. (I try to explain this explicitly when I'm teaching someone.) > > As a result, some folks don't get that to do the indexing correctly > the machine has to be informed of the type. It can be informed at run > time -- you can do that typedef with variables as indexes inside a > function declaration -- but you can't lie to the compiler or it will > take its revenge. If you tell the truth to the compiler, it will do > what you want. > > People that don't understand this would try > > d[5][5][5]; > > which does not mean the same thing at all! Extra credit for readers > who can articulate what it does mean. (Hint -- there are implied > arrays of "dynarray"s in this example.) > > You can argue that needing to do (*d)[5][5][5] instead of d[5][5][5] > is a defect in the language. I'd disagree -- if you are fussing with > pointers and heap allocation, you want pointers and pointer > dereference, and if you aren't explicit about that you're not telling > the computer what you want it to do (or, more to the point, preventing > it from doing what you actually want). That's the price you pay when > you allocate a struct, too. > > If you are looking for allocating a temporary dynamic array on the > stack, of course, you get an array, not a pointer to an array. > > > Well, to my knowledge, and loosely based on an example in Plum's book, > > you go through all the following: > > That's not strictly correct. I've appended a sample program at the > end. Compile it and run it on your favorite C compiler. You will get > the expected output when you run it. > > > So maybe there are things I don't know about all this, but from my > > perspective, this is all not exactly smooth and transparent for > > someone trying to do a bit of numeric array manipulation. > > Well, see my attached sample. > > > With f90, however, in any scope you can create an array to be indexed > > however you would like, of whatever dimensions you would like by > > specifying: > > C isn't particularly different. The syntax is just a bit different (as > seen above and below). > > > It is also possible to use what are called automatic arrays within a > > subroutine or function scope to essentially get scratch space of a > > size specified in the call interface. So, a subroutine of the general > > form: > > > > subroutine dosomething(i, j) > > > > implicit none > > > > real :: scratch(i, j) > > C lets you do exactly the same (see above and below). > > >>> 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. > > > > Well, I pretty much make my living by making code fast for folks that > > care about such things, like the amber group. So I am aware of all > > these issues and basically agree. I think C can be less efficient in > > some scenarios if there is extensive use of indirection (pointers), > > depending somewhat on the architecture. > > Yup, you're right. You have to be careful not to confuse the compiler > with excessive pointer aliasing. If you do, you lose. You can get > around it with "restrict", but it is certainly a defect of weak > typing. That's one reason I don't claim C is my favorite language for > this sort of thing -- just better (IMHO) than many other beasts. > > > I have particularly seen 2-fold differences in itanium performance > > caused by algorithms that don't stride regularly through arrays, but > > have to do some sort of indirection (pointer or offset) to get the > > next chunk of work. > > Be careful there. Consider how inconsistent and bad Itanium compilers > are. (It is the problem with having an architecture that throws so > much work onto the compiler writer. There is a reason the architecture > has died.) There is also the issue of whether you're getting cache > misses -- that's always a bad one. > > However, I agree that if you ask the compiler to do something foolish > you can hurt yourself -- but that's true of any language including > Fortran. > > One favorite example of mine is this: > > Teachers often (mistakenly) teach their students to build hash tables > by making the table length a prime number to exploit the same > properties linear congruential number generators exploit. Thus, you > would make your table, say, 97 buckets long and do: > > hashval = foo % 97; > > to calculate the bucket you want. This is, in fact, a bad idea. > > It is true that you get somewhat better distribution of buckets by > doing the mod prime operation, but under the covers, mod requires that > you do an integer division, which often takes close to 20 > cycles. Doing a simple shift takes one cycle. Thus, doing a table that > is an exact power of 2 means that your hash function takes 15 or 25 > times less time to compute. That is usually a big win in terms of > constant factors, even if you have to climb a link or two extra in an > open hash table. > > What's the problem here? Assuming that just because % and >> are > single operators that they both take the same length of time. > > Perry > > -------------------- Sample C program > > #include > #include > > typedef float dynarray[10][10][10]; > > void testme(int i, int j) > { > double a[i][j]; > > a[1][2] = 5.0; > > printf("double is: %f\n", a[1][2]); > } > > > int main(int argc, char **argv) > { > dynarray *d; > float f; > > d = malloc(sizeof(dynarray)); > > (*d)[5][5][5] = 10.0; > > f = (*d)[5][5][5]; > > printf("float is: %f\n", f); > > testme(6, 6); > > } > > -------------------- Sample Output: > > $ cc -o foo foo.c > $ ./foo > float is: 10.000000 > double is: 5.000000 > $> > > >