From owner-chemistry@ccl.net Thu Sep 29 00:41:00 2005 From: "CCL" To: CCL Subject: CCL: About compiling Gaussian98 Message-Id: <-29375-050928160159-10474-bvNxekP5mXUoFpr+u4/7vQ-,-server.ccl.net> X-Original-From: "Anthony J. H. M. Meijer" Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Date: Wed, 28 Sep 2005 19:50:12 +0100 MIME-Version: 1.0 Sent to CCL by: "Anthony J. H. M. Meijer" [a.meijer-,-sheffield.ac.uk] --Replace strange characters with the "at" sign to recover email address--. On Tuesday 27 September 2005 03:24, 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! Hi, Check out http://ruby.ch.wani.osaka-u.ac.jp/nozaki/qc/g98tips.html I think it has the answers to your query. Greetings, Anthony Meijer -- ------------------------------------------------- Dr. Anthony J. H. M. Meijer Dept. of Chemistry, Room G8a University of Sheffield Sheffield S3 7HF United Kingdom Email: a.meijer-,-sheffield.ac.uk WWW: www.sheffield.ac.uk/meijergroup Tel:+44-114-222-9482 Fax:+44-114-222-9346 PGP:0xB55B90AF (On request or at keyserver) ------------------------------------------------- From owner-chemistry@ccl.net Thu Sep 29 00:56:00 2005 From: "CCL" To: CCL Subject: CCL: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29376-050929001346-23483-oFUubBI8b8HYIDholY4Ciw-x-server.ccl.net> X-Original-From: "Perry E. Metzger" Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Sep 2005 00:13:42 -0400 MIME-Version: 1.0 Sent to CCL by: "Perry E. Metzger" [perry-x-piermont.com] --Replace strange characters with the "at" sign to recover email address--. "Alex. A. Granovsky" writes: > 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 My Fortran 9x is a bit rusty, so you'll forgive me if I mistook the meaning of your example when translating. void test(int m, int n, double a[m][n], double b[m][n]) { for (int i = 0; i < n; i++) for (int j = 0; j < m; j++) a[j][i] = i * b[j][i]; } (I didn't bother testing this so don't be surprised if I got something slightly wrong.) Note there is no vectorized "whole array slice" operation available -- I suppose that's a notational deficiency, although in practice I'd just subsume that in a macro or an inline if i was doing a bunch of whole array manipulations in a row. The point here, though, was to write it as straightforwardly as possible so I did. In spite of this, the C code is a lot less verbose. As for efficiency, since you're using arrays here and not pointers, there is no pointer aliasing possible and the compiler can produce code that's pretty much identically efficient in either language -- it can vectorize it in either language if you have a vectorizing compiler and hardware. (GCC could probably vectorize a bunch of this for your SSE2 unit if you have a Pentium with one.) FYI, in the usual style people write C, you probably would write this very slightly differently -- people are used to the array index varying the other way around, as it does in most languages. BTW, some people have commented that dynamic arrays are only standard in C99. That's technically true, but they have been generally available as a compiler extension for ... well, quite a while. Perry From owner-chemistry@ccl.net Thu Sep 29 01:11:00 2005 From: "CCL" To: CCL Subject: CCL: W:Iodo NMR chemical shifts Message-Id: <-29377-050928161112-15273-EB+uiOpNuFoxdqAKjHQr8g()server.ccl.net> X-Original-From: "Gisele deFreitas Gauze" Sent to CCL by: "Gisele deFreitas Gauze" [giselegauze()yahoo.com.br] --Replace strange characters with the "at" sign to recover email address--. I am calculating chemical shifts to alfa iodine ketones, with Gaussian (3-21G and lanl2dz) and the results are very poor. Anyone knows about specific iodine basis set to perform these calculation. Thanks for while Gisele de Freitas Gauze giselegauze()yahoo.com.br Maring-Paran-Brasil From owner-chemistry@ccl.net Thu Sep 29 01:41:01 2005 From: "CCL" To: CCL Subject: CCL: NMR calculation Message-Id: <-29379-050928185938-13531-eln70fD92GohcuZC11NXnw_+_server.ccl.net> X-Original-From: =?ISO-8859-1?Q?Reynier_Suardiaz_del_R=EDo?= Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Date: Wed, 28 Sep 2005 14:09:56 -0400 MIME-Version: 1.0 Sent to CCL by: =?ISO-8859-1?Q?Reynier_Suardiaz_del_R=EDo?= [reynier_+_fq.uh.cu] --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 I think the answer is diferent if you want to calculte chamical shifts or coupling constants, in both cases my opinion is that the best choice for simple organic molecules taking into account cuality and time-consuming is to calculte within the DFT framework. In the case of chemical shifts there are a lot of papers using B3LYP / 6-311++G(d,p) with very good results, some reports favor also to PBE1PBE functional. In the case of coupling cosntants i have been obtained good results using B3LYP / EPR-III with Gaussian03 (not the first versions of G03). best reynier -- ________________________________ Reynier Suardiaz del Río Dpto. de Química Física Facultad de Química Universidad de la Habana e-mail: reynier_+_fq.uh.cu web: http://www.fq.uh.cu ________________________________ From owner-chemistry@ccl.net Thu Sep 29 01:56:01 2005 From: "CCL" To: CCL Subject: CCL: Madelung or Klechkovski ? Message-Id: <-29380-050928175649-11416-Fc3vTtWq4drNeatmxYP89w##server.ccl.net> X-Original-From: Eric Scerri Content-Type: multipart/alternative; boundary=Apple-Mail-2--686317412 Date: Wed, 28 Sep 2005 14:58:57 -0700 Mime-Version: 1.0 (Apple Message framework v733) Sent to CCL by: Eric Scerri [scerri##chem.ucla.edu] --Replace strange characters with the "at" sign to recover email address--. --Apple-Mail-2--686317412 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed the reference is, > Klechkowski, V.M., Doklady Akademii Nauk, 86: 691-694, 1951. If not I have a number of other references by this author which may =20 be what you are looking for. Interestingly the rule, by whichever name one might call it, has yet =20 to be derived from first principles. There have been attempts by the likes of Lee Allen (to my mind =20 spurious), Obadasi, Hakala, and by Ostrovsky. None of them appear =20 to be very convincing. I have written about this in the first of the two volumes dedictated =20 to Lowdin (Kluwer, 2003), and in another paper in Foundations of =20 Chemistry, vol 6, No1, 93-116, 2004. One of Ostrovsky's paper's on this subject with a full bibliography =20 of the early formulation of the rule also appears in the same =20 journal. vol 3, 145-182, 2001. regards, eric scerri On Sep 28, 2005, at 9:07 AM, CCL wrote: > > Sent to CCL by: "Xavier ASSFELD" [Xavier.Assfeld]*[cbt.uhp-nancy.fr] > > --Replace strange characters with the "at" sign to recover email =20 > address--. > > Dear CCLers, > > This is not a scientific question. This is an historico-scientific =20 > question! > > In france, in freshman chemistry, we teach that the energetic order =20= > of the > atomic orbitals is given by the "Klechkovski rules" (or =20 > Klechkowski, or > Klechkovsky, or even Klechkowsky). That is to say, the enegy =20 > increases as > (n+l) increases and for a given value of (n+l) the energy increases =20= > as n, > where n and l are the principal and azimutal quantum number. After =20 > a quick > search, I've discovered that this name is also used in Belgium, in > Swizterland, and in Canada. Surprizingly three french speaking =20 > countries... > I have found from a Belarus site that it is the Madelung-=20 > Klechkovski rules! > And in fact most english speaking countries seems to use the =20 > 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=E9oriques T: (33) 3 83 68 43 82 > Facult=E9 des Sciences F: (33) 3 83 68 43 71 > 54506 Vandoeuvre, France http://www.cbt.uhp-nancy.fr > > > > -=3D This is automatically added to each message by the mailing =20 > script =3D- > To recover the email address of the author of the message, please =20 > change> > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20 > +-+-+ > > > Dr. Eric Scerri, Department of Chemistry & Biochemistry, UCLA, Los Angeles, CA 90095-1569 E-mail scerri##chem.ucla.edu Tel: 310 206 7443 Web Page http://www.chem.ucla.edu/dept/Faculty/scerri/ Editor of Foundations of Chemistry, http://www.springerlink.com/app/=20 home/journal.asp?=20 wasp=3D5ca71bc378264971ab44b1279df63572&referrer=3Dparent&backto=3Dlinking= publ=20 icationresults,1:103024,1 Also see International Society for the Philosophy of Chemistry http://ispc.sas.upenn.edu/ --Apple-Mail-2--686317412 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1





the reference = is,


Klechkowski,=A0 V.M., Doklady Akademii Nauk, 86: 691-694, = 1951.

If = not I have a number of other references by this author which may be what = you are looking for.


Interestingly the rule, by = whichever name one might call it, has yet to be derived from first = principles.

There have been attempts by the likes of Lee = Allen (to my mind spurious), Obadasi, Hakala,=A0 and by Ostrovsky.=A0 = None of them appear to be very convincing.=A0=A0
I have written about this in the first of the = two volumes dedictated to Lowdin (Kluwer, 2003), and in another paper in = Foundations of Chemistry, vol 6, No1, 93-116, = 2004.

One of Ostrovsky's paper's = on this subject with a full bibliography of the early formulation of the = rule also appears in the same journal.=A0 vol 3, 145-182, = 2001.


regards,
eric = scerri


=A0




On Sep 28, 2005, = at 9:07 AM, CCL wrote:


