From noertema@theochem.tu-muenchen.de Mon Jul 21 04:12:27 1997 Received: from hp1.theochem.tu-muenchen.de for noertema@theochem.tu-muenchen.de by www.ccl.net (8.8.3/950822.1) id EAA05401; Mon, 21 Jul 1997 04:06:58 -0400 (EDT) Message-Id: <199707210806.EAA05401@www.ccl.net> Received: by hp1.theochem.tu-muenchen.de (1.38.193.4/16.2) id AA00885; Mon, 21 Jul 1997 10:06:52 +0200 From: Folke Noertemann To: chemistry@www.ccl.net Subject: internal coord. -> cartesian Date: Mon Jul 21 09:40:40 1997 Reply-To: noertema@theochem.tu-muenchen.de Dear CCL'ers, I am currently trying to write my own geometry-optimization tool and my question refers to the summary 'internal->cartesian' in the CCL archive. I have implemented a method to convert from internal coordinates to cartesian coordinates which has also been outlined by Heinz Schiffer, that is 1.) given a set of cartesian coordinates, I calculate a set of bond lengths, angles and dihedral angles and, as a byproduct a Wilson Matrix B containing the partial derivates d q_j/d x_i (q : internal coordinates, x: cartesian coordinates) is set up. 2.) A step is made: q_old -> q_new 3.) The inverse of B (B_inv) is used to calculate x_new-x_old = B_inv [x_old] *(q_new-q_old). 4.) Using x_new, step 1 is used to recalculate a set of internals q_test. If q_test=q_new, I am done. If not, the process is repeated , updating B_inv [x] until it reproduces the correct q_new. It works fine for bond lengths. Since B contains only unit vectors the process is *converged* in one step. If I am using steps in bond angles I am unable to get the difference between the actual angle update and the converged result below 5 percent. For realistic angle updates (such as ~10 degrees) it is around 10 percent. My understanding was, that the iterative process should take care of the fact that the steps are NOT infinitesimal thus converging to exactly the desired step. The code is so embarrasingly simple that I either made a very dumb mistake or (and this is my question) I do not understand this iterative process. Is it supposed to converge to exactly q_new or not? Thank you very much in advance, F. Noertemann -- \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Folke Noertemann \_ Lehrstuhl f. theoret. Chemie \_ TU Muenchen \_ Lichtenbergstr. 4 \_ D-85747 Garching \_ \_ e-mail: noertema@theochem.tu-muenchen.de \_ phone : 089 - 289 13609 \_ \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ From noertema@theochem.tu-muenchen.de Mon Jul 21 05:12:34 1997 Received: from theo1.theochem.tu-muenchen.de for noertema@theochem.tu-muenchen.de by www.ccl.net (8.8.3/950822.1) id EAA05444; Mon, 21 Jul 1997 04:21:52 -0400 (EDT) Received: (from noertema@localhost) by theo1.theochem.tu-muenchen.de (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA15150; Mon, 21 Jul 1997 10:21:51 +0200 Date: Mon, 21 Jul 1997 10:21:51 +0200 Message-Id: <199707210821.KAA15150@theo1.theochem.tu-muenchen.de> From: Folke Noertemann To: chemistry@www.ccl.net Subject: internal coordinates->cartesian Dear CCL'ers, (sorry if this occurs twice in the list!) I am currently trying to write my own geometry-optimization tool and my question refers to the summary 'internal->cartesian' in the CCL archive. I have implemented a method to convert from internal coordinates to cartesian coordinates which has also been outlined by Heinz Schiffer, that is 1.) given a set of cartesian coordinates, I calculate a set of bond lengths, angles and dihedral angles and, as a byproduct a Wilson Matrix B containing the partial derivates d q_j/d x_i (q : internal coordinates, x: cartesian coordinates) is set up. 2.) A step is made: q_old -> q_new 3.) The inverse of B (B_inv) is used to calculate x_new-x_old = B_inv [x_old] *(q_new-q_old). 4.) Using x_new, step 1 is used to recalculate a set of internals q_test. If q_test=q_new, I am done. If not, the process is repeated , updating B_inv [x] until it reproduces the correct q_new. It works fine for bond lengths. Since B contains only unit vectors the process is *converged* in one step. If I am using steps in bond angles I am unable to get the difference between the actual angle update and the converged result below 5 percent. For realistic angle updates (such as ~10 degrees) it is around 10 percent. My understanding was, that the iterative process should take care of the fact that the steps are NOT infinitesimal thus converging to exactly the desired step. The code is so embarrasingly simple that I either made a very dumb mistake or (and this is my question) I do not understand this iterative process. Is it supposed to converge to exactly q_new or not? Thank you very much in advance, Folke Noertemann Lehrstuhl f. Theoret. Chemie Lichtenbergstr.4 85479 Garching noertema@theochem.tu-muenchen.de From jbrandao@ualg.pt Mon Jul 21 12:12:33 1997 Received: from mozart.si.ualg.pt for jbrandao@ualg.pt by www.ccl.net (8.8.3/950822.1) id LAA07075; Mon, 21 Jul 1997 11:49:41 -0400 (EDT) Received: by mozart.si.ualg.pt; id AA00256; Mon, 21 Jul 1997 16:50:43 GMT Received: by beethoven.si.ualg.pt with Internet Mail Service (5.0.1457.3) id <3XF24CTF>; Mon, 21 Jul 1997 17:01:26 +0100 Message-Id: <4E65BC611BDCD011858A0000F8631D383A22@beethoven.si.ualg.pt> From: Joao Brandao To: chemistry@www.ccl.net Subject: Help!! O atom (1D) energy Date: Mon, 21 Jul 1997 17:01:24 +0100 X-Priority: 3 Return-Receipt-To: Joao Brandao Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain > Dear CCl members, > > I have got a problem with the ab initio calculation of systems that > can dissociate to O atoms on a 1D excited state, like H2O. When the > two H atoms remain close enough, the gain in H2 singlet state > compensates de energy excitation of the O atom and this becomes the > dissociative channel. > I am using GAMESS with a moderately large basis set at the MCSCF/CI > level to compute some points in the H2O PES and I was looking for this > particular dissociation channel. > As a test I was looking for the O(1D)-O(3P) energy gap and > compare it to the experimental value of 1.96 eV (JANAF tables). > > For the O atom I am using the aug-cc-pCVQZ basis of Dunning, > which means 12s6p3d2f1g / > [5s4p3d2f1g]+3s3p2d1f(Tight)+1s1p1d1f1g(diffuse) functions. > > As a method of calculus I use a MR-CI calculation with a FORS > calculus on all 1s, 2s and 2p space of the O atom and a single and > double CI using all 3s 3p and 3d orbitals. > I have also done another, more accurate (I have got less > energy), calculation using a larger MCSCF space which includes 1s, 2s, > 2p, 3s, and 3p orbitals exciting 4 electrons. > > My problem is related to the definition of the reference > configuration for these states: > For O(3P) it seems clear to use 3 double occupied orbitals and > two single occupied orbitals with alpha electrons, keeping the > multiplicity as 3. > For O(1D) I have used as reference 4 double occupied orbitals. > BUT THIS SHOULD BE SIMILAR FOR THE O(1S) STATE. How can I distinguish > them? At fist time, I expected to compute different energies, The > first five should be the O(1D) and the sixth the O(1S). So I demanded > GAMESS to give me the 7 lower energy levels for this calculation. > > BUT... The results doesn't show any degeneracy. I couldn't find > any state 2.16 eV (the experimental difference between o(1S)-O(1D)) > above with the lower energy level. I have got some with energies > between those levels. > The computed difference between the O(1D) (taken as the lower > singlet level) and O(3P) states is greater than the experimental > value. I computed 2.154 eV and the difference becomes a little larger > with the more accurate MCSCF calculation. > > AM I DOING SOMETHING WRONG??? WHAT??? > > The difficult of getting an accurate value for this difference > is an old problem. Other published calculations overestimate this gap > but, to my knowledge, none of them take much care about it. > Am I getting a mixing of O(1D) and O(1S) states because the > GAMESS program is not designed for atoms? > > Any help grateful acknowledge. A summary of the answers will be > send to this list. > > Thanks for your attention, > > Joao Brandao > > --------------------------------------------------------------------- > Unidade de Ciencias Exactas e Humanas > Universidade do Algarve -Campus de Gambelas > P-8000 FARO > Portugal > e-mail: jbrandao@ualg.pt > Tel. 0351-89-800900 ext. 7628 > Fax. 0351-89-818560 > --------------------------------------------------------------------- > > > > > > > > From fgonzale@lauca.usach.cl Mon Jul 21 13:12:31 1997 Received: from ralun.usach.cl for fgonzale@lauca.usach.cl by www.ccl.net (8.8.3/950822.1) id MAA07325; Mon, 21 Jul 1997 12:36:23 -0400 (EDT) Received: from lauca.usach.cl (lauca.usach.cl [158.170.64.28]) by ralun.usach.cl (8.6.11/8.6.9) with ESMTP id MAA14322 for ; Mon, 21 Jul 1997 12:45:35 -0500 Received: (from fgonzale@localhost) by lauca.usach.cl (8.6.12/8.6.12) id MAA00300; Mon, 21 Jul 1997 12:39:59 -0400 Date: Mon, 21 Jul 1997 12:39:58 -0400 (CST) From: Fdo Danilo Gonzalez Nilo To: chemistry@www.ccl.net cc: mcaroli@lauca.usach.cl Subject: restart G94 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi all! We are working with the G94 program on PC 486 DX4 100MHz model, and calculations are normally rather slow. does anybody know how to save data in a long calculation, so that the process is not interrupted and the data lost if the computer is switched off before the final result is obtained? Thanks a lot! Fernando Danilo Gonzalez N. University of Santiago de Chile Faculty of Chemistry and Biology Casilla 40, Correo 33, Santiago, Chile fono: 681 2575 E-mail : fgonzale@lauca.usach.cl fax : (562) 681 2108 danilo@quimbio.usach.cl URL : http://quimbio.usach.cl/~danilo/ *************************************************************************x From che5jwc@titan.vcu.edu Mon Jul 21 14:12:32 1997 Received: from titan.vcu.edu for che5jwc@titan.vcu.edu by www.ccl.net (8.8.3/950822.1) id NAA07749; Mon, 21 Jul 1997 13:53:11 -0400 (EDT) Received: from [128.172.182.152] by titan.vcu.edu (AIX 4.1/UCB 5.64/4.03) id AA39752; Mon, 21 Jul 1997 13:50:22 -0400 Message-Id: <33D3A148.2B98@titan.vcu.edu> Date: Mon, 21 Jul 1997 13:50:00 -0400 From: John Cox Reply-To: che5jwc@titan.vcu.edu Organization: VCU X-Mailer: Mozilla 3.01Gold (Win95; I) Mime-Version: 1.0 To: chemistry@www.ccl.net Subject: Help! InsightII Counter Ions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I am working with oligonucleotides generated in the Biopolymer module by Insight and am wondering how to incorporate counter ions to balance the charge of the system to 0. The strands separate when optimized with Discover seemingly because of phosphate charge repulsions, and I think generic counter cations will correct this problem. Suggestions on how to generate/incorporate these charges will be greatly appreciated, thanks. Cheers, John Cox Graduate Student Dept. of Chemistry Virginia Commonwealth University Richmond, VA 804 828-0276 che5jwc@titan.vcu.edu From baker@terminator.chem.uiowa.edu Mon Jul 21 15:12:32 1997 Received: from ns-mx.uiowa.edu for baker@terminator.chem.uiowa.edu by www.ccl.net (8.8.3/950822.1) id OAA08251; Mon, 21 Jul 1997 14:51:43 -0400 (EDT) Received: from terminator.chem.uiowa.edu (terminator.chem.uiowa.edu [128.255.69.76]) by ns-mx.uiowa.edu (8.8.5/8.8.5) with SMTP id NAA47042 for <@ns-mx.uiowa.edu:chemistry@www.ccl.net>; Mon, 21 Jul 1997 13:51:45 -0500 Received: by terminator.chem.uiowa.edu (940816.SGI.8.6.9/940406.SGI) id NAA11364; Mon, 21 Jul 1997 13:52:47 -0700 Date: Mon, 21 Jul 1997 13:52:47 -0700 (PDT) From: "Nathan A. Baker" To: chemistry@www.ccl.net Subject: Gaussian 94 DFT & Opt Problems. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi -- I have encountered several strange errors in Gaussian 94 which I was wondering if anyone else may have encountered and perhaps fixed. First, when performing BPW91 DFT calculations, I often receive a "Spurious electron density" error which is not rectified by switching SCF methods. Often this happens in potential energy scans, where one structure will give an error while a closely related structure will converge without difficulty. Second, during geometry optimizations with frozen redundant internal coordinates, Gaussian will crash without *any* error message wahtsoever. I'm running the package on a Power Challenge system with a very large memory limit (.5 Gb) so, I'm fairly sure this crash is not due to memory limitations even thought I'm using a big (~20 atoms) molecule with lots of added, frozen internal coordinates. Finally, (this is moer of a question) why does Gaussian ignore the frozen redundant coordinates in the followin .COM file? : %chk=output.chk #BPW91/6-311+G(d,p) Opt=AddRedundant Test A Title 0 1 Cartesian Coordinates (also tried it with Z-matrix) 1 0 0.96 F It does not freeze the distance between atoms 1 and 0 at 0.96 A during the optimization. Thanks for your help! ----------------------------------------------- Nathan Baker * baker@terminator.chem.uiowa.edu Objects in Mir are closer than they appear. ----------------------------------------------- From hinsen@lmspc1.ibs.fr Sun Jul 20 09:12:17 1997 Received: from ibs.ibs.fr for hinsen@lmspc1.ibs.fr by www.ccl.net (8.8.3/950822.1) id IAA02792; Sun, 20 Jul 1997 08:22:27 -0400 (EDT) Received: from lmspc1.ibs.fr (hinsen@lmspc1.ibs.fr [192.134.36.141]) by ibs.ibs.fr (8.6.12/8.6.12) with ESMTP id OAA16498; Sun, 20 Jul 1997 14:23:37 +0200 Received: (from hinsen@localhost) by lmspc1.ibs.fr (8.8.5/8.8.5) id OAA20921; Sun, 20 Jul 1997 14:22:18 +0200 Date: Sun, 20 Jul 1997 14:22:18 +0200 Message-Id: <199707201222.OAA20921@lmspc1.ibs.fr> From: Konrad Hinsen To: chemistry@www.ccl.net Subject: Re: CCL:Object-oriented means for computational chemistry programming Coming back from the EBSA conference in Orleans, I found a few messages on this topic that I would like to comment on: -------------------------------------------------- Anthony J. Duben: > IMHO there is another alternative -- Ada. It is designed for writing solid > software engineering > applications, lacks the arcana of C/C++, and has versions available for > most systems. Ada has an impressive collection of arcana of its own; it might easily be the most complicated language in existence. However, it definitely has advantages as compared to C/C++, and I think it deserves a closer inspection for numerical applications (which to my knowledge barely exist in Ada). Personally, I just don't like it, and I don't like the idea of using a language that is so complicated that most programmers will never be able to learn all of it. -------------------------------------------------- Irene Newhouse: > There ARE reasons why FORTRAN is still used by scientists. Of course > there's the legacy code argument -- people who don't have time to reinvent > the wheel continue to use stable, well-developed subroutines for parts of > their code. Right. But you can continue to use all that legacy code while writing new stuff in another language - that's why I mentioned mixed-language programming. My Python code for linear algebra uses LAPACK, for example, but users don't see that directly. > 2nd, you cannot confuse aesthetic structure > with efficently executing code!!!! I work in a user services environment > where we help people optimize codes. Spaghetti code is ugly, but it > executes. Every subroutine call adds overhead, and we've seen some > gorgeous OOP stuff that runs like molasses in January, dragged down by all > the overhead... FORTRAN has a decades' long head start in compiler opt. This is a matter of using good compilers. Compiler technology has progressed tremendously, although numerical optimizations are often ignored except in the case of Fortran compilers. I am sure that we will see better compilers for other languages as soon as scientists and engineers begin to express a real interest in those languages to compiler writers. -------------------------------------------------- Gabriel Berriz: > The bottom line: no single language is perfect. I think scientists > should get used to the idea of mixed-language programming. > > This sounds great in theory, but I think it is hard to put into > practice. The reason is that, while anyone can easily find pretty > authoritative reference manuals on, say, ANSI C or Fortran90, it is > much harder to find good documentation for mixed-language programming. Right, but some particularly useful combinations are exceptions. The C/Fortran interface is handled rather nicely by the CFORTRAN package developed at DESY (ftp to zebra.desy.de). And modern high-level languages (such as Python) are written in C and therefore have a simple C interface. Together with CFORTRAN that allows using Fortran subroutines. C++ can interface to C in a standard way, and there is also a provision for linking with Fortran code, although I am not sure if it made it into the draft standard, or if it is implemented in real-life compilers. It certainly *could* be done if there were enough interest. Most other languages can somehow interface to C and from there elsewhere, but then it becomes compiler dependent. > (And coding with incomplete or inaccurate information will almost > certainly fail to yield faster programs.) Or have I just had bad Coding with incomplete information is standard practice! I wonder how many Fortran-loving scientists have read and understood the Fortran standard! It's at http://www.fortran.com/fortran/stds_docs.html. > Moreover, I suspect that to make the mixed-language idea pay-off, one > would really have to learn a great deal about the processor-dependent > nitty-gritty of numerical computation, information that is even more > difficult to come by even than that for mixed-language programming. Not at all, unless your goal is to optimize the use of various languages. > As things stand, computational chemists face the unpleasant choice > between writing relatively slow code in their favorite language, or > devoting a huge amount of time and effort to mastering the > computational arcana of the various, rapidly mutating platforms they > work with, material that is totally unrelated to their science. As There may be solutions. Just a crazy idea: create an institution devoted to "scientific computing" for the academic community. Staff it with application scientists and computer scientists, and let it work on a high-level language for scientific applications plus a set of standard libraries for common needs and simple interfacing to at least C, C++, and Fortran on all modern machines. The result should be usable by scientists who are not expert programmers, but expert programmers should participate in its design and implementation. The scientific Python community has essentially started in that direction, and what is there proves that it can be done. But as a purely volunteer effort it suffers from manpower restrictions. For example, work on a Fortran interface stopped when its author left academia for a "real" job. > likely 110%, as fast? Probably not. Ultimately, most folks are more > concerned with optimizing their time use than the computer's :-) . Exactly! But in my opinion, spending weeks analyzing and debugging ancient Fortran code is not an efficient way of using human time. For someone starting on a lifelong carreer in computational science, the time to learn programming properly is most certainly a good investment. -------------------------------------------------- Gerald Loeffler: > Thats > Scientific and Engineering C++ : An Introduction With Advanced > Techniques and Examples > by John J. Barton, Lee R. Nackman > Hardcover, 671 pages > Published by Addison-Wesley Pub Co > Publication date: July 1, 1994 > > This on the other hand is a very thoroughly written text on C++ as it > will more or less emerge from the standardization effort (note: there is > no ANSI C++ standard yet!). A very good recommendation for any C++ programmer working on scientific applications. However, if you want to *learn* C++ from it, you should be well motivated, otherwise you might easily be discouraged. My recommendation: get this one plus a "standard" C++ introduction and use them in parallel. -------------------------------------------------- A J Turner: > There seems to be one points that no-one has covered, especially when we > say FORTRAN has run its coarse. If I am to spend a long time writing a > piece of code to perform a very complex task - I need to be 100% sure > that the code will be in a lagnuage that can be used in the future. There > is only one language that can really offer that - FORTRAN. There are a number of languages that are sufficiently established to be around with near certainty for a long time. In addition to Fortran, that's C, C++, and COBOL. Probably also Ada, if only due to the support of the US DOD. As for interpreted languages like Python, most of them are implemented in C, and as long as the source code is open (which is true at least for Python, Perl, and Tcl), no one prevents you from keeping a personal copy for an indefinite future. As a somewhat philosophical note on this topic, let me say that in my opinion the long-time value of code is often grossly overestimated. What matters is algorithms, not code. Reimplementing a known and working algorithm is routine work that takes less and less time as programming tools improve. In fact, I'd like to propose an alternative model for developing scientific code: define a "lifetime" of between five and ten years for each package (depending on the speed of method development) and throw it away after that time, replacing it with new code containing the useful part of the functionality and written according to the state of the art of programming. Such an approach might well be more globally efficient than the current "keep-it-alive-as-long-as-possible" method. -------------------------------------------------- David E. Bernholdt: > It idea of mixed language programming is to use languages most > appropriate for the task at hand, not just for speed, but for ease of > implementation. Such decisions are usually fairly coarse-grained. Exactly! > > Ultimately, most folks are more concerned with optimizing their time > > use than the computer's :-) . > > In my opinion, this is the reason _to_ use mixed language > programming. If I wanted to write a robust input parser for a large I couldn't agree more! > One can DESIGN software based on these principles (OOD) regardless of > what language the software is to be implemented in. Right. But implementing an OO design in a non-OO language requires a lot of experience and discipline - to be expected of a professional programmer, but not of a programming scientist. Of course the more basic problem is that scientists tend to skip the design phase altogether. Which is why big projects ought to be started in collaboration with software engineering experts. > I disagree with the person who proposed C++ is "the" langauge for > future work because it is an OOL. There are a lot of other > considerations that (should) factor into the decision of which > language to use. However I think that ALL projects should consider > object-oriented DESIGN regardless of implementation language. Again I agree completely. -------------------------------------------------- Lestaw K. Bieniasz: > If you need a program for individual purpose, use Fortran if you like it. Of course. However, don't do one of the following: 1) Force your students and postdocs to use Fortran even if they know and prefer something else. 2) Teach your students nothing but Fortran. Unfortunately, both are standard practice today. -------------------------------------------------- OK, that's it, sorry for the long post, and back to work... -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28 Institut de Biologie Structurale | Fax: +33-4.76.88.54.94 41, av. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- From berriz@chasma.harvard.edu Mon Jul 21 22:12:35 1997 Received: from chasma.harvard.edu for berriz@chasma.harvard.edu by www.ccl.net (8.8.3/950822.1) id VAA10282; Mon, 21 Jul 1997 21:37:29 -0400 (EDT) Received: by chasma.harvard.edu (AIX 3.2/UCB 5.64/4.03) id AA23901; Mon, 21 Jul 1997 21:38:07 -0400 Date: Mon, 21 Jul 1997 21:38:07 -0400 From: berriz@chasma.harvard.edu (Gabriel Berriz) Message-Id: <9707220138.AA23901@chasma.harvard.edu> To: chemistry@www.ccl.net In-Reply-To: <199707201222.OAA20921@lmspc1.ibs.fr> (message from Konrad Hinsen on Sun, 20 Jul 1997 14:22:18 +0200) Subject: Fortran for C Programmers? (Was: Object-oriented means for computational chemistry programming) While we're on the subject of mixed-language programming, does anyone know of a book (or any other reference) on Fortran for C programmers? I have read introductory material on Fortran, and written *teeny* throaway programs, but I still don't have a very good grasp of the structure of Fortran programs. The examples of Fortran code I've seen look like *nothing* else in my experience (mostly C, Perl, and Python); I'm not sure what's the point of doing things that way. Hence, any material on the general structure of Fortran programs (especially Fortran90), and how it contrasts with the "C paradigm" would be extremely helpful. (Unfortunately, there seems to be more demand and supply for guides to C for Fortran programmers than the other way around... :/ ) Thanks in advance for your suggestions, Gabriel Berriz berriz@chasma.harvard.edu