From states@ibc.wustl.edu Sat May 6 08:48:52 1995 Received: from medicine for states@ibc.wustl.edu by www.ccl.net (8.6.10/930601.1506) id IAA09948; Sat, 6 May 1995 08:45:02 -0400 Received: from ibc.WUStL.EDU (ibc.wustl.edu [128.252.122.174]) by medicine (8.6.11/8.6.5) with SMTP id HAA14751 for ; Sat, 6 May 1995 07:40:18 -0500 Received: by ibc.WUStL.EDU (5.x/SMI-SVR4) id AA20433; Sat, 6 May 1995 07:45:00 -0500 Date: Sat, 6 May 1995 07:45:00 -0500 From: states@ibc.wustl.edu (David J. States) Message-Id: <9505061245.AA20433@ibc.WUStL.EDU> To: CHEMISTRY@ccl.net Subject: Re: CCL:TCL Comp. Chem tools.. |> > Before everyone becomes too enthusiastic about Tcl, I would like |> > to point out that Tcl - like most "scripting" languages - is |> > very limited, especially when it comes to data manipulation. |> > If all you want is to automatize a short sequence of actions, |> > that's fine - but don't expect more from it. |> |> Actually, you really are selling Tcl short. Some very nice applications can |> be and have been written using Tcl and the various extensions that are |> available. It *is* a complete programming language. The portability, |> extensibility, and lisp-like ability to treat code as data and vice-versa |> make it ideal for developing large heterogeneous distributed systems. Having inadvertantly touched off a lively on Tcl, let me ask, what about TkPerl? People use Tcl in order to use Tk. Without the Tk GUI tools, I don't think there would be much enthusiasm for Tcl just as a scripting language. At least some of us find it hard to deal with the lisp-like syntax of Tcl and already work in perl (what can I say, I also prefer vi over emacs, C over C++, and live in the midwest). Perl has established its vaiability as a programming language in its own right, and Perl5 fixes many of the rough edges in earlier versions (pointers, multidimensional arrays, foreign language interfaces, ...). Perl is also a compiled language which gives it better compute performance, and perl has a very rich set of intrinsics and extensions (regular expressions, system calls, RDBMS interfaces, etc.). So how come no comments on Perl/TkPerl in all the Tcl/Tk discussion? David States Institute for Biomedical Computing / Washington University in St. Louis From hinsenk@ERE.UMontreal.CA Sat May 6 10:18:53 1995 Received: from condor.CC.UMontreal.CA for hinsenk@ERE.UMontreal.CA by www.ccl.net (8.6.10/930601.1506) id KAA10329; Sat, 6 May 1995 10:08:00 -0400 Received: from eole.ERE.UMontreal.CA by condor.CC.UMontreal.CA with SMTP id AA22325 (5.65c/IDA-1.4.4 for chemistry@ccl.net); Sat, 6 May 1995 10:07:43 -0400 Received: from cyclone.ERE.UMontreal.CA by eole.ERE.UMontreal.CA (940406.SGI/5.17) id AA29296; Sat, 6 May 95 10:07:42 -0400 Received: by cyclone.ERE.UMontreal.CA (940406.SGI/5.17) id AA25003; Sat, 6 May 95 10:07:41 -0400 Date: Sat, 6 May 95 10:07:41 -0400 From: hinsenk@ERE.UMontreal.CA (Hinsen Konrad) Message-Id: <9505061407.AA25003@cyclone.ERE.UMontreal.CA> To: ejfried@herzberg.ca.sandia.gov Cc: chemistry@ccl.net In-Reply-To: <9505051414.ZM21463@herzberg> (ejfried@herzberg.ca.sandia.gov) Subject: Re: CCL:TCL Comp. Chem tools.. Hinsen Konrad (hinsenk@ERE.UMontreal.CA) has been railing against the use of Tcl for scripting chemistry tools, and against the premature establishment of standards. Don't get me wrong: I have nothing against Tcl *for scripting*. That's what it was made for. I was just pointing out that one should not miss the opportunity to get something better than a mere scripting language. Folks with PCs used them to design today's better architectures. No one said, "everyone must use the PC-clone architecture." It just happened, and as a result, computers became cheap commodities and the world benefitted immeasurably. And the world would have benefitted much more if more companies had developed innovative concepts for one or two more years instead of cloning the IBM PC, whose conceptual problems were evident when it came out. But I don't really blame anyone for that development. I am just proposing that one should learn from the mistakes of the past and not repeat them. Structured programming would never have been invented if the power of high-level language programming hadn't been demonstrated by FORTRAN. Again, I don't blame anyone for developing or using Fortran. Fortran was an enormous step forward, compared to machine languages. I blame those who failed to explore alternatives and forced generations of scientists and engineers to stick with it even after its weaknesses became appearant. The advantages of modern object-oriented languages compared to Fortran (I am always referring to Fortran 77) are as important as were the advantages of Fortran compared to Assembler in the late 50s. ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. A | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- From hinsenk@ERE.UMontreal.CA Sat May 6 10:48:54 1995 Received: from condor.CC.UMontreal.CA for hinsenk@ERE.UMontreal.CA by www.ccl.net (8.6.10/930601.1506) id KAA10584; Sat, 6 May 1995 10:39:43 -0400 Received: from eole.ERE.UMontreal.CA by condor.CC.UMontreal.CA with SMTP id AA22534 (5.65c/IDA-1.4.4 for CHEMISTRY@ccl.net); Sat, 6 May 1995 10:39:24 -0400 Received: from cyclone.ERE.UMontreal.CA by eole.ERE.UMontreal.CA (940406.SGI/5.17) id AA04779; Sat, 6 May 95 10:39:23 -0400 Received: by cyclone.ERE.UMontreal.CA (940406.SGI/5.17) id AA25517; Sat, 6 May 95 10:39:22 -0400 Date: Sat, 6 May 95 10:39:22 -0400 From: hinsenk@ERE.UMontreal.CA (Hinsen Konrad) Message-Id: <9505061439.AA25517@cyclone.ERE.UMontreal.CA> To: states@ibc.wustl.edu Cc: CHEMISTRY@ccl.net In-Reply-To: <9505061245.AA20433@ibc.WUStL.EDU> (states@ibc.wustl.edu) Subject: Re: CCL:TCL Comp. Chem tools.. Having inadvertantly touched off a lively on Tcl, let me ask, what about TkPerl? People use Tcl in order to use Tk. Without the Tk GUI tools, I don't think there would be much enthusiasm for Tcl just as a scripting language. At least some of us find it hard to deal with the Tk is one reason for Tcl's popularity, but there is also the fact that it is an embeddable language, which Perl isn't. There are indeed other alternatives for Tk; in addition to TkPerl, there is also a Scheme interface to Tk. There are alse other embeddable languages, including more powerful ones that Tcl (Python for example). ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. A | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- From toukie@zui.unizh.ch Sat May 6 16:33:58 1995 Received: from rzusuntk.unizh.ch for toukie@zui.unizh.ch by www.ccl.net (8.6.10/930601.1506) id QAA12786; Sat, 6 May 1995 16:31:03 -0400 Received: by rzusuntk.unizh.ch (4.1/SMI-4.1.9) id AA07781; Sat, 6 May 95 22:31:02 +0200 X-Nupop-Charset: Swiss Date: Sat, 6 May 1995 22:30:51 +0100 (MET) From: "Hr Dr. S. Shapiro" Sender: toukie@zui.unizh.ch Reply-To: toukie@zui.unizh.ch Message-Id: <81051.toukie@zui.unizh.ch> To: chemistry@ccl.net Subject: Seeking .pdb membrane files Dear Colleagues; I have been asked to help prepare a display cabinet for the general public about cell membranes. I am seeking either .pdb files of synthetic or natural (biological) membranes, and/or other computer graphics depict- ing membrane structure/function, especially graphics illustrating the interactions (or proposed interactions) between membranes and membranotropic agents. If you have any such graphics files that you can share with me, or can direct me to an FTPable directory from which such graphics files can be downloaded, kindly send _specifics_ to toukie@zui.unizh.ch Thanks in advance to all responders. Sincerely, (Dr.) S. Shapiro Institut fuer orale Mikrobiologie und allgemeine Immunologie Zentrum fuer Zahn-, Mund- und Kieferheilkunde der Universitaet Zuerich Plattenstrasse 11 Postfach CH-8028 Zuerich 7 Switzerland toukie@zui.unizh.ch FAX-nr: ( ... + 1) 261'56'83 From m10!frisch@uunet.uu.net Sat May 6 17:04:01 1995 Received: from relay3.UU.NET for m10!frisch@uunet.uu.net by www.ccl.net (8.6.10/930601.1506) id QAA12981; Sat, 6 May 1995 16:56:37 -0400 Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQyopf26067; Sat, 6 May 1995 16:56:37 -0400 Message-Id: Received: from m10.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Sat, 6 May 1995 16:56:37 -0400 Received: by m10.gaussian.com; Sat, 6 May 1995 16:54:00 -0400 From: m10!frisch@uunet.uu.net (Michael Frisch) Subject: CCL:Scan=Opt in G94 (fwd) To: chemistry@ccl.net Date: Sat, 6 May 1995 16:53:59 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1725 Gavin Tasai asked about relaxed potential surface scans in Gaussian 94. The defaults are enough different in G94 for both optimizations and scans that this is worth a general reply. In Gaussian 94 the default is to do optimizations, including relaxed scans, in redundant internal coordinates. This is done indentically regardless of whether the initial structure is specified as cartesians or a Z-matrix, and there is no connection between how the z-matrix, if any, is specified and the coordinates used in the calculation. When information about the coordinates used in the optimization is required, as is the case if you specificy Opt=AddRedundant to add/change coordinates, Opt Geom=Modify to read in a structure but then modify coordinates, or Scan=Opt (which is really synonymous with Opt=AddRedundant since optimizations and relaxed scans are handled identically), then the information is read in a format which allows any of the possible redundant internal coordinates to be specified. For example: 1 2 3 f 95.0 adds the angle between atoms 1, 2, and 3 if it is not already in the redunant coordinate set and freeze it at 95 degrees. Similary, 2 4 s 3 0.1 Makes the bond between atoms 2 and 4 a variable to be scanned with 3 steps of 0.1 angstroms. In redundant optimizations, information on z-matrix variable definition cards other than the value of the variable has no effect. It is also possible to do relaxed scans in z-matrix coordinates by specifying Opt=Z-matrix on the route card and then indicating which variables are to be scanned on the variable definition lines as is done for non-relaxed scans. Scan=(Opt,Z-Matrix) should be accepted as a synonym for Opt=Z-Matrix, but it isn't. Mike Frisch From b_duke@lacebark.ntu.edu.au Sat May 6 18:18:59 1995 Received: from lacebark.ntu.edu.au for b_duke@lacebark.ntu.edu.au by www.ccl.net (8.6.10/930601.1506) id SAA13648; Sat, 6 May 1995 18:10:59 -0400 From: Received: by lacebark.ntu.edu.au (AIX 3.2/UCB 5.64/4.03) id AA08073; Sun, 7 May 1995 07:30:45 +1100 Message-Id: <9505062030.AA08073@lacebark.ntu.edu.au> Subject: Gaussian and Raman intensities. To: CHEMISTRY@ccl.net (chemistry) Date: Sun, 7 May 1995 07:30:45 +1000 (EETDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1081 Hi folks, I have normally not been interested in Raman intensities using G92/DFT so I have used freq=noraman to save time. I now have a project where the experimentalist needs them. For RHF there is no problem, but can Gaussian compute them for post RHF methods. With MP2 and DFT methods using freq on the command line does not give them. I would be also interested in whether they can be obtained with numerical 2nd derivatives - freq=numer. The manual is not clear on these points. It seems to suggest that they are available for all methods with analytic 2nd derivatives but only ir intensities come out with MP2 and DFT. If G94 is different I would be interested to know. I do not have a manual for G94 but I do have access to it in a limited way on a supercomputer. I will summarise responses. Cheers, Brian. -- Associate Professor Brian Salter-Duke (Brian Duke) School of Mathematical and Physical Sciences, Northern Territory University, Darwin, NT 0909, Australia. Phone 089-466702 e-mail: b_duke@lacebark.ntu.edu.au or b_duke@uncl04.ntu.edu.au From b_duke@lacebark.ntu.edu.au Sat May 6 18:49:00 1995 Received: from lacebark.ntu.edu.au for b_duke@lacebark.ntu.edu.au by www.ccl.net (8.6.10/930601.1506) id SAA13918; Sat, 6 May 1995 18:37:40 -0400 From: Received: by lacebark.ntu.edu.au (AIX 3.2/UCB 5.64/4.03) id AA06812; Sun, 7 May 1995 07:57:26 +1100 Message-Id: <9505062057.AA06812@lacebark.ntu.edu.au> Subject: CCL:A BLYP/Becke3LYP frequency problem in G92/DFT - Summary To: CHEMISTRY@ccl.net (chemistry) Date: Sun, 7 May 1995 07:57:26 +1000 (EETDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2315 Some time ago I posted the following problem about getting poor "zero" frequencies with G92/DFT. > I have been using BLYP and Becke3LYP for some large systems where > MP2 frequencies are not feasible here with some success. With one system > I have a problem. The molecule has D2h symmetry and is like diborane. > Experimentally we know this but are using theory to help the neutron > diffraction studies and to sort out the i.r./Raman bands. > > SCF gives reasonable results with two basis sets. BLYP and Becke3LYP > give similar geometries to the SCF but the SCF gives one imaginary > frequency. However the 3 "zero" rotational frequencies are roughly > -30, -20 and -8. The imag freq is -40. I used opt=tight and Int=FineGrid. > The frequency run still shows the forces and predicted displacements > to be good. > Several people offered suggestions. The most comprehensive reponse was from Benny Johnson:_ -------------------------------------------------------------------- The main reason for nonzero DFT rotational frequencies in Gaussian is the lack of proper rotational invariance in the quadrature grid. This is discussed in B. G. Johnson and M. J. Frisch Chem. Phys. Lett. 216, 133 (1993). and a rigorous solution is given in B. G. Johnson, P. M. W. Gill and J. A. Pople Chem. Phys. Lett. 220, 377 (1994). Hope this helps, Benny Johnson Q-Chem, Inc. ------------------------------------------------------------------- I also thank Ross Nobes and Tony Scott for help. The problem can be overcome, at least with G94. It is important to use opt=tight or opt=verytight and a fine grid. With G92/DFT the finest grid is obrained with Int=FineGrid. For my case this was not good enough. For G94 Int=FineGrid is now the default and various finer grids are possible. I was able to get good results with a finer grid. I thinh the details are in the manual but I do not have a copy. Ross Nobes gave me the details. A proper fix is coming out in QChem. I think that summarises the replies that pointed to the problem. Cheers, Brian. -- Associate Professor Brian Salter-Duke (Brian Duke) School of Mathematical and Physical Sciences, Northern Territory University, Darwin, NT 0909, Australia. Phone 089-466702 e-mail: b_duke@lacebark.ntu.edu.au or b_duke@uncl04.ntu.edu.au From states@ibc.wustl.edu Sat May 6 21:34:03 1995 Received: from medicine for states@ibc.wustl.edu by www.ccl.net (8.6.10/930601.1506) id VAA14751; Sat, 6 May 1995 21:28:40 -0400 Received: from ibc.WUStL.EDU (ibc.wustl.edu [128.252.122.174]) by medicine (8.6.11/8.6.5) with SMTP id UAA25441; Sat, 6 May 1995 20:23:56 -0500 Received: by ibc.WUStL.EDU (5.x/SMI-SVR4) id AA25313; Sat, 6 May 1995 20:28:39 -0500 Date: Sat, 6 May 1995 20:28:39 -0500 From: states@ibc.wustl.edu (David J. States) Message-Id: <9505070128.AA25313@ibc.WUStL.EDU> To: states@ibc.WUStL.EDU, hinsenk@ERE.UMontreal.CA Subject: Re: CCL:TCL Comp. Chem tools.. Cc: CHEMISTRY@ccl.net X-Sun-Charset: US-ASCII |> Tk is one reason for Tcl's popularity, but there is also the fact |> that it is an embeddable language, which Perl isn't. There are |> indeed other alternatives for Tk; in addition to TkPerl, there is |> also a Scheme interface to Tk. |> |> There are alse other embeddable languages, including more powerful |> ones that Tcl (Python for example). One of the major new features of perl 5 is embedding. Both perl->C and C->perl interfaces are provided. If you were frustrated by some of the limitations of perl 4, it might be worth taking another look. David States Institute for Biomedical Computing / Washington University in St. Louis