Sent to = CCL by: "Xavier ASSFELD" [Xavier.Assfeld]*[cbt.uhp-nancy.fr]


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
(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?



=A0=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ...Xav

Pr. = Xavier Assfeld =A0 =A0 =A0 =A0 =A0 = =A0 Xavier.Assfeld##cbt.uhp-nan= cy.fr
Chimie et Biochimie th=E9oriques = T: (33) 3 83 68 43 82
Facult=E9 des Sciences = =A0 =A0 =A0 =A0 =A0 F: (33) = 3 83 68 43 71
54506 Vandoeuvre, France =A0 =A0 =A0 http://www.cbt.uhp-nancy.fr
=



-=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
lookup 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

Job advertising: http://www.ccl.net/jobs=A0





Dr. Eric = Scerri,

Department of Chemistry & = Biochemistry,

UCLA,

Los = Angeles,

CA = 90095-1569


E-mail scerri##chem.ucla.edu

Tel: 310 = 206 7443


Web Pagehttp://www.chem.ucl= a.edu/dept/Faculty/scerri/


Editor of = Foundations of Chemistry,=A0http://www.springerlink.com/app/home/journal.asp?wasp=3D5ca7= 1bc378264971ab44b1279df63572&referrer=3Dparent&backto=3Dlinkingpub= licationresults,1:103024,1


Also see = International Society for the Philosophy of = Chemistry

http://ispc.sas.upenn.edu/


=A0


 =

= --Apple-Mail-2--686317412-- From owner-chemistry@ccl.net Thu Sep 29 01:26:01 2005 From: "CCL" To: CCL Subject: CCL: Open source contributions by pharma. Message-Id: <-29378-050928210037-6642-P6w8PqPFoUYI0c9538dorQ(a)server.ccl.net> X-Original-From: "Peter Spiro" content-class: urn:content-classes:message Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 28 Sep 2005 16:46:51 -0700 MIME-Version: 1.0 Sent to CCL by: "Peter Spiro" [spiro(a)renovis.com] --Replace strange characters with the "at" sign to recover email address--. John, most immediately I'd like to make some contributions to Ivan Tubert-Brohman's PerlMol, a chemoinformatics and computational chemistry package that this perl addict has found very useful. I'm not familiar with Dynamol but the feature list contains a number of capabilities (conformational searching, molecular descriptiors) it'd be great to have. I'd certainly encourage you to open source it! On the subject of cheminformatics applications such as descriptor calculation, conformational search, QSAR, etc, I'd be interested to know people's recommendations for open source/free/cheap software in this area. Is there anything that comes close to, say, MOE? Best regards, Peter -----Original Message----- > From: owner-chemistry(a)ccl.net [mailto:owner-chemistry(a)ccl.net] Sent: Wednesday, September 28, 2005 12:22 PM To: Peter Spiro Subject: CCL: Open source contributions by pharma. 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(a)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(a)lists.sourceforge.net'; > 'chminf-l(a)listserv.indiana.edu'; 'chemistry(a)server.ccl.net'; > 'qsar_society(a)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. > ________________________________http://www.ccl.net/cgi-bin/ccl/send_ccl_messageThis 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 Thu Sep 29 02:11:00 2005 From: "CCL" To: CCL Subject: CCL: Few more changes and tune-ups of CCL Message-Id: <-29381-050929012635-30925-11RZJJerPUbYnNTGkiYBTw]|[server.ccl.net> X-Original-From: janl]|[speakeasy.net Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 29 Sep 2005 05:26:33 +0000 MIME-Version: 1.0 Sent to CCL by: janl]|[speakeasy.net --Replace strange characters with the "at" sign to recover email address--. Dear CCL, I hoped not to add to the busy list exchanges, but I am getting emails... I got one excellent suggestion to correct the CGI script that shows messages in the list archive at: http://www.ccl.net/chemistry/resources/messages/index.shtml to show the author of the e-mail rather than owner-chemistry... I did this... The other request, is more difficult: Show the author of the message on the From: line in your mailbox. When you list messages in your MUA (Mail User Agent) currently all messages are listed as coming from: CCL Obviously, people want to see the author in their mail index before they open the message. NOTE: the original From: line is always present in the CCL message in the HEADER as: X-Original-To: "someone" It is also on the top of each message, but sometimes you do not see it if the message is of MIME multipart variety. I am all with you on that, but... Even, if I did not bother about spyware, and used the real address on the From: line (and it has to be real, or your spam filters will junk it away), this would not work well. The problem is that with over two thousands subscribers, 10 or more addresses bounce mail. In theory, messages should be bounced to the Envelope From (i.e., the address that is often shown on the 1st Received: header line) and is given to the receiving end during SMTP handshake: Mail From: But in practice, due to diverse spam/virus fighting approaches, the original Envelope From address is not used for bounces. Machines often use From: for bounces, or even Reply-To:. Likewise, the good old Errors-To: and Sender: do not work in many cases. And I really do not want author to be swamped with bounces. I will try to come with something. It cannot be made perfect, but I will try to change the software so the From: line is From: "Info about original author" The "Info about original author" should be listed in the index of your mail. But I will not get to it today, since I made another change... Some of you will stomp on me, some will say not enough... In my opinion, the traffic on the list is sometimes too high. This happens... You just click on reply, and you do not know how many other people clicked on reply at approximately the same time. So, I added time spacing between messages. It is currently set at 15 minutes. The next messages will be distributed no less than 15 minutes after the previous message was distributed. For example: if 3 messages arrived at 1pm in 2 second intervals, the first will be posted at about 1pm, 2nd at 1:15pm, and the the 3rd on 1:30pm. We will see how it works... I will play with the parameter, and maybe it will be necessary to make it bigger. What it really means that if people submitted many e-mails, they will not appear right away. In extreme situations they may appear next day. I hate to do it to you Ladies and Gentlemen, but I hate hate mail too... {:-(}. Jan jkl]|[ccl.net From owner-chemistry@ccl.net Thu Sep 29 03:33:01 2005 From: "CCL" To: CCL Subject: CCL: Fortran vs. C - when will it end? Message-Id: <-29382-050929024908-24250-0xTIXpGETeMsS8ISjlg4Zw-,-server.ccl.net> X-Original-From: Eugen Leitl Content-Disposition: inline Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Sep 2005 08:49:04 +0200 Mime-Version: 1.0 Sent to CCL by: Eugen Leitl [eugen-,-leitl.org] --Replace strange characters with the "at" sign to recover email address--. On Wed, Sep 28, 2005 at 06:13:04PM +0200, CCL wrote: > 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 It is definitely relevant for those of us who're into numerics. > 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 disagree. Particularly the demonstration of new C features vs. Fortran was interesting, and apropos. -- Eugen* Leitl leitl ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From owner-chemistry@ccl.net Thu Sep 29 05:19:00 2005 From: "CCL" To: CCL Subject: CCL: Open source contributions by pharma. Message-Id: <-29383-050929051654-7001-bP80qyjeyaNQQXdqqsnzsg-x-server.ccl.net> X-Original-From: john furr Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Date: Thu, 29 Sep 2005 05:16:50 -0400 MIME-Version: 1.0 Sent to CCL by: john furr [john.furr-x-gmail.com] --Replace strange characters with the "at" sign to recover email address--. Peter I believe Dragon probably has the most descriptors. (~2000 I believe). Also the statistical abilities of MOE are quite unstable. It is not uncommon to get different r2 from different PLS runs with the same parameters. On the plus side you can look at the SVL. However, I don't find SVL to be a comfortable language to program. Personal preference I guess. On 9/28/05, CCL wrote: > > Sent to CCL by: "Peter Spiro" [spiro(a)renovis.com] > > --Replace strange characters with the "at" sign to recover email address--. > > John, most immediately I'd like to make some contributions to Ivan Tubert-Brohman's PerlMol, a chemoinformatics and computational chemistry package that this perl addict has found very useful. > > I'm not familiar with Dynamol but the feature list contains a number of capabilities (conformational searching, molecular descriptiors) it'd be great to have. I'd certainly encourage you to open source it! > > On the subject of cheminformatics applications such as descriptor calculation, conformational search, QSAR, etc, I'd be interested to know people's recommendations for open source/free/cheap software in this area. Is there anything that comes close to, say, MOE? > > Best regards, > Peter > > > -----Original Message----- > > From: owner-chemistry-x-ccl.net [mailto:owner-chemistry-x-ccl.net] > Sent: Wednesday, September 28, 2005 12:22 PM > To: Peter Spiro > Subject: CCL: Open source contributions by pharma. > > > > 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-x-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-x-lists.sourceforge.net'; > > 'chminf-l-x-listserv.indiana.edu'; 'chemistry-x-server.ccl.net'; > > 'qsar_society-x-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. > > ________________________________http://www.ccl.net/cgi-bin/ccl/send_ccl_messageThis 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 Thu Sep 29 06:03:00 2005 From: "CCL" To: CCL Subject: CCL: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29384-050929055333-23576-klFS503TC2zzpfYVLbewHQ#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 13:57:00 +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--. Dear Perry, > My Fortran 9x is a bit rusty, so you'll forgive me if I mistook the > meaning of your example when translating. > > void test(int m, int n, double a[m][n], double b[m][n]) > { > for (int i = 0; i < n; i++) > for (int j = 0; j < m; j++) > a[j][i] = i * b[j][i]; > } > > (I didn't bother testing this so don't be surprised if I got something > slightly wrong.) The correct sample code which was initially taken in mind by me is as follows: void test (int m, int n, double a[n][m], double b[n][m]) { for (int i = 0; i < n; i++) for (int j = 0; j < m; j++) a[i][j] = i * b[i][j]; } However, there are at least two problems with this code: 1. It is not as portable at moment as Fortran propotype is, as C99 standard is not yet supported by all compilers. For example until very recently, Intel's C/C++ compilers refused this code. 2. I was not able to get it vectorized or even unrolled with both gcc and icc compilers. This problem disappears if using original Fortran code. Best regards, Alex > > Note there is no vectorized "whole array slice" operation available -- > I suppose that's a notational deficiency, although in practice I'd > just subsume that in a macro or an inline if i was doing a bunch of > whole array manipulations in a row. The point here, though, was to > write it as straightforwardly as possible so I did. In spite of this, > the C code is a lot less verbose. > > As for efficiency, since you're using arrays here and not pointers, > there is no pointer aliasing possible and the compiler can produce > code that's pretty much identically efficient in either language -- it > can vectorize it in either language if you have a vectorizing compiler > and hardware. (GCC could probably vectorize a bunch of this for your > SSE2 unit if you have a Pentium with one.) > > FYI, in the usual style people write C, you probably would write this > very slightly differently -- people are used to the array index > varying the other way around, as it does in most languages. > > BTW, some people have commented that dynamic arrays are only standard > in C99. That's technically true, but they have been generally > available as a compiler extension for ... well, quite a while. > > > Perry > From owner-chemistry@ccl.net Thu Sep 29 06:17:00 2005 From: "CCL" To: CCL Subject: CCL: [CCL]: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29385-050929054114-22838-3Bgv28Vz/0h018aNY8dyaA^^server.ccl.net> X-Original-From: Sigismondo Boschi Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Date: Thu, 29 Sep 2005 10:17:17 +0200 (MEST) MIME-Version: 1.0 Sent to CCL by: Sigismondo Boschi [s.boschi^^cineca.it] --Replace strange characters with the "at" sign to recover email address--. CCL wrote: >>> 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. I can not resist. Doing that you introduce a new data structure (the array of pointers) to support a language feature (the double indexing skeme) and NOT to solve *the* problem. This is conceptually wrong, object oriented speaking. Furthermore it is inefficient, since you compile an indirect reference to memory, that is like, A[i][j] ~ A(B(i),j) The "only" correct way to do it (for DENSE matrices) is: A[i+n*j] ~ A(i,j) and - in c++ - to embed it in classes. ATLAS is done in that way. MTL (matrix template library) too. Nobody doing real scientific programming will introduce indirect referencing to memory where not needed, because it is SLOW. C / C++ languages has not support for dynamic multidimensional arrays, F90 does. That's all. There is nothig wrong with writing A[i+n*j]: and "n" is much less information than the array of pointers. Store "n" in a struct or class with the A pointer and use it, if you want it to be elegant. I do *like* C & C++ much more than Fortran, but the language for scientific programming is Fortran. Fortran90 today. Scientists (Chemists! Is not this C*C*L?) are presumibly not informatics and many (not all) of the scientific codes do not need high level of structuring. Furthermore scientists (generally speaking, there are exceptions) still do not have knowledge of the power of the object orinted model. Obviously there is an osmosis in progress, from the Informatics world, and when in the future new codes will be written they will be object oriented, IF needed. That's a software technolgy much over the "language" by itself. In what language does not matter, but today, writing in fortran means that the code has more chances to be shared in the scientific computing community. And that's something that eventually would need tenths of years to be changed. That's why "I do not know how it will be, but it will be named 'fortran'". This does not imply that "scientific programming must be done in fortran": research means also trying with novelle develpment methods, but that fortran is the "elective" language for this area, as C/C++ is for system programming, Java for web/communications, ... however you can write your own scientif code with C#, and outperform an equivalent fortran code, but it will be more difficult to share it with the rest of the scientific world, than it was written in fortran. I really hope this e-mail will reach the professor with whom I had the degree thesis, since I wanted to write my Monte Carlo simulation code in C... It was faster than the equivalent F77 code, and much more flexible and powerful, but it has not been developed any further when I left that research group.... Sigh! Regards, Sigismondo -- Sigismondo Boschi, Ph.D. tel: +39 051 6171559 CINECA (High Performance Systems) fax: +39 051 6137273 - 6132198 via Magnanelli, 6/3 http://instm.cineca.it 40033 Casalecchio di Reno (BO)-ITALY http://www.cineca.it From owner-chemistry@ccl.net Thu Sep 29 08:15:00 2005 From: "CCL" To: CCL Subject: CCL: Open source contributions by pharma. Message-Id: <-29386-050929080838-10883-qShz1YcrWhzYeMTdX9eKRQ===server.ccl.net> X-Original-From: Egon Willighagen Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 29 Sep 2005 13:32:37 +0200 MIME-Version: 1.0 Sent to CCL by: Egon Willighagen [e.willighagen===science.ru.nl] --Replace strange characters with the "at" sign to recover email address--. On Thursday 29 September 2005 11:16 am, CCL wrote: > Sent to CCL by: john furr [john.furr-x-gmail.com] > Peter I believe Dragon probably has the most descriptors. (~2000 I > believe). Also the statistical abilities of MOE are quite unstable. > It is not uncommon to get different r2 from different PLS runs with > the same parameters. On the plus side you can look at the SVL. > However, I don't find SVL to be a comfortable language to program. > Personal preference I guess. and > On 9/28/05, CCL wrote: > > Sent to CCL by: "Peter Spiro" [spiro(a)renovis.com] > > On the subject of cheminformatics applications such as descriptor > > calculation, conformational search, QSAR, etc, I'd be interested to know > > people's recommendations for open source/free/cheap software in this > > area. Is there anything that comes close to, say, MOE? There are two *open source* projects that do QSAR: http://joelib.sf.net/ and http://cdk.sf.net/ The subset of the QSAR capabilities of the latter can be seen on http://www.chemistry-development-kit.org/ And there is a free webservice available somewhere too... Egon From owner-chemistry@ccl.net Thu Sep 29 08:41:01 2005 From: "CCL" To: CCL Subject: CCL: Madelung or Klechkovski ? Message-Id: <-29387-050929044005-2880-SqceDpA6nTTwhM7LBdSvtg:-:server.ccl.net> X-Original-From: Paul Fleurat-Lessard Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Date: Thu, 29 Sep 2005 09:33:38 +0200 MIME-Version: 1.0 Sent to CCL by: Paul Fleurat-Lessard [Paul.Fleurat-Lessard:-:ens-lyon.fr] --Replace strange characters with the "at" sign to recover email address--. Dear Xavier, During my teaching experience in france, I also discovered that the Kelchkowki rules are, as we say in France, a cultural exception ! While searching for the origin of these rules, I found that most of the countries refer to them as 'the aufbau principle' (something like the 'construction principle'), but I have no reference about it. May be some CCLers can help us on this ! I took some time searching through some database, and Klechkowsky name never appeared... Regards, Paul. -- Fleurat-Lessard Paul, Lecturer e-mail: Paul.Fleurat-Lessard:-:ens-lyon.fr Laboratoire de Chimie Ecole Normale Supérieure de Lyon Tel: + 33 (0)4 72 72 81 54 46, Allée d'Italie Fax: + 33 (0)4 72 72 88 60 69364 Lyon Cedex 07 Si vous ne pouvez expliquer un concept à un enfant de six ans, c'est que vous ne le comprenez pas complètement. Albert Einstein From owner-chemistry@ccl.net Thu Sep 29 08:56:00 2005 From: "CCL" To: CCL Subject: CCL: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29388-050929074731-30174-5DtVt5UGAVOLf8tI3VDqFA""server.ccl.net> X-Original-From: "Dr. Ibrahim Noorbatcha" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 Sep 2005 19:02:02 +0800 MIME-Version: 1.0 Sent to CCL by: "Dr. Ibrahim Noorbatcha" [ibrahiman""iiu.edu.my] --Replace strange characters with the "at" sign to recover email address--. This thread of discussion is very interesting. I would like to see more such specific examples which will bring out the pros and cons of the programming languages. ibrahim Sent to CCL by: "Alex. A. Granovsky" [gran#classic.chem.msu.su] --Replace strange characters with the "at" sign to recover email address--. Dear Perry, > My Fortran 9x is a bit rusty, so you'll forgive me if I mistook the > meaning of your example when translating. > > void test(int m, int n, double a[m][n], double b[m][n]) > { > for (int i = 0; i < n; i++) > for (int j = 0; j < m; j++) > a[j][i] = i * b[j][i]; > } > > (I didn't bother testing this so don't be surprised if I got something > slightly wrong.) The correct sample code which was initially taken in mind by me is as follows: void test (int m, int n, double a[n][m], double b[n][m]) { for (int i = 0; i < n; i++) for (int j = 0; j < m; j++) a[i][j] = i * b[i][j]; } However, there are at least two problems with this code: 1. It is not as portable at moment as Fortran propotype is, as C99 standard is not yet supported by all compilers. For example until very recently, Intel's C/C++ compilers refused this code. 2. I was not able to get it vectorized or even unrolled with both gcc and icc compilers. This problem disappears if using original Fortran code. Best regards, Alex > > Note there is no vectorized "whole array slice" operation available -- > I suppose that's a notational deficiency, although in practice I'd > just subsume that in a macro or an inline if i was doing a bunch of > whole array manipulations in a row. The point here, though, was to > write it as straightforwardly as possible so I did. In spite of this, > the C code is a lot less verbose. > > As for efficiency, since you're using arrays here and not pointers, > there is no pointer aliasing possible and the compiler can produce > code that's pretty much identically efficient in either language -- it > can vectorize it in either language if you have a vectorizing compiler > and hardware. (GCC could probably vectorize a bunch of this for your > SSE2 unit if you have a Pentium with one.) > > FYI, in the usual style people write C, you probably would write this > very slightly differently -- people are used to the array index > varying the other way around, as it does in most languages. > > BTW, some people have commented that dynamic arrays are only standard > in C99. That's technically true, but they have been generally > available as a compiler extension for ... well, quite a while. > > > Perryhttp://www.ccl.net/cgi-bin/ccl/send_ccl_message##################################################################################### Note: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. INTERNATIONAL ISLAMIC UNIVERSITY MALAYSIA and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Thank You. ##################################################################################### From owner-chemistry@ccl.net Thu Sep 29 09:11:01 2005 From: "CCL" To: CCL Subject: CCL: Open source contributions by pharma. Message-Id: <-29389-050929050646-6477-aktu2qBpINfwUOzFValLZg^server.ccl.net> X-Original-From: peter murray-rust Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Thu, 29 Sep 2005 09:24:13 +0100 Mime-Version: 1.0 Sent to CCL by: peter murray-rust [pm286^cam.ac.uk] --Replace strange characters with the "at" sign to recover email address--. At 00:46 29/09/2005, CCL wrote: >Sent to CCL by: "Peter Spiro" [spiro(a)renovis.com] > > >On the subject of cheminformatics applications such as descriptor >calculation, conformational search, QSAR, etc, I'd be interested to >know people's recommendations for open source/free/cheap software in >this area. Is there anything that comes close to, say, MOE? > One of the approaches is to produce interoperable tools that can be combined to fit a problem. With that in mind a number of us have formed "The Blue Obelisk" - a virtual collaboration of some of the main Open groups in this area. See: http://geoffhutchison.net/blog/archives/2005/03/14/the-blue-obelisk-movement/ http://wwmm.ch.cam.ac.uk/presentations/acs2005/communal/blueobelisk.html http://almost.cubic.uni-koeln.de/jrg/pictures/blueobeliskfolder/zphotoslidesfolder_view The philosophy is: * Open: Access, Data, Standards, Source * consistent and complementary * non-divisive and fun Components include * CDK * JChempaint * Jmol * JOELib * JUMBO * NMRShiftDB * Octet * Openbabel * QSAR * WWMM The underlying concept is that all members create software to interoperate with the others. This means careful attention to interfaces, APIs, ontologies/dictionaries, reference data sets, etc. Anyone is welcome to add their project to the group as long as (a) the software is developed under an OSI license (not just "free") (b) there is a conscious effort to use communal metadata/dictionaries/reference data where possible (for example we all try to use the same atomic weights (c) Open standards (particularly W3C/XML) are used where possible. We have integrated much of this with Open workflow/pipeline systems (e.g. Taverna, Kepler) and are looking to use R for much of the statistical analysis and management. With these tools it is possible to build systems of great scope. There are currently a few components that we lack and we'd be extremely grateful for anyone who can contribute (note that data/metadata/specifications are as important as source). We also believe that WebServices (WSDL) will be extremely valuable as they can greatly reduce the problem of language and platform incompatibility. For example we have mounted an InChI server so that anyone wanting an InChI can send a WSDL request rather than have to install and wrap the InChI program. A number of Blue Obelisk members are starting to offer QSAR services or descriptors in this way P.Peter Murray-Rust Unilever Centre for Molecular Sciences Informatics University of Cambridge, Lensfield Road, Cambridge CB2 1EW, UK +44-1223-763069 From owner-chemistry@ccl.net Thu Sep 29 10:12:00 2005 From: "CCL" To: CCL Subject: CCL: W:Iodo NMR chemical shifts Message-Id: <-29393-050929095554-4504-+ZNCp63P/cMHP7ayn6iiqw/a\server.ccl.net> X-Original-From: "Shobe, David" content-class: urn:content-classes:message Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 29 Sep 2005 09:53:01 -0400 MIME-Version: 1.0 Sent to CCL by: "Shobe, David" [dshobe/a\sud-chemieinc.com] --Replace strange characters with the "at" sign to recover email address--. If you're calculating NMR properties, I'd +definitely+ stay away from ECPs. I think there are special basis sets for NMR calculations which give higher accuracy than "normal" basis sets. Typically these are double- or triple-zeta in the core AO's as well as the valence AO's. I don't have enough knowledge to be able to recommend any one of these "NMR basis sets" in particular though. --David Shobe, Ph.D., M.L.S. Süd-Chemie, Inc. phone (502) 634-7409 fax (502) 634-7724 Don't bother flaming me: I'm behind a firewall. -----Original Message----- > From: owner-chemistry/a\ccl.net [mailto:owner-chemistry/a\ccl.net] Sent: Thursday, September 29, 2005 1:12 AM To: Shobe, David Subject: CCL: W:Iodo NMR chemical shifts Sent to CCL by: "Gisele deFreitas Gauze" [giselegauze()yahoo.com.br] --Replace strange characters with the "at" sign to recover email address--. I am calculating chemical shifts to alfa iodine ketones, with Gaussian (3-21G and lanl2dz) and the results are very poor. Anyone knows about specific iodine basis set to perform these calculation. Thanks for while Gisele de Freitas Gauze giselegauze/a\yahoo.com.br Maring-Paran-Brasilhttp://www.ccl.net/cgi-bin/ccl/send_ccl_message From owner-chemistry@ccl.net Thu Sep 29 09:40:01 2005 From: "CCL" To: CCL Subject: CCL: W:Partial optimization in G03 Message-Id: <-29391-050929091355-7489-t/j/+87T0b7JhlJalKwNfg%a%server.ccl.net> X-Original-From: "Carlos Silva" Sent to CCL by: "Carlos Silva" [csilval%a%uvigo.es] --Replace strange characters with the "at" sign to recover email address--. Dera CCLers, I am triying to scan the Potential Energy Surface of a particularly capricious intramolecular reaction. I would like several coordinates (particularly a couple of dihedrals) to be restrained within a range of values so to avoid the two reactive moieties of the molecule falling apart. I notice in G03 manual that the "Frozen" option of "ModRedundant" accepts a "min" and "max" value, I am not sure if this is what I should use since there is not much info in the manual. I would appreciate if anybody could shed some light onto this problem. Regards, From owner-chemistry@ccl.net Thu Sep 29 09:58:01 2005 From: "CCL" To: CCL Subject: CCL: Fortran vs. C - when will it end? Message-Id: <-29392-050929091837-11242-pHDsReG8D4F4ySgQbhdLdQ;;server.ccl.net> X-Original-From: Steve Bowlus Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Date: Thu, 29 Sep 2005 06:18:20 -0700 MIME-Version: 1.0 Sent to CCL by: Steve Bowlus [chezbowlus;;goldrush.com] --Replace strange characters with the "at" sign to recover email address--. >>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. As a "modeler" - not a "computational chemist", much less a programmer - I have always found it useful to know some of issues facing and the vocabulary used by the developers with whom I occasionally work. Just as it is useful to know the issues and vocabulary of the organic chemists, biologists, and statisticians who work with me in drug design. I don't have to know "how" they do their jobs, but some view of "what" the relevant questions might be is handy. sb From owner-chemistry@ccl.net Thu Sep 29 09:26:01 2005 From: "CCL" To: CCL Subject: CCL: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29390-050929084536-15171-8qBlerOcAVYwJQSD340EMA-$-server.ccl.net> X-Original-From: "Perry E. Metzger" Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Sep 2005 08:45:32 -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--. "Alex. A. Granovsky" writes: > However, there are at least two problems with this code: > > 1. It is not as portable at moment as Fortran propotype is, > as C99 standard is not yet supported by all compilers. > For example until very recently, Intel's C/C++ compilers > refused this code. If by "recently" you mean "years". :) > 2. I was not able to get it vectorized or even unrolled > with both gcc and icc compilers. This problem disappears > if using original Fortran code. I have no trouble with this generating efficient code under gcc (though it might require that you use the "restrict" qualifier for it to vectorize). If you insist I'll mail out the generated assembly language but I don't think it is appropriate to bore people with this topic any more -- I'm going to drop the public discussion. Perry From owner-chemistry@ccl.net Thu Sep 29 10:29:01 2005 From: "CCL" To: CCL Subject: CCL: NMR chemical shifts - STOs v. GTOs Message-Id: <-29394-050929100233-9947-JSD7rJmIzQWjXFC1GEmRUg---server.ccl.net> X-Original-From: "Shobe, David" content-class: urn:content-classes:message Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 29 Sep 2005 09:59:38 -0400 MIME-Version: 1.0 Sent to CCL by: "Shobe, David" [dshobe---sud-chemieinc.com] --Replace strange characters with the "at" sign to recover email address--. I just thought of something. I've never heard this (I never do NMR calculations), but would a program that uses Slater-type orbitals have a huge accuracy advantage over one that uses Gaussian-type orbitals? It makes sense because the STO's are more accurate in the near-nucleus area than GTO's. --David Shobe, Ph.D., M.L.S. Süd-Chemie, Inc. phone (502) 634-7409 fax (502) 634-7724 Don't bother flaming me: I'm behind a firewall. -----Original Message----- > From: owner-chemistry---ccl.net [mailto:owner-chemistry---ccl.net] Sent: Thursday, September 29, 2005 1:12 AM To: Shobe, David Subject: CCL: W:Iodo NMR chemical shifts Sent to CCL by: "Gisele deFreitas Gauze" [giselegauze()yahoo.com.br] --Replace strange characters with the "at" sign to recover email address--. I am calculating chemical shifts to alfa iodine ketones, with Gaussian (3-21G and lanl2dz) and the results are very poor. Anyone knows about specific iodine basis set to perform these calculation. Thanks for while Gisele de Freitas Gauze giselegauze---yahoo.com.br Maring-Paran-Brasilhttp://www.ccl.net/cgi-bin/ccl/send_ccl_message From owner-chemistry@ccl.net Thu Sep 29 11:14:01 2005 From: "CCL" To: CCL Subject: CCL: Madelung or Klechkovski ? Message-Id: <-29395-050929110837-15010-ZWRW2t5blh62dMU1PTqiKw:+:server.ccl.net> X-Original-From: Anastassia Alexandrova Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Date: Thu, 29 Sep 2005 10:25:53 -0400 MIME-Version: 1.0 Sent to CCL by: Anastassia Alexandrova [anastassia.alexandrova:+:yale.edu] --Replace strange characters with the "at" sign to recover email address--. In Russia people teach Klechkovskyi rule. So another 1/6th of the World thinks it was Klechkovskyi. -- Anastassia Alexandrova, Ph.D. Yale University Department of Chemistry 225 Prospect Street New Haven, CT 06520-8107 Phone: 203-432-6288 Fax: 203-432-6144 anastassia.alexandrova:+:yale.edu http://zarbi.chem.yale.edu/~anastassia/ Quoting CCL : > > Sent to CCL by: Paul Fleurat-Lessard > [Paul.Fleurat-Lessard:-:ens-lyon.fr] > > --Replace strange characters with the "at" sign to recover email > address--. > > Dear Xavier, > > During my teaching experience in france, I also discovered that the > > Kelchkowki rules are, as we say in France, a cultural exception ! > While > searching for the origin of these rules, I found that most of the > countries refer to them as 'the aufbau principle' (something like the > > 'construction principle'), but I have no reference about it. May be > some > CCLers can help us on this ! > > I took some time searching through some database, and Klechkowsky > name > never appeared... > > Regards, > Paul. > > -- > Fleurat-Lessard Paul, Lecturer e-mail: > Paul.Fleurat-Lessard:+:ens-lyon.fr > Laboratoire de Chimie > Ecole Normale Supérieure de Lyon Tel: + 33 (0)4 72 72 81 > 54 > 46, Allée d'Italie Fax: + 33 (0)4 72 72 88 > 60 > 69364 Lyon Cedex 07 > > Si vous ne pouvez expliquer un concept à un enfant de six ans, > c'est que vous ne le comprenez pas complètement. > Albert Einstein > > > > -= This is automatically added to each message by the mailing script > =- > To recover the email address of the author of the message, please > change> > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ > > > From owner-chemistry@ccl.net Thu Sep 29 11:29:00 2005 From: "CCL" To: CCL Subject: CCL: W:madelung and aufbau principle Message-Id: <-29396-050929102512-28266-YgfEKNPo0jZ3uYs1mReWDw-x-server.ccl.net> X-Original-From: "Andreas Orthaber" Sent to CCL by: "Andreas Orthaber" [amdreas.orthaber-x-uni-graz.at] --Replace strange characters with the "at" sign to recover email address--. Hallo, The "aufbau" (build up) principle only say that electrons fill lower orbitals first. Madelungs rule gives the energetic order of orbitals ( n+ l, principle quantum number plus subsidiary quantum number ) klechovski might be the same like madelung but i can only be found on french web-sites best regards andreas orthaber From owner-chemistry@ccl.net Thu Sep 29 11:59:01 2005 From: "CCL" To: CCL Subject: CCL: Summary Madelung or Klechkovskii ? Message-Id: <-29397-050929115250-28466-ewP6+t5sa4wd4z+6VdIvMg!^!server.ccl.net> X-Original-From: "Xavier ASSFELD" Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 29 Sep 2005 17:52:32 +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--. Hi, special thanks to Eric Scerri and to Mireille Krier. Here is the ref: Klechkovskii, V.M. (n + l)-groups in the consecutive filling of electron configurations of atoms. Doklady Akademii Nauk SSSR (1951), 80 603-6. It seems that Madelung was the first one, although I havn't read the two papers yet. Thank you CCL! ...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 Thu Sep 29 13:30:00 2005 From: "CCL" To: CCL Subject: CCL: Madelung or Klechkovski /Aufbau principle Message-Id: <-29398-050929125333-23654-XhWfgZGmbWKvyOrJiHYGhw{}server.ccl.net> X-Original-From: Ken Butenhof Content-Type: multipart/alternative; boundary="=_alternative 005CBD108525708B_=" Date: Thu, 29 Sep 2005 12:53:10 -0400 MIME-Version: 1.0 Sent to CCL by: Ken Butenhof [kenb{}accelrys.com] --Replace strange characters with the "at" sign to recover email address--. This is a multipart message in MIME format. --=_alternative 005CBD108525708B_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Can someone explain how Madelung-- Klechkovski (or Kelchkowki's) rule=20 differ from=20 the Aufbau principle (Aufbauprinzip) described by Niels Bohr circa 1920? Kenneth Butenhof phone: 800 756-4674 Principal Scientist email: kenb{}accelrys.com Accelrys Inc. web: www.accelrys.com "CCL" =20 Sent by: owner-chemistry{}ccl.net 09/29/2005 10:25 AM Please respond to "CCL Subscribers" To "Butenhof, Ken " cc Subject CCL: Madelung or Klechkovski ? Sent to CCL by: Anastassia Alexandrova [anastassia.alexandrova:+:yale.edu] --Replace strange characters with the "at" sign to recover email=20 address--. In Russia people teach Klechkovskyi rule. So another 1/6th of the World=20 thinks it was Klechkovskyi. --=20 Anastassia Alexandrova, Ph.D. Yale University Department of Chemistry 225 Prospect Street New Haven, CT 06520-8107=20 Phone: 203-432-6288=20 Fax: 203-432-6144 anastassia.alexandrova{}yale.edu http://zarbi.chem.yale.edu/~anastassia/ Quoting CCL : >=20 > Sent to CCL by: Paul Fleurat-Lessard > [Paul.Fleurat-Lessard:-:ens-lyon.fr] >=20 > --Replace strange characters with the "at" sign to recover email > address--. >=20 > Dear Xavier, >=20 > During my teaching experience in france, I also discovered that the >=20 > Kelchkowki rules are, as we say in France, a cultural exception ! > While=20 > searching for the origin of these rules, I found that most of the=20 > countries refer to them as 'the aufbau principle' (something like the >=20 > 'construction principle'), but I have no reference about it. May be > some=20 > CCLers can help us on this ! >=20 > I took some time searching through some database, and Klechkowsky > name > never appeared... >=20 > Regards, > Paul. >=20 > --=20 > Fleurat-Lessard Paul, Lecturer e-mail: > Paul.Fleurat-Lessard{}ens-lyon.fr > Laboratoire de Chimie > Ecole Normale Sup=E9rieure de Lyon Tel: + 33 (0)4 72 72 81 > 54 > 46, All=E9e d'Italie Fax: + 33 (0)4 72 72 88 > 60 > 69364 Lyon Cedex 07 >=20 > Si vous ne pouvez expliquer un concept =E0 un enfant de six ans, > c'est que vous ne le comprenez pas compl=E8tement. > Albert Einstein >=20 >=20 >=20 > -=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>=20 > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ >=20 >=20 > -=3D This is automatically added to each message by the mailing script =3D-http://www.ccl.net/cgi-bin/ccl/send=5Fccl=5Fmessagehttp://www.ccl.net/cgi-bin/ccl/send=5Fccl=5Fmessage Job advertising: http://www.ccl.net/jobs=20--=20 Click on the link below to report this email as spam https://www.mailcontrol.com/sr/Fn6kLNLmVN8eBfTljOp+PEZHUEeihbupL6fNoe1YRahu= S7jsR6G+dMtRoHlUzjHw+4NaKEq4vCC4N3AcDbBM5+CCqNntONU5r4U1gUc9fU9n!4OiIDLjbpf= fOF3Drvvl5jw4ANltGpJxqfx8gsAj02!hAfoKUTbNzd9RBlstxIUnmQhx1IsJ9iX6GcBKtJSaDA= SE1fBJY82oV2JwgT4t71NOO9GFnNxV=20 --=_alternative 005CBD108525708B_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Can  someone explain how   Madelung-- Klechkovski (or Kelchkowki's) rule differ from
the  A= ufbau principle (Aufbauprinzip) described by Niels Bohr circa <= a href=3Dhttp://en.wikipedia.org/wiki/1920>1920?<= /font>


 Kenneth Butenhof          phone:  800 756-4674
Principal Scientist          email:    k= enb{}accelrys.com
Accelrys Inc.                   web:     www.accelrys.com


"CCL" <o= wner-chemistry{}ccl.net>
Sent by: owner-chemistry{}ccl.net

09/29/2005 10:25 AM
Please respond to
"CCL Subscribers" <chemistry{}ccl.net>
To
"Butenhof, Ken -id= #3p5-" <kenb{}accelrys.com>
cc
Subject
CCL: Madelung or Klechk= ovski ?






Sent to CCL by: Anastassia Alexandrova [anastassia.alexandrova:+:yale.edu]<= br>
--Replace strange characters with the "at" sign to recover email address--.

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

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


Quoting CCL <owner-chemistry{}ccl.net>:

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



-=3D This is automatically added to each message by the mailing script =3D-=      http://www.ccl.net/cgi-bin/ccl/send=5Fccl=5Fmessage
     http://www.ccl.net/cgi-bin/ccl/send=5Fccl=5Fmessage





--
Click on the link below to report this email as spam
https://www.mailcontrol.com/sr/Fn6kLNLmVN8eBfTljOp+PEZHUEeihbupL6fNoe1YRahu= S7jsR6G+dMtRoHlUzjHw+4NaKEq4vCC4N3AcDbBM5+CCqNntONU5r4U1gUc9fU9n!4OiIDLjbpf= fOF3Drvvl5jw4ANltGpJxqfx8gsAj02!hAfoKUTbNzd9RBlstxIUnmQhx1IsJ9iX6GcBKtJSaDA= SE1fBJY82oV2JwgT4t71NOO9GFnNxV

--=_alternative 005CBD108525708B_=-- From owner-chemistry@ccl.net Thu Sep 29 15:03:00 2005 From: "CCL" To: CCL Subject: CCL: NMR chemical shifts - STOs v. GTOs Message-Id: <-29399-050929145848-10438-vRHBZVa3mYxwP2W6nQ/l7Q^^server.ccl.net> X-Original-From: Mariusz Sterzel Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-362964248-1128016723=:23190" Date: Thu, 29 Sep 2005 13:58:43 -0400 (EDT) MIME-Version: 1.0 Sent to CCL by: Mariusz Sterzel [msterzel^^buffalo.edu] --Replace strange characters with the "at" sign to recover email address--. This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-362964248-1128016723=:23190 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hmm, I never did such a comparison but ADF with TZP basis set and revPBE=20 DFT functional gave me quite well results for platinum nmr for series of=20 halogen complexes, at least for Cl and Br. I do not have experimental data= =20 for iodine complexes. Frankly speaking the main problem is to choose=20 proper model for environment especialy if you have bare ions in solution.= =20 But not only bare ions have problem, I still cannot get=20 -1630 ppm for PtCl_4^{2-} with respect to PtCl_6^{2-}... life is cruel. And you can find planty of such "small" problems in literature. If you have time and free resources one can download evaluation version=20 of adf for free (www.scm.com) and check whether STOs are better than GTOs.= =20 Program is fully functional during one month as I remember. Anyway question was about best method for organic molecules. As I remember= =20 the best chemical shift results were obtained within coupled cluster=20 scheme, but DFT will be good enough. What kind of functional you should=20 use - I do not know. You can use plenty of different programs adf,=20 turbomole, gaussian, nwchem, demon and many others. I use adf because it's= =20 fast, scales allmost lineary up to 64 proc. and it has allmost everything= =20 I need. For b3-lyp calculations I would suggest turbomole or jaguar if you= =20 need fast b3-lyp. Mariusz -- Mariusz Sterzel Email: msterzel/^at^\buffalo.edu On Thu, 29 Sep 2005, CCL wrote: > > Sent to CCL by: "Shobe, David" [dshobe---sud-chemieinc.com] > > --Replace strange characters with the "at" sign to recover email address-= -. > > I just thought of something. I've never heard this (I never do NMR calcu= lations), but would a program that uses Slater-type orbitals have a huge ac= curacy advantage over one that uses Gaussian-type orbitals? It makes sense= because the STO's are more accurate in the near-nucleus area than GTO's. > > --David Shobe, Ph.D., M.L.S. > S=FCd-Chemie, Inc. > phone (502) 634-7409 > fax (502) 634-7724 > > Don't bother flaming me: I'm behind a firewall. > > > > -----Original Message----- >> From: owner-chemistry^^ccl.net [mailto:owner-chemistry^^ccl.net] > Sent: Thursday, September 29, 2005 1:12 AM > To: Shobe, David > Subject: CCL: W:Iodo NMR chemical shifts > > > Sent to CCL by: "Gisele deFreitas Gauze" [giselegauze()yahoo.com.br] > > --Replace strange characters with the "at" sign to recover email address-= -. > > I am calculating chemical shifts to alfa iodine ketones, with Gaussian (3= -21G and lanl2dz) and the results are very poor. Anyone knows about specifi= c iodine basis set to perform these calculation. > > Thanks for while > > Gisele de Freitas Gauze > giselegauze^^yahoo.com.br > Maring-Paran-Brasilhttp://www.ccl.net/cgi-bin/ccl/send_ccl_message > > > -=3D This is automatically added to each message by the mailing script = =3D-> > > > > --8323328-362964248-1128016723=:23190-- From owner-chemistry@ccl.net Thu Sep 29 15:54:01 2005 From: "CCL" To: CCL Subject: CCL: NMR chemical shifts - STOs v. GTOs Message-Id: <-29400-050929135302-31502-aNtca1aanmyfriURJUlwgA""server.ccl.net> X-Original-From: =?ISO-8859-1?Q?Reynier_Suardiaz_del_R=EDo?= Content-Type: multipart/alternative; boundary="------------050306050400040505090503" Date: Thu, 29 Sep 2005 12:53:35 -0400 MIME-Version: 1.0 Sent to CCL by: =?ISO-8859-1?Q?Reynier_Suardiaz_del_R=EDo?= [reynier""fq.uh.cu] --Replace strange characters with the "at" sign to recover email address--. --------------050306050400040505090503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit For the evaluation of coupling constants where the dominant term is the Fermi Contact would be better to use STO, but they are most time consuming and not all the coupling have these dominance (some couplings with F or N). The problem is solved using GTO with "tight s functions", the s parts of the basis set completly decontracted. The ADF program use STO and have a subprogram that compute coupling constants (CPL) i don't know a comparison but i think the difference between STO and GTO with tight s functions is negligible. -- ________________________________ Reynier Suardiaz del Río Dpto. de Química Física Facultad de Química Universidad de la Habana e-mail: reynier""fq.uh.cu web: http://www.fq.uh.cu ________________________________ CCL wrote: >Sent to CCL by: "Shobe, David" [dshobe---sud-chemieinc.com] > >--Replace strange characters with the "at" sign to recover email address--. > >I just thought of something. I've never heard this (I never do NMR calculations), but would a program that uses Slater-type orbitals have a huge accuracy advantage over one that uses Gaussian-type orbitals? It makes sense because the STO's are more accurate in the near-nucleus area than GTO's. > >--David Shobe, Ph.D., M.L.S. >Süd-Chemie, Inc. >phone (502) 634-7409 >fax (502) 634-7724 > >Don't bother flaming me: I'm behind a firewall. > > > >-----Original Message----- > > >>From: owner-chemistry""ccl.net [mailto:owner-chemistry""ccl.net] >> >> >Sent: Thursday, September 29, 2005 1:12 AM >To: Shobe, David >Subject: CCL: W:Iodo NMR chemical shifts > > >Sent to CCL by: "Gisele deFreitas Gauze" [giselegauze()yahoo.com.br] > >--Replace strange characters with the "at" sign to recover email address--. > >I am calculating chemical shifts to alfa iodine ketones, with Gaussian (3-21G and lanl2dz) and the results are very poor. Anyone knows about specific iodine basis set to perform these calculation. > >Thanks for while > >Gisele de Freitas Gauze >giselegauze""yahoo.com.br >Maring-Paran-Brasilhttp://www.ccl.net/cgi-bin/ccl/send_ccl_message> > > > > -- ________________________________ Reynier Suardiaz del Río Dpto. de Química Física Facultad de Química Universidad de la Habana e-mail: reynier""fq.uh.cu web: http://www.fq.uh.cu ________________________________ --------------050306050400040505090503 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
 For the evaluation of  coupling  constants where the dominant term is the Fermi Contact would be better to use STO, but they are most time consuming and not all the coupling have these dominance (some couplings with F or N). The problem is solved using GTO with "tight s functions", the s parts of  the basis set completly decontracted.
 The ADF program use STO and have a subprogram that compute coupling constants (CPL) i don't know a comparison but i think the difference between STO and GTO with  tight s functions is negligible.


-- 



    ________________________________
	
	Reynier Suardiaz del Río
	Dpto. de Química Física
	Facultad de Química
	Universidad de la Habana
	e-mail: reynier""fq.uh.cu
	web: http://www.fq.uh.cu
    ________________________________


CCL wrote:
Sent to CCL by: "Shobe, David" [dshobe---sud-chemieinc.com]

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

I just thought of something.  I've never heard this (I never do NMR calculations), but would a program that uses Slater-type orbitals have a huge accuracy advantage over one that uses Gaussian-type orbitals?  It makes sense because the STO's are more accurate in the near-nucleus area than GTO's.

--David Shobe, Ph.D., M.L.S.
Süd-Chemie, Inc.
phone (502) 634-7409
fax (502) 634-7724

Don't bother flaming me: I'm behind a firewall.



-----Original Message-----
  
From: owner-chemistry""ccl.net [mailto:owner-chemistry""ccl.net] 
    
Sent: Thursday, September 29, 2005 1:12 AM
To: Shobe, David
Subject: CCL: W:Iodo NMR chemical shifts


Sent to CCL by: "Gisele deFreitas Gauze" [giselegauze()yahoo.com.br]

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

I am calculating chemical shifts to alfa iodine ketones, with Gaussian (3-21G and lanl2dz) and the results are very poor. Anyone knows about specific iodine basis set to perform these calculation.

Thanks for while

Gisele de Freitas Gauze
giselegauze""yahoo.com.br
Maring-Paran-Brasilhttp://www.ccl.net/cgi-bin/ccl/send_ccl_messageE-mail to subscribers: CHEMISTRY""ccl.net or use:
      http://www.ccl.net/cgi-bin/ccl/send_ccl_message

E-mail to administrators: CHEMISTRY-REQUEST""ccl.net or use
      http://www.ccl.net/cgi-bin/ccl/send_ccl_message

Job advertising: http://www.ccl.net/jobs



-- 



    ________________________________
	
	Reynier Suardiaz del Río
	Dpto. de Química Física
	Facultad de Química
	Universidad de la Habana
	e-mail: reynier""fq.uh.cu
	web: http://www.fq.uh.cu
    ________________________________
--------------050306050400040505090503-- From owner-chemistry@ccl.net Thu Sep 29 16:29:01 2005 From: "CCL" To: CCL Subject: CCL: W:Iodo NMR chemical shifts Message-Id: <-29401-050929144606-26159-JU78qJ+Oc2NfKQXR8nUM1Q(-)server.ccl.net> X-Original-From: Rudolf Herrmann Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 29 Sep 2005 19:11:23 +0200 MIME-Version: 1.0 Sent to CCL by: Rudolf Herrmann [rudolf.herrmann(-)physik.uni-augsburg.de] --Replace strange characters with the "at" sign to recover email address--. Olá Gisele, On Thursday 29 September 2005 15:53, CCL wrote: > Sent to CCL by: "Gisele deFreitas Gauze" > I am calculating chemical shifts to alfa iodine ketones, with Gaussian > (3-21G and lanl2dz) and the results are very poor. Anyone knows about > specific iodine basis set to perform these calculation. > > Thanks for while > > Gisele de Freitas Gauze obtive resultados razoáveis para os desvios de carbono e hidrogénio com a combinação B3LYP/LANL2DZ (para todos os átomos), embora em outros sistemas (organometálicos, particularmente compostos de rénio). Acho que no seu caso existe um certo desequilíbrio entre o LANDL2DZ e o 3-21G o que pode criar estes problemas. Boa sorte, felicidades Rudolf. -- Dr. Rudolf Herrmann Institute of Physics, University of Augsburg Universitätsstr. 1 D-86135 Augsburg (Germany) e-mail: rudolf.herrmann(-)physik.uni-augsburg.de From owner-chemistry@ccl.net Thu Sep 29 17:04:00 2005 From: "CCL" To: CCL Subject: CCL: overalying small molecules Message-Id: <-29402-050929161647-29820-aSv8VTT+9wmDMeJ9yNnvww.@.server.ccl.net> X-Original-From: "Ivanciuc, Ovidiu I." content-class: urn:content-classes:message Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="Windows-1252" Date: Thu, 29 Sep 2005 15:16:38 -0500 MIME-Version: 1.0 Sent to CCL by: "Ivanciuc, Ovidiu I." [oiivanci...@...utmb.edu] --Replace strange characters with the "at" sign to recover email address--. >> I am trying to overlaying the 3D structures of two small >> molecules one which is not peptide. Is there any free >> software I can do this? You can use the following programs: PLATON (use the function FIT) http://web.mit.edu/platon_v40505/platon/docs/platon/pl000000.html quaternion-mol-fit (deposited in the CCL Software database) http://www.ccl.net/cca/software/SOURCES/C/quaternion-mol-fit/index.shtml CE (Web server) http://cl.sdsc.edu/ce.html Regards, Ovidiu ********************************* Dr. Ovidiu Ivanciuc Sealy Center for Structural Biology, Department of Human Biological Chemistry & Genetics, University of Texas Medical Branch, 301 University Boulevard, Galveston, Texas 77555-0857 USA From owner-chemistry@ccl.net Thu Sep 29 17:39:00 2005 From: "CCL" To: CCL Subject: CCL: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29403-050929163746-4988-DweIQ4W+E7gFa82h9Nsgvw^-^server.ccl.net> X-Original-From: "Perry E. Metzger" Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Sep 2005 16:37:41 -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--. "Alex. A. Granovsky" writes: > gcc version 3.3.3 Try 4.0.2. If it still doesn't work for your test function, let me know and I'll complain about it to the gcc people and see about getting it fixed. -- Perry E. Metzger perry^-^piermont.com From owner-chemistry@ccl.net Thu Sep 29 18:13:00 2005 From: "CCL" To: CCL Subject: CCL: Cleaning up dusty deck fortran and converting to C/C++ - Wrap up Message-Id: <-29404-050929164006-6177-GDTdd0/dUA6SHAn0iupE/Q#%#server.ccl.net> X-Original-From: "Robert Duke" Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A3_01C5C514.6904D7B0" Date: Thu, 29 Sep 2005 16:39:50 -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--. This is a multi-part message in MIME format. ------=_NextPart_000_00A3_01C5C514.6904D7B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, I know I said I was done, but after I said that, there were some = incorrect assertions, and a ton of verbiage about issues involved in = using array typedefs, and I want to make some clarifications in that = area. Also I want to wrap up with a few comments about some of the = development challenges that do exist in f90/95. They are not = insurmountable challenges, but if you hit them after working in c or = f77, they tend to be irritating until you understand how to deal with = them. Thanks to the folks who said they found the comparative coding = discussion helpful. My goals were to highlight the facts that: 1) f90/95 now supports most, if not all algorithms/data structures = anyone would want to use for numerical s/w development. 2) The support for the humble array is better in f90/95 than in c. 3) Porting code from f77 to f90/95 is simpler than porting it to c, with = less risk and less effort. In domains other than numerical s/w development, I immediately concede = this not to be the case, and I would use C++ when working with other s/w = professionals in those domains in a heartbeat (I only do = performance-critical code, so no need to go into what choices are better = for gui, throwaway code, etc. etc.). I am not a fortran bigot by any = means, and am sometimes chagrinned that it presents the best solution to = the problems I currently face; I had rather code in c++ for the = satisfaction associated with the cleaner abstractions, given that you = use the language in a sane fashion. Array support Okay, there was general agreement as follows: 1) Both languages do a decent job of supporting the automatic array. 2) The "array of pointers" implementation of multidimensional arrays in = c is generally not a good approach for numerical s/w for a variety of = reasons, mostly performance but also in regard to interfacing with = numerical analysis libraries that expect real arrays. 3) A common approach to the dynamic array problem in c is to simply = allocate one dimensional arrays and then calculate your own = multidimensional indices. This is inelegant and error-prone and hard to = read, but it does work. In fairness I would have to add that the use of = macros can cover up some of the ugliness here. 4) Different initial index values and index order between fortran and c, = while not presenting insurmountable problems, do present a considerable = nuisance in porting code. There was a big discussion of how to get dynamic arrays (other than = automatic arrays that are on the stack on entry to a function, but have = no persistence on exit). In particular, I submitted a snippet of code = > from Tom Plum that Perry said was incorrect, and then he went into a = fairly long discourse on the fine points of arrays, pointers, typedefs, = declarators, etc. etc. with a quiz at the end. Okay, I pretty much = understand all this stuff, but will attempt to present a more clear = example below. In the first place, there was nothing wrong at all with = the snippet of code I submitted yesterday (I had executed it), and below = is a small program that has also correctly executed (gcc, linux) that = demonstrates all the relevant points: BEGIN CODE: #include void do_something(i, j, array) int i; int j; int array[i][j][3]; /* array declarator 2 */ { int ii, jj; for (ii =3D 0; ii < i; ii++) { printf("ii=3D %d\n", ii); for (jj =3D 0; jj < j; jj++) { printf("jj=3D %d\n", jj); printf("value1=3D %d\n", array[ii][jj][0]); printf("value2=3D %d\n", array[ii][jj][1]); printf("value3=3D %d\n", array[ii][jj][2]); } } return; } int main(int argc, char ** argv) { int i, j, k; typedef int array_type[i][j][3]; /* typedef 1 */ array_type * alloc_array =3D NULL; /* array declarator 1 */ size_t alloc_size; int ii, jj; i =3D 5; j =3D 10; alloc_size =3D i * j * 3; k =3D 0; if ((alloc_array =3D (array_type *)malloc(alloc_size)) !=3D NULL) { for (ii =3D 0; ii < i; ii++) { for (jj =3D 0; jj < j; jj++) { (*alloc_array)[ii][jj][0] =3D k; (*alloc_array)[ii][jj][1] =3D k + 1; (*alloc_array)[ii][jj][2] =3D k + 2; k +=3D 3; } } do_something(i, j, alloc_array); /* note: do_something(i, j, *alloc_array); is more syntactically */ /* correct, and also happens to work... */ } else { fprintf(stderr, "Failure allocating %u bytes.\n", alloc_size); exit(1); } exit(0); } END CODE This chunk of code basically demonstrates how to create a dynamic and = persistent array at the level of main() and pass it to other functions, = and how to be able to use multidimensional indices in a fairly natural = manner in both scopes. The creation of the array in the first scope = does seem to absolutely require the use of a typedef for the array with = what is essentially late binding of the index limits (the variables i = and j). When you malloc this, you get a pointer returned, but it is = actually a "pointer to a pointer", since an array name itself is always = just the address of the first element in the array (that's what all = array names resolve to). For this reason you have to dereference the = ptr to the array ptr as shown above in the statements starting = (*alloc_array). Note however that there is a bit of linguistic = inconsistency in use of alloc_array in the function call - you can use = either *alloc_array or just plain alloc_array, and both will work. This = probably has to do with some fine points about arrays as function call = parameters. Anyway, it works, though it is a bit clunky. Normally, in = creating 1d arrays dynamically, one just creates a ptr to the type = object you want in the array, and this ptr then functions cleanly as the = array name itself, but not if you use the array typedef. Okay, going up = into do_something(), one can specify the array in the call interface in = a natural manner, and specify other call variables as the indices. = Aside from grief should you try to prototype this, this works fine, and = it is standard, fairly old c ("Reliable Data Structures in C" was = published in 1985, after all). I have not been able to get a = prototypable solution, and typedef'ing won't work because typedefs that = include variables as indices must occur within the scope of a function. Okay, what are the problems, aside from the fact that all this stuff is = not that intuitive, even for someone who has made extensive use of = dynamic data structures in the language (from my point of view, the = biggest reason to program in c has to do with just how flexible it is in = this domain)? Well, the typedef trick will not work with global scope, = as it requires function scope (I tried...). Also, the variable indices = are a potential error source, but hey, there are so many potential error = sources when you write in c, you just have to get used to it (I used to = teach assembler long ago; you really need to be careful then, but boy, = you can do anything ;-)). As far as the global scoping goes, I would = expect you can maybe get away with a cast to some global storage you = have allocated, or for that matter just use casting to get a global = array into other scopes as needed, but it is another issue, and I have = not played around enough to find all the limitations. Alright, these are all solutions; you can solve the problems in c. Is = it elegant? Not to my mind. Is it intuitive? Not even close. Is it = relatively bombproof? I'd wear a helmet. Nonetheless, I am happy that = we have all been through this exercise (not everyone may concur); for me = I was mostly resigned to using one dimensional arrays and calculating = the multidimensional indices when I needed multidimensional arrays in C; = now we have at least explored the alternatives. "Interesting" issues in building f90, and dealing with intermodule = dependencies. F90/95 compilers often ship with proprietary build tools that can handle = issues of module dependencies and manage the compilation/linking = process. That's great, unless you happen to work with just about every = machine and operating system that runs unix (that would be me). In that = case, you want to be able to use something nice and generic like make = that you will find on every system. I indeed do use make and makefiles, = but I include a homebrew perl script that can be used to sort out the = dependencies found in #include preprocessor statements, in fortran = include statements, and in f90/95 "use" statements. This works = reasonably well, but I did not come upon the solution overnight. I may = be able to share the script with anyone interested, but will have to = check. A more daunting issue is that of intermodule dependencies itself, and = the issue of circular dependencies. In c, or f77 that is = cpp-preprocessed as is the common habit, things that need to be visible = between different source files are placed in header files, and they are = "#included" everywhere they are needed. In a sense, by doing this, you = defer the interdependencies between the .c files to link time by doing = this, and they don't matter at that point - you have all the objects. = Not so with f90/95. There, you typically define modules in separate = files, and the modules so defined "use" each other as required, through = intermediation of a ".mod" file that is generated during compilation in = addition to the .o. So suppose module a uses module b, and module b = uses module a. Well to get started compiling, module a needs the b mod = file, and vice versa. You are deadlocked on a circular dependency. So = you have to lay out your data and routines in such a manner that there = are no circular dependencies (ie., all relationships must be = hierarchical, in what I believe is a directed acyclic graph). Well, = when you port code and start stuffing things into modules, it is not = going to lay out so nicely. It is very "common" to use tons of common = blocks that are expressed in headers, and if you include this stuff in = modules with code when you port, you will almost for sure generate a ton = of intermodule dependencies and be ready to rip your hair out. The = simple inelegant solution is to first put all the common data in their = own modules with no code. Then migrate stuff around as it makes sense = in terms of program structure. This works, but it is always horrific to = see all that global data out there, not bound to any particular group of = related subroutines. Well, in my experience, unless you are working in = a true object-oriented language, this is something you have to live with = to varying degrees. Best Regards - Bob Duke ------=_NextPart_000_00A3_01C5C514.6904D7B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Folks,
I know I said I was done, but after I said = that,=20 there were some incorrect assertions, and a ton of verbiage about issues = involved in using array typedefs, and I want to make some clarifications = in that=20 area.  Also I want to wrap up with a few comments about some of the = development challenges that do exist in f90/95.  They are not=20 insurmountable challenges, but if you hit them after working in c or = f77, they=20 tend to be irritating until you understand how to deal with = them.

Thanks=20 to the folks who said they found the comparative coding discussion=20 helpful.  My goals were to highlight the facts that:

1) = f90/95 now=20 supports most, if not all algorithms/data structures anyone would want = to use=20 for numerical s/w development.
2) The support for the humble array is = better=20 in f90/95 than in c.
3) Porting code from f77 to f90/95 is simpler = than=20 porting it to c, with less risk and less effort.

