From owner-chemistry@ccl.net Sat May 7 00:56:00 2011 From: "Chenghua Zhang zchua126.com() 126.com" To: CCL Subject: CCL: The rate-limiting step is the product release using QM/MM Message-Id: <-44572-110507005405-21824-m/S8ypSUe+Z2Q7cVNtbABQ]=[server.ccl.net> X-Original-From: "Chenghua Zhang" Content-Type: multipart/alternative; boundary="----=_Part_23817_1087305.1304744022856" Date: Sat, 7 May 2011 12:53:42 +0800 (CST) MIME-Version: 1.0 Sent to CCL by: "Chenghua Zhang" [zchua126.com{:}126.com] ------=_Part_23817_1087305.1304744022856 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: 7bit Dear all, Recently, I want to investigate a enzyme reaction using QM/MM (ES--TS--PS--P+S). Experimentally, the primary isotope effects on the kinetic constants and the effects of changes in solvent viscosity are consistent with product release being the rate-limiting step. How can I simulate the process of product release and to indict that the rate-limiting step is the product release rather than from ES to TS. Thanks very much~~ Sincerely Chenghua Zhang College of Chemistry Sichuan University, China. ------=_Part_23817_1087305.1304744022856 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: 7bit Dear all,

    Recently, I want to investigate a enzyme reaction using QM/MM (ES--TS--PS--P+S). Experimentally, the primary isotope effects on the kinetic constants  and the effects of changes in solvent viscosity are consistent with product release being the rate-limiting step.
   How can I simulate the process of product release and to indict that the rate-limiting step is the product release rather than from ES to TS. Thanks very much~~

Sincerely
Chenghua Zhang
College of Chemistry
Sichuan University, China.



------=_Part_23817_1087305.1304744022856-- From owner-chemistry@ccl.net Sat May 7 03:45:00 2011 From: "Sebastian Kozuch kozuchs(_)yahoo.com" To: CCL Subject: CCL: Computational Chemistry Wiki Message-Id: <-44573-110507032319-1432-ChgdcdXyUUX3BWm7T+jR5w.@.server.ccl.net> X-Original-From: Sebastian Kozuch Content-Type: multipart/alternative; boundary="0-1300100337-1304752987=:63020" Date: Sat, 7 May 2011 00:23:07 -0700 (PDT) MIME-Version: 1.0 Sent to CCL by: Sebastian Kozuch [kozuchs_-_yahoo.com] --0-1300100337-1304752987=:63020 Content-Type: text/plain; charset=us-ascii I wanted to say a couple of words about the computational chemistry wiki, which was cited recently in this list. Up to now it is more a small experiment than a useful tool. Two years ago this wiki started after a small debate in CCL, where the question of a simple and updated source of methods arose. So the wiki was created in a free web hosting for wikis (wikia), and a small bunch of small articles was written as a test, but with the hope of growing. The idea received some commendations and several constructive criticism, such as who will be the administrator and if there is a possibility to move the wiki to a more serious server where no publicity appears. Someone (I don't remember exactly who) even suggested that this should be discussed at the following WATOC meeting. The wiki didn't prosper much, since no progress was done regarding these issues. I know that most of these projects tend to sink into oblivion, but I still think that the wiki can be extremely valuable. It is not meant to cover the general subjects (for that, wikipedia is the right place), but to give a hint on the usage of the specific methods of computational chemistry, and where can we find further references. So, if someone is interested, I invite you to visit the wiki, or even try to add a small article. It can only work if more than one person is on it. Maybe in the near future, if a better server is decided to be used, we can move those articles to its definite place. http://computationalchemistry.wikia.com Best, xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ..........Sebastian Kozuch........... xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ....Weizmann Institute of Science.... ...........Rehovot, Israel........... .. sebastian.kozuch-$-weizmann.ac.il .. http://yfaat.ch.huji.ac.il/kozuch.htm xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ________________________________ > From: "Jim Kress ccl_nospam-,-kressworks.com" To: "Kozuch, Sebastian " Sent: Thu, May 5, 2011 9:55:35 PM Subject: CCL: To begin with computational chemistry http://computationalchemistry.wikia.com/wiki/Computational_Chemistry_Wiki > From:owner-chemistry+ccl_nospam==kressworks.com..ccl.net [mailto:owner-chemistry+ccl_nospam==kressworks.com..ccl.net] On Behalf Of karthikeyan m.karthikeyan^^ncl.res.in Sent: Thursday, May 05, 2011 11:20 AM To: Kress, Jim Subject: CCL: To begin with computational chemistry I am bit upset with the series of discussion on 'To begin with computational chemistry' To avoid piracy and outdated books, can we 'crowd source' a Wikibook or cloudbook on "computational chemistry"? I am an organic chemist by education and working with chemical information for the past 15 years. I really need to know the computational chemistry to define the 'chemical reaction space' I try here and there, read here and there, use softwares to extent for example MOPAC, GW03, MOE, Hyperchem, Schordinger, Accelrys etc., I think it is high time to build a 'dynamic book' because no book is complete and could support the 'best of every available tools' to solve chemical/molecular problems. Cloud books with detailed explanation with case studies as 'blogs' would really help not only 'third world countries' and even the 'developed countries'. Just some thoughts please write your comments directly to me if any. M.Karthikeyan http://moltable.ncl.res.in/ --0-1300100337-1304752987=:63020 Content-Type: text/html; charset=us-ascii
I wanted to say a couple of words about the computational chemistry wiki, which was cited recently in this list.
Up to now it is more a small experiment than a useful tool. Two years ago this wiki started after a small debate in CCL, where the question of a simple and updated source of methods arose. So the wiki was created in a free web hosting for wikis (wikia), and a small bunch of small articles was written as a test, but with the hope of growing. The idea received some commendations and several constructive criticism, such as who will be the administrator and if there is a possibility to move the wiki to a more serious server where no publicity appears. Someone (I don't remember exactly who) even suggested that this should be discussed at the following WATOC meeting. The wiki didn't prosper much, since no progress was done regarding these issues.
I know that most of these projects tend to sink into oblivion, but I still think that the wiki can be extremely valuable. It is not meant to cover the general subjects (for that, wikipedia is the right place), but to give a hint on the usage of the specific methods of computational chemistry, and where can we find further references. So, if someone is interested, I invite you to visit the wiki, or even try to add a small article. It can only work if more than one person is on it. Maybe in the near future, if a better server is decided to be used, we can move those articles to its definite place.

http://computationalchemistry.wikia.com


Best,
 
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
..........Sebastian Kozuch...........
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
....Weizmann Institute of Science....
...........Rehovot, Israel...........
.. sebastian.kozuch-$-weizmann.ac.il ..
http://yfaat.ch.huji.ac.il/kozuch.htm
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


From: "Jim Kress ccl_nospam-,-kressworks.com" <owner-chemistry-$-ccl.net>
To: "Kozuch, Sebastian " <kozuchs-$-yahoo.com>
Sent: Thu, May 5, 2011 9:55:35 PM
Subject: CCL: To begin with computational chemistry

http://computationalchemistry.wikia.com/wiki/Computational_Chemistry_Wiki

 

 

From: owner-chemistry+ccl_nospam==kressworks.com..ccl.net [mailto:owner-chemistry+ccl_nospam==kressworks.com..ccl.net] On Behalf Of karthikeyan m.karthikeyan^^ncl.res.in
Sent: Thursday, May 05, 2011 11:20 AM
To: Kress, Jim
Subject: CCL: To begin with computational chemistry

 

I am bit upset with the series of discussion on 'To begin with computational chemistry'
To avoid piracy and outdated books, can we 'crowd source' a Wikibook or cloudbook on "computational chemistry"?
I am an organic chemist by education and working with chemical information for the past 15 years.
I really need to know the computational chemistry to define the 'chemical reaction space'
I try here and there, read here and there, use softwares to extent for example MOPAC, GW03, MOE, Hyperchem,
Schordinger, Accelrys etc., I think it is high time to build a 'dynamic book' because
no book is complete and could support the 'best of every available tools' to solve
chemical/molecular problems. Cloud books with detailed explanation  with
case studies as 'blogs' would really help not only 'third world countries' and even
the 'developed countries'. Just some thoughts please write your comments directly to me if any.
M.Karthikeyan
http://moltable.ncl.res.in/


--0-1300100337-1304752987=:63020-- From owner-chemistry@ccl.net Sat May 7 04:20:01 2011 From: "uekstrom[a]gmail.com uekstrom[a]gmail.com" To: CCL Subject: CCL: Program language in Quantum Chemistry: C++ or FORTRAN? Message-Id: <-44574-110507040302-4425-+lGU/EsVZYGzPkayKqg/Ow[#]server.ccl.net> X-Original-From: "uekstrom!=!gmail.com" Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Date: Sat, 7 May 2011 10:02:53 +0200 MIME-Version: 1.0 Sent to CCL by: "uekstrom::gmail.com" [uekstrom::gmail.com] On Sat, May 7, 2011 at 4:33 AM, Jun Zhang coolrainbow()yahoo.cn wrote: > > Sent to CCL by: Jun Zhang [coolrainbow]*[yahoo.cn] > Hello Everyone: > > Many new developed quantum chemistry software have been written in C++ rather than FORTRAN. Although the compilers for C++ are developing, however, due to C++'s inherent complexity, I don't think it is easier to optimize a C++ code than FORTRAN code for compilers. So why so many have chosen C++? Is it due to developing efficiency? Any suggestions will be appreciated. If you know what you are doing it's possible to write efficient C++ code as well. On the other hand there are many things which are almost impossible to program in Fortran, so you may save a lot of time programming in C++. This time can be used for implementing better algorithms, which is much more important than any perceived performance advantage of Fortran*. Also, since the Fortran market is so small the C++ compilers are much less buggy, which again saves developer time and results in better programs. * This advantage is very small, and often goes the other direction, i.e. a C program with proper use of _restrict_ is faster than the equivalent Fortran program. FFTW and ATLAS are implemented in C, for example. Nowadays it's possible to screw up performance in new interesting ways with Fortran, i.e. you should not use the built in MATMUL because it is too slow. Truly the language of scientific computing.. Sincerely, Ulf Ekstrom From owner-chemistry@ccl.net Sat May 7 04:55:00 2011 From: "Michel Petitjean petitjean.chiral!=!gmail.com" To: CCL Subject: CCL: Program language in Quantum Chemistry: C++ or FORTRAN? Message-Id: <-44575-110507042418-8189-PJpMzn5Tti3FjWnDhQadBg:-:server.ccl.net> X-Original-From: Michel Petitjean Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Date: Sat, 7 May 2011 10:24:05 +0200 MIME-Version: 1.0 Sent to CCL by: Michel Petitjean [petitjean.chiral%gmail.com] Hi, That was a long time we did not face to this discussion. I guess that many developpers choose C++ because they were taught C and then learned C++ rather than fortran. In my opinion, the difference of efficiency of optimization is not a major criteria for selecting fortran rather than C. I can understand that teaching C as first language is adequate for most cursus, but really fortran should not be discarded for those who are expected to face to math programming. Plese read some f95 manual, and try to programme some numerical algorithm (not too simple) in C or C++ and then in f95 or even in f77. What about variable dimension arguments, arrays indiced from 1 rather than 0, etc. Oh I know, fortran is considered as garbage because there is the old "GOTO" statement. But GOTO is just a more powerful version of the "break" statement available in most modern languages. In any case, these instructions should be used only when really necessary. My personal opinion is that, except for applications close to computer system, fortran is highly convenient, if not better, compared to C/C++ (the case of web applications is outside this discussion). But it is hard to find teachers knowing f95 or even f77, and teachers taught what they know, i.e., mostly C, and worse, python. Why python ? Because teachers say that students are unable to understand C as first language, so, an "easier language is better for them", supposed to let students get the desired results faster than with other languages. But please, realize that students are not more stupid than their teachers, who, sometimes, themselves were taught python rather than C (or find easier to teach python ?) ! Yes students can be taught C as a first language even if they know nothing about computers: just explain them, it is the occasion to let them really understand what they are doing when programming: ignoring what is a pointer, how a floating number is represented, or what is an ascii character, is inacceptable for a programmer. The same error is repeated along the years: students are not supposed to be able to understand concepts! Some 30-40 years ago, it was said that BASIC had to be taught first, for the same reasons that python is taught first these recent years. Fortran is the oldest soft product which survived until now (more than a half century old). Fortran and C will undoubtly both survive during a long. A serious science programmer is welcome to learn both. Other languages, I don't know. Regarding web applications, I hope that the situation will be clarified after some time. All my best, Michel Petitjean MTi, INSERM UMR-S 973, University Paris 7 35 rue Helene Brion, 75205 Paris Cedex 13, France. Phone: +331 5727 8434; Fax: +331 5727 8372 E-mail: petitjean.chiral/a\gmail.com (preferred), michel.petitjean/a\univ-paris-diderot.fr http://petitjeanmichel.free.fr/itoweb.petitjean.freeware.html 2011/5/7 Jun Zhang coolrainbow()yahoo.cn : > > Sent to CCL by: Jun Zhang [coolrainbow]*[yahoo.cn] > Hello Everyone: > > Many new developed quantum chemistry software have been written in C++ rather than FORTRAN. Although the compilers for C++ are developing, however, due to C++'s inherent complexity, I don't think it is easier to optimize a C++ code than FORTRAN code for compilers. So why so many have chosen C++? Is it due to developing efficiency? Any suggestions will be appreciated. > > Jun Zhang > Nankai University > coolrainbow- -yahoo.cn > From owner-chemistry@ccl.net Sat May 7 06:44:00 2011 From: "Michel Petitjean petitjean.chiral!=!gmail.com" To: CCL Subject: CCL: Program language in Quantum Chemistry: C++ or FORTRAN? Message-Id: <-44576-110507062046-31128-PiUtB0nmu9GwcB6mPcZufw _ server.ccl.net> X-Original-From: Michel Petitjean Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Date: Sat, 7 May 2011 12:20:37 +0200 MIME-Version: 1.0 Sent to CCL by: Michel Petitjean [petitjean.chiral{=}gmail.com] Hi, I disagree with some of the statements below. My comments are inserted in the text. Best regards, Michel Petitjean MTi, INSERM UMR-S 973, University Paris 7 CNRS SNC 9079 35 rue Helene Brion, 75205 Paris Cedex 13, France. Phone: +331 5727 8434; Fax: +331 5727 8372 E-mail: petitjean.chiral##gmail.com (preferred), michel.petitjean##univ-paris-diderot.fr http://petitjeanmichel.free.fr/itoweb.petitjean.html 2011/5/7 uekstrom[a]gmail.com uekstrom[a]gmail.com : > > Sent to CCL by: "uekstrom::gmail.com" [uekstrom::gmail.com] > On Sat, May 7, 2011 at 4:33 AM, Jun Zhang coolrainbow()yahoo.cn > wrote: >> >> Sent to CCL by: Jun Zhang [coolrainbow]*[yahoo.cn] >> Hello Everyone: >> >> Many new developed quantum chemistry software have been written in C++ rather than FORTRAN. Although the compilers for C++ are developing, however, due to C++'s inherent complexity, I don't think it is easier to optimize a C++ code than FORTRAN code for compilers. So why so many have chosen C++? Is it due to developing efficiency? Any suggestions will be appreciated. > > If you know what you are doing it's possible to write efficient C++ > code as well. On the other hand there are many things which are almost > impossible to program in Fortran, Which ones are impossible ??? Almost impossible means possible. Once adequates routines are done, anything becomes easy (bit access, string handling functions, etc.). > so you may save a lot of time programming in C++. Not true for many numerical algorithms programming. The indices starting from 0 in C/C++ are a nightmare for matrix calculus and other applications. > This time can be used for implementing better > algorithms, which is much more important than any perceived > performance advantage of Fortran*.  Also, since the Fortran market is > so small the C++ compilers are much less buggy, Is there data to support that ? I would be delighted to know about bugs for actual fortran compilers. Fortran market is much older: for this reason, producers of professional fortran compilers have all desired experience to build high quality compilers. It does not mean that the bug reports sets are void. The ones of fortran and C++ should be compared. > which again saves > developer time and results in better programs. See above. > * This advantage is very small, and often goes the other direction, > i.e. a C program with proper use of _restrict_ is faster than the > equivalent Fortran program. FFTW and ATLAS are implemented in C, for > example. Nowadays it's possible to screw up performance in new > interesting ways with Fortran, i.e. you should not use the built in > MATMUL because it is too slow. Truly the language of scientific > computing.. I do not think that there are meaningfull differences, and I do not know in favor of which they are. This is related to optimizers, not to language themselves. Benchmarks should tell us more. My opinion is that working the algorithms (complexity, precision) is by far much more important rather than having an optimizer producing the best results. > Sincerely, > Ulf Ekstrom > From owner-chemistry@ccl.net Sat May 7 10:20:01 2011 From: "Arne Dieckmann adieckma-$-googlemail.com" To: CCL Subject: CCL: iPhone & iPad 3D Molecule Browser - iMolview Message-Id: <-44577-110507054334-32762-i8jMrYjTsk0+0klqhf6rpA * server.ccl.net> X-Original-From: Arne Dieckmann Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=windows-1252 Date: Sat, 7 May 2011 11:43:22 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Sent to CCL by: Arne Dieckmann [adieckma],[googlemail.com] Dear Andrew, how about loading in your own pdb files? I'd buy it if that will be possible. Cheers, Arne On May 7, 2011, at 2:13 AM, Andrew Orry andy:_:molsoft.com wrote: > Dear All, > > MolSoft is excited to announce the release of an iPhone and iPad app that lets you browse protein, DNA, and drug molecules in 3D. The app has a direct link to the Protein Data Bank (PDB) and DrugBank and has a fast and easy to use interface. Touching the molecules via the screen allows you to interact immediately with the 3D structures in a unique way. You can zoom in and out, rotate, spin, pan, and clip the 3D molecules with your finger tips in ways that are impossible using a traditional mouse and desktop computer. > > For more details and screenshots see: http://www.molsoft.com/iMolview.html > > The key features are: > • Easy to use touch interface. > • A direct link to the Protein Data Bank (PDB) and DrugBank. > • Each molecular view can be customized with a rich set of molecular representations including: wires, balls-and-sticks, space filling, ribbon diagrams, and molecular surfaces. > • Zoom in and out, rotate, spin, pan, and clip the 3D molecule. > • A wide selection of coloring schemes is available. > • Color background, color molecule by atom type, chain, N- to C- terminal, and secondary structure. > • Select residues, atoms, or chains and color or change their representations individually. > • Select residues in sequence and get the corresponding selection in 3D. > • Select the whole chain by holding the corresponding tab. > • Display fog effect. > • Set 'inertia' to the maximum and let your molecule spin in 3D indefinitely. > • Display residue and site labels for the whole object or selection. > • Direct link to PubMed. > • Read in your own MolSoft ICM *.icb files. > We hope you enjoy using the app and find it useful for your research and teaching. We welcome any feedback you may have. > > Thanks, > Andrew > -- > Andrew Orry Ph.D. > MolSoft LLC > Senior Research Scientist > 11199 Sorrento Valley Road, S209 > San Diego > CA 92121 > Tel: 858-625-2000 x108 > Fax: 828-625-2888 > > www.molsoft.com From owner-chemistry@ccl.net Sat May 7 10:55:01 2011 From: "Jerome Kieffer jerome.Kieffer() terre-adelie.org" To: CCL Subject: CCL: Program language in Quantum Chemistry: C++ or FORTRAN? Message-Id: <-44578-110507083954-21291-Bw9Br3iXAAGREqr1YPDRUg:_:server.ccl.net> X-Original-From: Jerome Kieffer Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Date: Sat, 7 May 2011 14:39:44 +0200 Mime-Version: 1.0 Sent to CCL by: Jerome Kieffer [jerome.Kieffer%x%terre-adelie.org] Michel, I disagree with you ... I used to be a computation chemist and now I am a professional scientific python programmer (i.e. paid to write code). Not only python but "mainly" python-C python-C++ and python-fortran scientific code. Python gives productivity for prototyping, C, C++ and Fortran are used when speed is needed (i.e. only after real profiling). Fortran is a great language for scientific programming, I agree, it has even great binding to python (f2py). My main concern is about the availability of (good) fortran compiler for various platforms (mainly windows64 where only intel offers a decent compiler but this is very expensive). So fortran is a good language but a bad choice due to the absence of compiler (few compiler offer full fortran 2003 support !). Cheers. -- Jérôme KIEFFER http://www.terre-adelie.org From owner-chemistry@ccl.net Sat May 7 18:45:00 2011 From: "uekstrom++gmail.com uekstrom++gmail.com" To: CCL Subject: CCL: Program language in Quantum Chemistry: C++ or FORTRAN? Message-Id: <-44579-110507064706-22355-3xs+nifVXEjhEeHodtPgsA+*+server.ccl.net> X-Original-From: "uekstrom^-^gmail.com" Content-Type: text/plain; charset=ISO-8859-1 Date: Sat, 7 May 2011 12:46:57 +0200 MIME-Version: 1.0 Sent to CCL by: "uekstrom,+,gmail.com" [uekstrom,+,gmail.com] > Plese read some f95 manual, and try to programme some numerical > algorithm (not too simple) in C or C++ and then in f95 or even in f77. > What about variable dimension arguments, arrays indiced from 1 rather > than 0, etc. I would say that for this exercise Matlab is 10x more productive compared to Fortran, C or C++, but that doesn't mean that Matlab is the right choice for making a large quantum chemistry program. The array index thing is a trivial point in a large program, more important is how adaptable the program will be in the future, and how fast new development can take place. There's nothing wrong with using different languages for different programs, or different languages for parts of the same program. The problem with Fortran is not that Fortran 77 had some issues, those issues were often also found in early C implementations. The problem with Fortran is that the language is evolving extremely slowly and that new features cannot be used because they are inefficient (i.e. MATMUL with ifort, the "best" Fortran compiler) or because compilers are still not, in 2011, supporting Fortran 2003. Being on the Fortran standardization committee must be the most maddening experience ever. Ulf From owner-chemistry@ccl.net Sat May 7 19:37:00 2011 From: "Venable, Richard (NIH/NHLBI) E venabler---nhlbi.nih.gov" To: CCL Subject: CCL: Program language in Quantum Chemistry: C++ or FORTRAN? Message-Id: <-44580-110507191439-4767-Rz2drMk34jkAowraNFWYRA]=[server.ccl.net> X-Original-From: "Venable, Richard (NIH/NHLBI) [E]" Content-Language: en Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 7 May 2011 19:14:29 -0400 MIME-Version: 1.0 Sent to CCL by: "Venable, Richard (NIH/NHLBI) [E]" [venabler__nhlbi.nih.gov] I've recently been testing a large Fortran95 program with GCC (gfortran), Intel (ifort), and PGI (pgf95) compilers, and my observation is that the partial support for the Fortran2003 features has improved greatly in all 3 of these compilers over the past few years. A couple of these features are prevalent enough that they have been adopted for use in the program. While it's not yet full support, it is considerably better than what is implied by the blanket statement "because compilers are still not, in 2011, supporting Fortran 2003." -- Rick Venable 5635 FL/T906 Membrane Biophysics Section NIH/NHLBI Lab. of Computational Biology Bethesda, MD 20892-9314 U.S.A. On 5/7/11 6:46 AM, "Barry Hardy barry.hardy*o*vtxmail.ch" wrote: Sent to CCL by: "uekstrom,+,gmail.com" [uekstrom,+,gmail.com] > Plese read some f95 manual, and try to programme some numerical > algorithm (not too simple) in C or C++ and then in f95 or even in f77. > What about variable dimension arguments, arrays indiced from 1 rather > than 0, etc. I would say that for this exercise Matlab is 10x more productive compared to Fortran, C or C++, but that doesn't mean that Matlab is the right choice for making a large quantum chemistry program. The array index thing is a trivial point in a large program, more important is how adaptable the program will be in the future, and how fast new development can take place. There's nothing wrong with using different languages for different programs, or different languages for parts of the same program. The problem with Fortran is not that Fortran 77 had some issues, those issues were often also found in early C implementations. The problem with Fortran is that the language is evolving extremely slowly and that new features cannot be used because they are inefficient (i.e. MATMUL with ifort, the "best" Fortran compiler) or because compilers are still not, in 2011, supporting Fortran 2003. Being on the Fortran standardization committee must be the most maddening experience ever. Ulf From owner-chemistry@ccl.net Sat May 7 21:56:01 2011 From: "Igor Filippov igor.v.filippov===gmail.com" To: CCL Subject: CCL: Program language in Quantum Chemistry: C++ or FORTRAN? Message-Id: <-44581-110507123846-21515-0V6HxAoqYkc5lVQ12Cluyw**server.ccl.net> X-Original-From: Igor Filippov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Date: Sat, 07 May 2011 12:38:29 -0400 Mime-Version: 1.0 Sent to CCL by: Igor Filippov [igor.v.filippov]=[gmail.com] I would also like to add that in addition to compiler the existence of modern, supported libraries is very important. Fortran may have some great legacy libraries, but does it have the equivalent of STL or boost? I use STL containers so much it's hard to go back to more primitive types/allocators now. Best regards, Igor On Sat, 2011-05-07 at 08:39 -0400, Jerome Kieffer jerome.Kieffer() terre-adelie.org wrote: > Sent to CCL by: Jerome Kieffer [jerome.Kieffer%x%terre-adelie.org] > > Michel, > > I disagree with you ... I used to be a computation chemist and now I > am a professional scientific python programmer (i.e. paid to write > code). Not only python but "mainly" python-C python-C++ and > python-fortran scientific code. > > Python gives productivity for prototyping, C, C++ and Fortran are used > when speed is needed (i.e. only after real profiling). > > Fortran is a great language for scientific programming, I agree, it > has even great binding to python (f2py). My main concern is about the > availability of (good) fortran compiler for various platforms (mainly > windows64 where only intel offers a decent compiler but this is very > expensive). > > So fortran is a good language but a bad choice due to the absence of > compiler (few compiler offer full fortran 2003 support !). > > Cheers. > From owner-chemistry@ccl.net Sat May 7 22:31:00 2011 From: "Tom Stockfisch tomstockfisch^^^gmail.com" To: CCL Subject: CCL: Program language in Quantum Chemistry: C++ or FORTRAN? Message-Id: <-44582-110507195044-17378-RC7buUgoWb+fmXydE5uJ6A**server.ccl.net> X-Original-From: Tom Stockfisch Content-Type: multipart/alternative; boundary=Apple-Mail-4-87515273 Date: Sat, 7 May 2011 16:50:29 -0700 Mime-Version: 1.0 (Apple Message framework v753.1) Sent to CCL by: Tom Stockfisch [tomstockfisch]|[gmail.com] --Apple-Mail-4-87515273 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I think Ulf's criteria are more on point here. When you are deciding on the right language to use it is generally pointless to argue which language is better in the abstract. If all of your graduate students know C,C++,python, none of them know fortran 90, and in the future you will be even less likely to find fortran programmers then that is a way more important fact than whether you like your arrays to start at 1. If you were going to do ab initio development then fortran might be the no-brainer choice over C because most ab initio code is still developed in fortran. Tom Thomas Stockfisch, Ph.D. tom=tstockfisch.com http://www.tstockfisch.com http://www.linkedin.com/pub/tom-stockfisch/3/948/4b3 760-497-4108 On May 7, 2011, at 3:46 AM, uekstrom++gmail.com uekstrom++gmail.com wrote: > > Sent to CCL by: "uekstrom,+,gmail.com" [uekstrom,+,gmail.com] >> Plese read some f95 manual, and try to programme some numerical >> algorithm (not too simple) in C or C++ and then in f95 or even in >> f77. >> What about variable dimension arguments, arrays indiced from 1 rather >> than 0, etc. > > I would say that for this exercise Matlab is 10x more productive > compared to Fortran, C or C++, but that doesn't mean that Matlab is > the right choice for making a large quantum chemistry program. The > array index thing is a trivial point in a large program, more > important is how adaptable the program will be in the future, and how > fast new development can take place. There's nothing wrong with using > different languages for different programs, or different languages for > parts of the same program. > > The problem with Fortran is not that Fortran 77 had some issues, those > issues were often also found in early C implementations. The problem > with Fortran is that the language is evolving extremely slowly and > that new features cannot be used because they are inefficient (i.e. > MATMUL with ifort, the "best" Fortran compiler) or because compilers > are still not, in 2011, supporting Fortran 2003. Being on the Fortran > standardization committee must be the most maddening experience ever. > > Ulf > > > > -= This is automatically added to each message by the mailing > script =- > To recover the email address of the author of the message, please > change> Conferences: http://server.ccl.net/chemistry/announcements/ > conferences/> > --Apple-Mail-4-87515273 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII I think Ulf's criteria are more on point here.  When you are = deciding on the right
language to use it is generally pointless to = argue which language is better in
the abstract.  If all = of your graduate students know C,C++,python, none of them
know = fortran 90, and in the future you will be even less likely to find = fortran programmers
then that is a way more important fact = than whether you like your arrays to start at 1.
If you were = going to do ab initio development then fortran might be the = no-brainer
choice over C because most ab initio code is still = developed in fortran.

Tom

On May 7, = 2011, at 3:46 AM, uekstrom++gmail.com uekstrom++gmail.com = wrote:


Sent to CCL by: "uekstrom,+,gmail.com" = [uekstrom,+,gmail.com]
Plese read some f95 manual, and try to programme = some numerical
algorithm (not too simple) in C = or C++ and then in f95 or even in f77.
What = about variable dimension arguments, arrays indiced from 1 = rather
than 0, etc.
=

I would say that for this exercise Matlab is 10x = more productive
compared to Fortran, C or C++, = but that doesn't mean that Matlab is
the right = choice for making a large quantum chemistry program.  The
array index thing is a trivial point in a large = program, more
important is how adaptable the = program will be in the future, and how
fast new = development can take place. There's nothing wrong with using
different languages for different programs, or = different languages for
parts of the = same program.

The problem with Fortran is not that Fortran 77 had = some issues, those
issues were often also = found in early C implementations. The problem
with Fortran is that the language is evolving = extremely slowly and
that new features cannot be = used because they are inefficient (i.e.
MATMUL = with ifort, the "best" Fortran compiler) or because compilers
are still not, in 2011, supporting Fortran 2003. = Being on the Fortran
standardization committee = must be the most maddening experience ever.

Ulf



-=3D This is automatically added = to each message by the mailing script =3D-
To = recover the email address of the author of the message, please = change
the strange characters on the = top line to the = sign. You can also
look up the = X-Original-From: line in the mail header.

E-mail to = subscribers: CHEMISTRY=ccl.net = or use:

E-mail to administrators: CHEMISTRY-REQUEST=ccl.net = or use

Subscribe/Unsubscribe: 

Before posting, check wait time = at: http://www.ccl.net



If your mail = bounces from CCL with 5.7.1 error, check:




= --Apple-Mail-4-87515273-- From owner-chemistry@ccl.net Sat May 7 23:06:00 2011 From: "uekstrom..gmail.com uekstrom..gmail.com" To: CCL Subject: CCL: Program language in Quantum Chemistry: C++ or FORTRAN? Message-Id: <-44583-110507191751-6814-kQGwCfVIfGi4kzMk8bvzvg_-_server.ccl.net> X-Original-From: "uekstrom-x-gmail.com" Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Date: Sun, 8 May 2011 01:17:45 +0200 MIME-Version: 1.0 Sent to CCL by: "uekstrom/a\gmail.com" [uekstrom/a\gmail.com] >> If you know what you are doing it's possible to write efficient C++ >> code as well. On the other hand there are many things which are almost >> impossible to program in Fortran, > > Which ones are impossible ??? > Almost impossible means possible. Once adequates routines are done, > anything becomes easy (bit access, string handling functions, etc.). Of course since both Fortran and C(++) are Turing complete anything is possible (except in F77 where pointers are not standardized). Here are some almost impossible things: Destructors were not available prior to Fortran 2003, which made it difficult to deal with resources with something like resource-acquisition-is-initialization. Is garbage collection at all possible? I still don't know to make my own memory allocator in Fortran 2003, which there might be very good reasons to do in large programs that use almost all system memory. Is it possible? Can I do templates in Fortran? Saying that "anything becomes easy" in Fortran is simply ridiculous when you compare to C++ with Boost which is an incredibly rich and well designed library. If anything it's an afternoon of work in C++ to wrap BLAS with an interface that lets you use 1-based indexing and allows you to do slices. This has the advantage over plain Fortran that you are guaranteed a certain performance of the matrix multiplication routines. >> so you may save a lot of time programming in C++. > > Not true for many numerical algorithms programming. > The indices starting from 0 in C/C++ are a nightmare for matrix > calculus and other applications. This is probably true, although once you start dealing with abstract types such as sparse matrices the differences disappears. If you are allowed to make your own library of functions in Fortran I will use my BLAS wrapper for C+++, which can easily use 1-based indexing if you so desire. It has the advantage that you know exactly which BLAS you get :-) >> Also, since the Fortran market is >> so small the C++ compilers are much less buggy, > > Is there data to support that ? > I would be delighted to know about bugs for actual fortran compilers. Unfortunately I am not making this up, for every few releases of Ifort there is typically something that goes wrong, specially with -O3 and inter-procedural optimizations turned on. Some of this is clear mis-compilation or internal compiler error, some of it is hard to diagnose for large old programs that may contain bugs. This is my experience with Dalton, Dirac and once commercial program. [..] > My opinion is that working the algorithms (complexity, precision) is > by far much more important rather than having an optimizer producing > the best results. Indeed. But the OP was asking about why some new quantum chemistry programs are written in C++. I think the answer is that when you write a large program with many modules then things which are awkward in Fortran become more and more of a problem. Numerics is not everything, although Fortran makes you believe that this is the case. Sincerely, Ulf From owner-chemistry@ccl.net Sat May 7 23:40:00 2011 From: "Arun Kumar Subramanian aksub007*|*gmail.com" To: CCL Subject: CCL: what will be the best way to simulate substrate interaction only within a binding pocket of a large protein. Message-Id: <-44584-110507222251-9739-d4yAQ6mM4ErCG2aUwzOX9g(_)server.ccl.net> X-Original-From: Arun Kumar Subramanian Content-Type: multipart/alternative; boundary=0015175dd524aed7a704a2ba653d Date: Sat, 7 May 2011 19:22:40 -0700 MIME-Version: 1.0 Sent to CCL by: Arun Kumar Subramanian [aksub007##gmail.com] --0015175dd524aed7a704a2ba653d Content-Type: text/plain; charset=ISO-8859-1 Hi NAMD'ers, I am trying to simulate the interactions and conformational changes of a part of substrate within just one binding site (may be i dont want protein to be flexible) using NAMD. But it is still going to take the same amount of computational intensity (if not, atleast far higher than simulating just few amino acids) if I freeze the whole protein and allow flexibility only in that region. Moreover I need to put the protein in a box and fill it with water, that is going to add more computational cost. Is freezing a good choice if I wish to do this simulation in a desktop computer with fairly good processor. I just want to model this in a quick and approximate way. I predict that it might need around 1-2 days to simulate 1 ns of this protein fully solvated with tip3p waters in 64 processors in a cluster. Any help or suggestions to accomplish this will be appreciated. Thanks. Sincerely, ArunKumar. S. --0015175dd524aed7a704a2ba653d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi NAMD'ers,

I am trying to simulate the interaction= s and conformational changes of a part of substrate within just one binding= site (may be i dont want protein to be flexible) using NAMD.

But it is still going to take the same amount of computation= al intensity (if not, atleast far higher than simulating just few amino aci= ds) if I freeze the whole protein and allow flexibility only in that region= . Moreover I need to put the protein in a box and fill it with water, that = is going to add more computational cost. Is freezing a good choice if I wis= h to do this simulation in a desktop computer with fairly good processor. I= just want to model this in a quick and approximate way. I predict that it = might need around 1-2 days to simulate 1 ns of this protein fully solvated = with tip3p waters in 64 processors in a cluster. Any help or suggestions to= accomplish this will be appreciated.

Thanks.

Sincerely,
<= br>
ArunKumar. S.
--0015175dd524aed7a704a2ba653d--