In domains other = than=20 numerical s/w development, I immediately concede this not to be the = case, and I=20 would use C++ when working with other s/w professionals in those domains = in a=20 heartbeat (I only do performance-critical code, so no need to go into = what=20 choices are better for gui, throwaway code, etc. etc.).  I am not a = fortran=20 bigot by any means, and am sometimes chagrinned that it presents the = best=20 solution to the problems I currently face; I had rather code in c++ for = the=20 satisfaction associated with the cleaner abstractions, given that you = use the=20 language in a sane fashion.

Array support

Okay, there was = general=20 agreement as follows:

1) Both languages do a decent job of = supporting the=20 automatic array.
2) The "array of pointers" implementation of=20 multidimensional arrays in c is generally not a good approach for = numerical s/w=20 for a variety of reasons, mostly performance but also in regard to = interfacing=20 with numerical analysis libraries that expect real arrays.
3) A common approach to the dynamic array problem in = c is to=20 simply allocate one dimensional arrays and then calculate your own=20 multidimensional indices.  This is inelegant and error-prone and = hard to=20 read, but it does work.  In fairness I would have to add that the = use of=20 macros can cover up some of the ugliness here.
4) Different initial index values and index order = between=20 fortran and c, while not presenting insurmountable problems, do present = a=20 considerable nuisance in porting code.

There was a big discussion = of how=20 to get dynamic arrays (other than automatic arrays that are on the stack = on=20 entry to a function, but have no persistence on exit).  In = particular, I=20 submitted a snippet of code from Tom Plum that Perry said was incorrect, = and=20 then he went into a fairly long discourse on the fine points of arrays,=20 pointers, typedefs, declarators, etc. etc. with a quiz at the end.  = Okay, I=20 pretty much understand all this stuff, but will attempt to present a = more clear=20 example below.  In the first place, there was nothing wrong at all = with the=20 snippet of code I submitted yesterday (I had executed it), and below is = a small=20 program that has also correctly executed (gcc, linux) that demonstrates = all the=20 relevant points:

BEGIN CODE:

#include = <stdio.h>
void
do_something(i, j, array)
  int = i;
  int=20 j;
  int array[i][j][3]; /* array declarator 2 = */
{
 =20 int ii, jj;
  for (ii =3D 0; ii < i; ii++)
 =20 {
    printf("ii=3D %d\n", ii);
    = for (jj =3D=20 0; jj < j; jj++)
    = {
     =20 printf("jj=3D %d\n", jj);
      = printf("value1=3D %d\n",=20 array[ii][jj][0]);
      printf("value2=3D = %d\n",=20 array[ii][jj][1]);
      printf("value3=3D = %d\n",=20 array[ii][jj][2]);
    }
  }
 =20 return;
}

int
main(int argc, char ** argv)
{
  int i, j,=20 k;
  typedef int array_type[i][j][3]; /* typedef 1 */
 =20 array_type * alloc_array =3D NULL; /* array declarator 1 = */
  size_t=20 alloc_size;
  int ii, jj;

  i =3D 5;
  j =3D 10;
  alloc_size =3D i = * j *=20 3;
  k =3D 0;
  if ((alloc_array =3D (array_type=20 *)malloc(alloc_size)) !=3D NULL)
  {
    for = (ii =3D 0; ii=20 < i; ii++)
    {
      = for (jj=20 =3D 0; jj < j; jj++)
     =20 {
        = (*alloc_array)[ii][jj][0] =3D=20 k;
        = (*alloc_array)[ii][jj][1] =3D k +=20 1;
        = (*alloc_array)[ii][jj][2] =3D k +=20 2;
        k +=3D=20 3;
      }
   =20 }
    do_something(i, j, = alloc_array);
   =20 /* note: do_something(i, j, *alloc_array); is more syntactically=20 */
    /* correct, and also happens to=20 work...           =             &= nbsp; =20 */
  }
  else
  {
    = fprintf(stderr,=20 "Failure allocating %u bytes.\n", alloc_size);
   =20 exit(1);
  }
  exit(0);
}
END CODE
 
This chunk of code basically demonstrates how to create a dynamic = and=20 persistent array at the level of main() and pass it to other functions, = and how=20 to be able to use multidimensional indices in a fairly natural manner in = both=20 scopes.  The creation of the array in the first scope does seem to=20 absolutely require the use of a typedef for the array with what is = essentially=20 late binding of the index limits (the variables i and j).  When you = malloc=20 this, you get a pointer returned, but it is actually a "pointer to a = pointer",=20 since an array name itself is always just the address of the first = element in=20 the array (that's what all array names resolve to).  For this = reason you=20 have to dereference the ptr to the array ptr as shown above in the = statements=20 starting (*alloc_array).  Note however that there is a bit of = linguistic=20 inconsistency in use of alloc_array in the function call - you can use = either=20 *alloc_array or just plain alloc_array, and both will work.  This = probably=20 has to do with some fine points about arrays as function call = parameters. =20 Anyway, it works, though it is a bit clunky.  Normally, in creating = 1d=20 arrays dynamically, one just creates a ptr to the type object you want = in the=20 array, and this ptr then functions cleanly as the array name itself, but = not if=20 you use the array typedef.  Okay, going up into do_something(), one = can=20 specify the array in the call interface in a natural manner, and specify = other=20 call variables as the indices.  Aside from grief should you try to=20 prototype this, this works fine, and it is standard, fairly old c = ("Reliable=20 Data Structures in C" was published in 1985, after all).  I have = not been=20 able to get a prototypable solution, and typedef'ing won't work because = typedefs=20 that include variables as indices must occur within the scope of a=20 function.
 
Okay, what are the problems, aside from the fact that all this = stuff is not=20 that intuitive, even for someone who has made extensive use of dynamic = data=20 structures in the language (from my point of view, the biggest reason to = program=20 in c has to do with just how flexible it is in this domain)?  = Well, =20 the typedef trick will not work with global scope, as it requires = function scope=20 (I tried...).  Also, the variable indices are a potential error = source, but=20 hey, there are so many potential error sources when you write in c, you = just=20 have to get used to it (I used to teach assembler long ago; you really = need to=20 be careful then, but boy, you can do anything ;-)).  As far as the = global=20 scoping goes, I would expect you can maybe get away with a cast to some = global=20 storage you have allocated, or for that matter just use casting to get a = global=20 array into other scopes as needed, but it is another issue, and I have = not=20 played around enough to find all the limitations.
 
Alright, these are all solutions; you can solve the problems in = c.  Is=20 it elegant?  Not to my mind.  Is it intuitive? Not even = close. =20 Is it relatively bombproof?   I'd wear a helmet.  = Nonetheless, I=20 am happy that we have all been through this exercise (not everyone may = concur);=20 for me I was mostly resigned to using one dimensional arrays and = calculating the=20 multidimensional indices when I needed multidimensional arrays in C; now = we have=20 at least explored the alternatives.
 
"Interesting" issues in building f90, and dealing with intermodule=20 dependencies.
 
F90/95 compilers often ship with proprietary build tools that can = handle=20 issues of module dependencies and manage the compilation/linking = process. =20 That's great, unless you happen to work with just about every machine = and=20 operating system that runs unix (that would be me).  In that case, = you want=20 to be able to use something nice and generic like make that you will = find on=20 every system.  I indeed do use make and makefiles, but I include a = homebrew=20 perl script that can be used to sort out the dependencies found in = #include=20 preprocessor statements, in fortran include statements, and in f90/95 = "use"=20 statements.  This works reasonably well, but I did not come upon = the=20 solution overnight.  I may be able to share the script with anyone=20 interested, but will have to check.
 
A more daunting issue is that of intermodule dependencies itself, = and the=20 issue of circular dependencies.  In c, or f77 that is = cpp-preprocessed as=20 is the common habit, things that need to be visible between different = source=20 files are placed in header files, and they are "#included" everywhere = they are=20 needed.  In a sense, by doing this, you defer the interdependencies = between=20 the .c files to link time by doing this, and they don't matter at = that=20 point - you have all the objects.  Not so with f90/95.  There, = you=20 typically define modules in separate files, and the modules so defined = "use"=20 each other as required, through intermediation of a ".mod" file that is=20 generated during compilation in addition to the .o.  So suppose = module a=20 uses module b, and module b uses module a.  Well to get started = compiling,=20 module a needs the b mod file, and vice versa.  You are deadlocked = on a=20 circular dependency.   So you have to lay out your data and = routines=20 in such a manner that there are no circular dependencies (ie., all = relationships=20 must be hierarchical, in what I believe is a directed acyclic = graph). =20 Well, when you port code and start stuffing things into modules, it is = not going=20 to lay out so nicely.  It is very "common" to use tons of common = blocks=20 that are expressed in headers, and if you include this stuff in modules = with=20 code when you port, you will almost for sure generate a ton of = intermodule=20 dependencies and be ready to rip your hair out.  The simple = inelegant=20 solution is to first put all the common data in their own modules with = no=20 code.  Then migrate stuff around as it makes sense in terms of = program=20 structure.  This works, but it is always horrific to see all that = global=20 data out there, not bound to any particular group of related = subroutines. =20 Well, in my experience, unless you are working in a true object-oriented = language, this is something you have to live with to varying = degrees.
 
Best Regards - Bob Duke
------=_NextPart_000_00A3_01C5C514.6904D7B0-- From owner-chemistry@ccl.net Thu Sep 29 18:49:05 2005 From: "CCL" To: CCL Subject: CCL: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29405-050929160616-28406-34rr3HPj6mMmi67mbdt+PA---server.ccl.net> X-Original-From: "Alex. A. Granovsky" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 30 Sep 2005 00:04:31 +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--. Dear Perry, > You also need the exact GCC. Which version are you using? gcc version 3.3.3 > Anyway, when I use -msse2, I seem to get references to %xmmN and such > in my assembly language output. What are you trying? > > Anyway, assuming gcc 3 or better: > > cc -S -std=c99 -march=pentium4 -msse2 -mfpmath=sse -c bar.c > > For me, that turns the core of the loop into a set of sse vector ops. Using command line: gcc -S -std=c99 -march=pentium4 -msse2 -mfpmath=sse -c test.c, I have gotten extremely unoptimized inner loop using scalar sse2 instructions. After adding -O3 option to the command line above, the inner loop becomes: .L10: movapd %xmm1, %xmm2 mulsd (%ebx,%eax), %xmm2 movsd %xmm2, (%esi,%eax) addl $8, %eax subl $1, %edx jne .L10 As you can see, the multiplication and memory references are still using scalar SSE2 and loop is not unrolled. Using icc, loop becomes unrolled, but still scalar and preserves strict memory access ordering. Using ifort 9.0 (Windows version, thus MS style listing) & original Fortran code: $B1$11: ; Preds $B1$9 $B1$11 movapd xmm2, XMMWORD PTR [esi+ebx*8] ;11.17 mulpd xmm2, xmm0 ;11.8 movapd xmm3, XMMWORD PTR [esi+ebx*8+16] ;11.17 movapd xmm4, XMMWORD PTR [esi+ebx*8+32] ;11.17 movapd xmm5, XMMWORD PTR [esi+ebx*8+48] ;11.17 movapd XMMWORD PTR [edi+ebx*8], xmm2 ;11.8 mulpd xmm3, xmm0 ;11.8 movapd XMMWORD PTR [edi+ebx*8+16], xmm3 ;11.8 mulpd xmm4, xmm0 ;11.8 movapd XMMWORD PTR [edi+ebx*8+32], xmm4 ;11.8 mulpd xmm5, xmm0 ;11.8 movapd XMMWORD PTR [edi+ebx*8+48], xmm5 ;11.8 add ebx, 8 ;11.8 cmp ebx, ecx ;11.8 jb $B1$11 ; Prob 97% ;11.8 jmp $B1$16 ; Prob 100% ;11.8 ALIGN 4 ALIGN 4 ; LOE eax ecx ebx esi edi xmm0 xmm1 $B1$14: ; Preds $B1$9 $B1$14 movsd xmm2, QWORD PTR [esi+ebx*8] ;11.17 movhpd xmm2, QWORD PTR [esi+ebx*8+8] ;11.17 mulpd xmm2, xmm0 ;11.8 movsd xmm3, QWORD PTR [esi+ebx*8+16] ;11.17 movhpd xmm3, QWORD PTR [esi+ebx*8+24] ;11.17 movsd xmm4, QWORD PTR [esi+ebx*8+32] ;11.17 movhpd xmm4, QWORD PTR [esi+ebx*8+40] ;11.17 movsd xmm5, QWORD PTR [esi+ebx*8+48] ;11.17 movhpd xmm5, QWORD PTR [esi+ebx*8+56] ;11.17 movapd XMMWORD PTR [edi+ebx*8], xmm2 ;11.8 mulpd xmm3, xmm0 ;11.8 movapd XMMWORD PTR [edi+ebx*8+16], xmm3 ;11.8 mulpd xmm4, xmm0 ;11.8 movapd XMMWORD PTR [edi+ebx*8+32], xmm4 ;11.8 mulpd xmm5, xmm0 ;11.8 movapd XMMWORD PTR [edi+ebx*8+48], xmm5 ;11.8 add ebx, 8 ;11.8 cmp ebx, ecx ;11.8 jb $B1$14 ; Prob 97% ;11.8 As you can see, there are two versions of the inner loop for two possible cases of data alignment, as it should be. Both are unrolled & vectorized, i.e, use vectorized memory access and multiplication commands. Thus, I would suppose that in C99 passing arrays does not imply that there are no aliasing across them, on the other hand it is now impossible to use restrict qualifier to explicitly declare this. This effectively disables advanced unrolling & vectorization Best regards, Alex Granovsky From owner-chemistry@ccl.net Thu Sep 29 19:24:00 2005 From: "CCL" To: CCL Subject: CCL: W:Identifying bridgehead atoms Message-Id: <-29406-050929191748-27572-7/wWlOOY1Wx0xMPIKqzDGw%a%server.ccl.net> X-Original-From: "Richard Hull" Sent to CCL by: "Richard Hull" [hull%a%axontologic.com] --Replace strange characters with the "at" sign to recover email address--. Are there any published algorithms for identifying bridgehead atoms within polycyclic ring systems, particularly for 2-D connection tables? I am most interested in topological properties of the corresponding chemical graph that can be exploited. Any pointers would be greatly appreciated. Best, Richard Hull hull%a%axontologic.com From owner-chemistry@ccl.net Thu Sep 29 21:26:00 2005 From: "CCL" To: CCL Subject: CCL: W:How to represent a 2-D cell in tinker? Message-Id: <-29407-050929212436-21961-G/l8mIwC15BzXvFtcHwiPw^^^server.ccl.net> X-Original-From: "Qing Shao" Sent to CCL by: "Qing Shao" [shaoqingfly1981^^^gmail.com] --Replace strange characters with the "at" sign to recover email address--. CCLers: Could you give me some advices on how to represent cell which has periodic condition only in X-axis and Y-axis in Tinker? I once attempted to use the a vacuum in the Z-axis so the periodic condition of Z-axis would vanished. But I cannot find a parameter about it. Is there any other method? Please give me some adivces on it. Thanks in advance. Qing Shao