From chemistry-request@server.ccl.net Mon Dec 6 18:44:15 1999 Received: from schrodinger.com (root@thermidore.schrodinger.com [192.156.98.99]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id SAA21077 for ; Mon, 6 Dec 1999 18:44:15 -0500 Received: from jane.schrodinger.com (jkp@jane.schrodinger.com [192.156.98.21]) by schrodinger.com (8.8.5/8.8.5) with ESMTP id OAA24087 for ; Mon, 6 Dec 1999 14:35:47 -0800 From: "Jason K. Perry" Received: (from jkp@localhost) by jane.schrodinger.com (8.8.5/8.8.5) id OAA29508 for chemistry@ccl.net; Mon, 6 Dec 1999 14:35:48 -0800 Date: Mon, 6 Dec 1999 14:35:48 -0800 Message-Id: <199912062235.OAA29508@jane.schrodinger.com> To: chemistry@ccl.net Subject: Re: RO jobs on unsaturated organometallics Dear Eric, I just wanted to follow-up on the useful suggestions of Dale Braden and Rick Muller on how to deal with converging your DFT with Jaguar. Dale's suggestion to send the case to help@schrodinger.com is best. We're very interested in looking at all cases that appear problematic - it is a top priority at Schrodinger to ensure our software products are performing properly for our users. In most instances, a simple solution can be found (as I'll detail below). As for cases that may be more difficult, we use those as a guide for improving robustness of the code. It might be the case that your calculation converges smoothly in Jaguar v4.0 (now in beta release). The manual offers some suggestions on improving convergence of difficult cases (section 6.3). Generally we suggest: 1) Try setting vshift. This increases the energy of the virtual orbitals such that they mix with the occupied orbitals more slowly. This stabilizes oscillatory convergence. Usually it's sufficient to set vshift to 0.5-1.0 (hartree), but there have been a couple rare cases where vshift=2.0 appeared necessary. We offer a variable vshift in Jaguar v4.0. It's more conservative in the early iterations, reducing the size of vshift as convergence is approached. 2) Try changing the accuracy settings. The default accuracy in Jaguar is quick. Setting the accuracy to ultrafine (iacc=1) improves convergence in some cases. That doesn't appear to be the problem here, though. 3) Try changing the convergence scheme. The default is DIIS (iconv=1). A more conservative scheme is GVB-DIIS (iconv=4). 4) Try changing the initial guess. If you can converge the HF/LACVP wavefunction, that would probably be your best initial guess for the B3LYP/LACVP** calculation. We've modified the default initial guess for organometallics in Jaguar v4.0. You can get this functionality in v3.5 using iguess=25 and an &atomic section, as explained in the manual. I encourage you to try the above options, but please don't hesitate to send your input files to help@schrodinger.com, so that we could examine them ourselves and provide more specific suggestions. Hope this helps, Jason Perry Schrodinger, Inc. http://www.schrodinger.com > Greetings, > > I'm having great difficulty getting convergence for my > restricted open-shell DFT jobs on coordinatively unsaturated > iron compounds. I'm using Jaguar for these (rob3lyp/lacvp**), > and I've used G94/98 in the past, so suggestions pertaining to > either package would help. In Jaguar I've used vshifts of 0.2 - > 1.0; accuracy settings (iacc) of quick, medium, and ultrafine; > As per hints in the manual I tried iacc=1 (ultrafine grids) with > the lac3vp** basis (largest available) and etot simply > oscillated. > > If anyone has successfully dealt with a similar situation with > either Jaguar or G98, I'd love to start a little dialog. > If/when I meet with success I'll edit down any conversations to > the pertinent points and repost them. > > Thanks in advance, > Eric Ball > > > > > > __________________________________________________ > Do You Yahoo!? > Thousands of Stores. Millions of Products. All in one place. > Yahoo! Shopping: http://shopping.yahoo.com > From chemistry-request@server.ccl.net Mon Dec 6 19:39:55 1999 Received: from sunflare.ccs.yorku.ca (sunflare.ccs.yorku.ca [130.63.236.128]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id TAA21282 for ; Mon, 6 Dec 1999 19:39:55 -0500 Received: from curl.gkcl.yorku.ca (curl.gkcl.yorku.ca [130.63.232.224]) by sunflare.ccs.yorku.ca (8.9.3/8.9.3) with SMTP id SAA06107 for <@mailrelay.yorku.ca:chemistry@ccl.net>; Mon, 6 Dec 1999 18:31:27 -0500 (EST) Received: by curl.gkcl.yorku.ca (940816.SGI.8.6.9/940406.SGI) for chemistry@ccl.net id SAA06028; Mon, 6 Dec 1999 18:36:30 -0500 From: chan@curl.gkcl.yorku.ca (Wai-To-Chan) Message-Id: <199912062336.SAA06028@curl.gkcl.yorku.ca> Subject: RO jobs on unsaturated organometallics To: chemistry@ccl.net Date: Mon, 6 Dec 1999 18:36:30 -0500 (EST) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Since you used vshift I presume your structure has a very small HOMO-LUMO gap? I've encountered convergence difficulties in metal-cluster complexes caused by narrowly-spaced lowlying virtual orbitals using the UHF-based DFT code in g98. In such cases VSHIFT didn't help me. I found increasing the 'weight' of HF exchange in the DFT hybrid functional or simply using HF-SCF more likely to get the SCF MO converged. What I ended up doing was to start with DFT-BHandHLYP to obtain a set of converged MOs first (in the right electronic state of course). I then uses the MO as initial guess for my subsequent B3LYP, B3P86 or B3PW91 calculation which otherwise failed to converge. Note that my suggestion does NOT imply recommendation of using BHandHLYP for organometalic system. Good luck. Wai-To Chan From chemistry-request@server.ccl.net Mon Dec 6 20:49:44 1999 Received: from lrz.uni-muenchen.de (lsajca1-ar3-012-122.biz.dsl.gtei.net [4.3.12.122]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id UAA21530 for ; Mon, 6 Dec 1999 20:49:42 -0500 Received: (from eugene.leitl@localhost) by lrz.uni-muenchen.de (8.8.8/8.8.8) id RAA24952; Mon, 6 Dec 1999 17:37:35 -0800 From: Eugene Leitl MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14412.25820.850556.601558@lrz.uni-muenchen.de> Date: Mon, 6 Dec 1999 17:37:32 -0800 (PST) Subject: Simulating Chemistry: Q&A with John Pople X-Mailer: VM 6.71 under 21.1 (patch 4) "Arches" XEmacs Lucid http://www.rdmag.com/features/0699rd/06pople.htm Simulating Chemistry As computers speed up, computational chemistry will become even more useful, allowing scientists to accomplish much more in less time. Q&A with John Pople, 1998 Nobel Laureate in chemistry Computational methods are gradually evolving, bringing new, easier-to-use, and more sophisticated programs to researchers, says John Pople, a Nobel Prize-winning professor of chemistry at Northwestern Univ., Evanston, Ill. These technological changes will continue in the next century, making chemical theory accessible to more scientists and engineers. He predicts that computational methods will become more available to experimental scientists, who will rely on increasingly sophisticated software packages. With these, they will be able to predict the structures and spectroscopic properties of molecules they can't make, identify unknown compounds, and study unstable molecules and reaction intermediates. In an exclusive interview, Pople outlined his views on the future of computational chemistry and its applications. R&D: What do you think are some of the most significant changes in computational chemistry in the last ten years? Pople: The techniques used to predict the properties of molecules require sufficient accuracy to reproduce the results of an experiment. This has only become possible as computers have become more powerful. At the same time, the corresponding algorithms and mathematical methods have developed. R&D: What kinds of improvements do you expect as computer technology gets better? Pople: There's a continual search for improved approximation methods, and there's a continual search to use existing approximations more efficiently, with fewer mathematical steps. It's interesting how science has moved from a university environment out to the commercial area through the software companies that now sell the quantum-chemistry programs. As a matter of fact, four such companies are derivatives from my research group. R&D: Do you think that the changes in computational chemistry will affect how experimentalists work? Pople: The chemical community will be more educated as to what can be done. The methods will become easier to use. They are analogous to instrumental methods, like looking at the vibrational spectrum of a molecule or its magentic-resonance spectrum. These are techniques that chemists learned to use. They will be able to use a theoretical quantum-chemistry computer program to learn the properties of a molecule in the same way. It's now common for an experimentalist to investigate his problem with a computational method-perhaps before he does the experiment-to get an indication of what the results might be. Whether a bond will be a strong one or a weak one, whether a reaction will proceed easily or with difficulty-these things can be studied by theory before the experiment is attempted. This sort of approach is used, for example, by drug companies that look at some theoretical studies of a potential drug molecule before going to the trouble of synthesizing it and testing it in practice. R&D: What do you think are some of the more important experimental applications besides drug research? Pople: Computational chemistry is used for studying the mechanisms of reactions, for example, in atmospheric physics. There are processes that can go on with pollutants in the atmosphere, reactions that they may undertake, and these can be studied by theory. Another application is in space. People study molecules in interstellar space that may exist for extended periods but can't be synthesized on the earth. R&D: They just aren't stable with other species around? Pople: That's right. You may have a molecule in interstellar space that doesn't undergo a collision with anything else or react with anything for long periods, because there's nothing there. This may be a molecule that you couldn't study in a terrestrial laboratory. People hypothesize that such a molecule may exist, then predict its structure and vibrational frequencies. Then you can go and look for it using that knowledge to help you. I mentioned before that you could study possible reactions. When one molecule undergoes a reaction, and forms some new molecules, it's often important to know if there's an intermediate or some catalyst that's affecting the rate of the reaction. You can explore that by theoretical methods, to see whether you have a reasonable hypothesis. R&D: How would you go about doing something like that? Pople: You test out your suggestions. You may think that a certain species takes part in the reaction, not directly but as a spectator. It's just present and interacts with the molecules undergoing the reaction. You can test them out by studying the complex of the reacting molecules and the possible spectator to see whether the spectator would affect the rate of reaction. All that can be studied by theory. R&D: Do you think they could use theoretical programs to identify unknowns? Pople: If you have a spectrum and don't know what the molecule is, but have a suspicion, you could work out the spectroscopy theoretically and then compare that with the spectrum that you see. That may help you identify the molecule. That's an important area of application. R&D: Do you think that there will be changes that will affect applied R&D? Pople: In so far as such applications are determined by underlying chemical processes, an understanding of chemical processes is important to the development. The whole area of combustion, in which there are many intermediate short-lived species, can be affected by studies of such intermediates-how stable they are, what their nature might be. R&D: Do you think that advances in computer technology or improvements in computational methods are required to do calculations on bigger molecules? Pople: The two go together-the methods and the algorithms as well as the computer technology. R&D: Can you describe some of approximations that people are trying to do? Pople: Some methods require integration of a wave function or wave functions over space, and you have to do this by forming a mathematical grid-a large grid of points in space. And one question is what's the most effective grid to use. A large grid will make it accurate, but, on the other hand, you don't want to make it too large so that the calculations don't get out of hand. You have to decide on the best compromise between accuracy and efficiency. R&D: How do you compromise on something like that? Pople: There are other factors, like where you put the grid points. What part of the molecule do you put most of them in to be most effective? Do you need many grid points far away from the center of the molecule? How does the density of the grid points affect the accuracy of your answer? All these are theoretical questions that you would have to study. Carrying out a computation is another challenge. Even after you've designed the computation, you may modify the computer algorithm to get the same answer using fewer multiplications, for example by changing the loop structure of the program. Modern techniques in computer science are quite important in making computations effective. R&D: Do you think that computer companies will design CPU chips for specific purposes like quantum chemistry? Pople: That does not seem to be the way to go. That has been suggested many times, and some people have actually experimented with special chips. However, it's usually found that you can do better with a general-purpose chip that will do additions and multiplications and move things about from one location to another. It's generally better to use what extra power you have, rather than to design specialist chips. R&D: So you don't think that's going to be a trend. Pople: It hasn't proved so up till now, although it may be. Some computers have chips designed to do square roots, for example. I don't know to what extent that's true at the present time, but certainly they have been designed to do that. A special circuit put on a chip to do a square root-that's the kind of thing that [computer engineers] would work on. That doesn't really affect the way I do things, or at least I'm not conscious of it. You just call for a square root and you don't know how it handles it inside the processor. Another thing is that computers can do several calculations at once. This happens in parallel computers. You have many processors all doing multiplications simultaneously. That can be used to make computations more effective-to get a bigger computation done in a given amount of time. If you have many processors going in parallel, the calculation has to be such that you don't need the results from one to do the computation in the next one. Avoiding that kind of conflict would be another important feature of computer programming. R&D: Do you think there will continue to be problems that experimental chemists won't be able to solve, where they will call in a computational specialist? Pople: Probably so. They must be educated as to the limitations of the programs. Sometimes they need to be educated as to the meanings of the answers. It may be that only a professional person would understand or recognize that answers might be unreliable. So there's a market for that. R&D: Now that experimentalists can do more things themselves with prepackaged software, how do you think what computational chemists do will change? Pople: There are continual developments. And the program packages that are available commercially will improve. Computational chemists will be working on the next versions, as they get better all the time. From chemistry-request@server.ccl.net Mon Dec 6 21:51:42 1999 Received: from lrz.uni-muenchen.de (lsajca1-ar3-012-122.biz.dsl.gtei.net [4.3.12.122]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id VAA21745 for ; Mon, 6 Dec 1999 21:51:41 -0500 Received: (from eugene.leitl@localhost) by lrz.uni-muenchen.de (8.8.8/8.8.8) id SAA25373; Mon, 6 Dec 1999 18:39:33 -0800 Resent-From: Eugene Leitl Resent-Message-ID: <14412.29541.164178.153223@lrz.uni-muenchen.de> Resent-Date: Mon, 6 Dec 1999 18:39:33 -0800 (PST) Resent-To: , , Message-Id: <19991xxx2070133.RAA08473@dodo.prod.itd.earthlink.net> Organization: Science-Week X-Distribution: Moderate Reply-to: prismx@scienceweek.com Priority: normal X-mailer: Pegasus Mail for Win32 (v3.01d) From: To: prismx@scienceweek.com Subject: ScienceWeek - Free Student Subscriptions Date: Mon, 6 Dec 1999 19:28:36 -0600 From: "Science-Week" PLEASE POST ----------- FYI: ScienceWeek, the award-winning weekly online research news digest, is offering a limited number of free subscriptions to science students worldwide. The term "student" includes both undergraduate and graduate students. The level of SW is probably too high for high school science students, but such students are welcome. This offer of a free 26-issue subscription is good only until January 1, 2000. Subscriptions will extend through June 2000. To obtain your free subscription, send your request by Email to: request@scienceweek.com Please indicate your full name and your educational institution. Subscriptions will be entered on a first-come first-served basis until the indicated quota is filled. ScienceWeek is transmitted via Email each week, total content approximately 70K bytes ASCII. Claire Haller Managing Editor ScienceWeek haller@scienceweek.com http://www.scienceweek.com From chemistry-request@server.ccl.net Mon Dec 6 23:37:50 1999 Received: from teapot23.domain2.bigpond.com (teapot23.domain2.bigpond.com [139.134.5.165]) by server.ccl.net (8.8.7/8.8.7) with SMTP id XAA22149 for ; Mon, 6 Dec 1999 23:37:49 -0500 Received: from localhost (localhost [127.0.0.1]) by teapot23.domain2.bigpond.com (NTMail 3.02.13) with ESMTP id pa077573 for ; Tue, 7 Dec 1999 13:28:25 +1000 Received: from BDIP-T-009-p-235-240.tmns.net.au ([139.134.235.240]) by mail2.bigpond.com (Claudes-Critical-MailRouter V2.6h 3/261261); 07 Dec 1999 13:28:24 Message-ID: <002801bf4063$7921c720$108b67cc@hnlsyd8> Reply-To: "Dr Huang" From: "Dr Huang" To: Cc: Subject: I had uploaded my new version polar4.zip to ccl.net Date: Tue, 7 Dec 1999 14:30:55 +1100 Polar 4 for Windows: Electrochemical simulation and data analysis [IN CCL: http://www.ccl.net/cca/software/MS-WIN95-NT/Polarograms ] DrHuang Pty Ltd 124 Eastern Avenue, Kingsford, Sydney, NSW 2032, Australia Phone: 61 2 96620516, 0413 008 019 mailto:polarography@bigFoot.com, showing@bigFoot.com www.electrochem.net www.DrHuang.net www.electroanal.com It analytically and digitally simulates voltammograms (polarograms) at 8 electrode geometries (planar, spherical, semi- spherical, cylindrical, semi-cylindrical, microdisc, thin film, and rotating electrodes) in over 5 techniques (linear sweep and CV, DC, normal pulse, differential pulse, and square wave voltammetries). It outputs current, resistance, conductivity and surface concentration. It also simulates effects of charge current, resistance, noise, electrolyte, stripping time, stripping potential, etc. User can type in his mechanism. It analyses any ASCII x-y data for detecting peak location, peak value, semi-derivative, derivative, intergral, semi-intergral, curve fitting, and separating overlapped peaks. It shows a tip when the user put mouse cursor over a lable. It can separate overlapped voltammograms into individuals, and extract real peaks >from voltammogram with noise and baseline. Users can compare by the theoretical peak values, analytically and digitally simulation, and choose to extract which kinetic pararmeters. Its data can be imported into other program (e.g. MS Excel). It has been successfully applied to fit experimental polarograms (voltammograms) of In(III), Cd(II), Pb(II), Tl(I), Cr(III). Zn(II), and binuclear copper complex in aqueous and non-aqueous media at mercury, solid metal and non-metal electrodes (specifically the dropping mercury, hanging mercury drop, gold, platinum and glassy carbon electrodes) by various electrochemical techniques (differential pulse, square wave, and pseudo-derivative normal pulse polarographies). It is available from the author or download from my Web site. From chemistry-request@server.ccl.net Tue Dec 7 00:37:07 1999 Received: from schrodinger.com (root@thermidore.schrodinger.com [192.156.98.99]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id AAA22364 for ; Tue, 7 Dec 1999 00:37:06 -0500 Received: from ithi.schrodinger.com (vacek@ithi.schrodinger.com [192.156.98.12]) by schrodinger.com (8.8.5/8.8.5) with ESMTP id UAA00770; Mon, 6 Dec 1999 20:28:34 -0800 From: George Vacek Received: (from vacek@localhost) by ithi.schrodinger.com (8.8.5/8.8.5) id UAA15011; Mon, 6 Dec 1999 20:29:41 -0800 Message-Id: <199912070429.UAA15011@ithi.schrodinger.com> Subject: Re: CCL:RO jobs on unsaturated organometallics To: rpm@wag.caltech.edu (Richard P. Muller) Date: Mon, 6 Dec 1999 20:29:40 -0800 (PST) Cc: esbchem@yahoo.com, chemistry@ccl.net In-Reply-To: <384BE93E.F19494F5@wag.caltech.edu> from "Richard P. Muller" at Dec 6, 99 08:50:06 am X-Mailer: ELM [version 2.4 PL23beta2] Content-Type: text %% "Eric S. Ball" wrote: %% > I'm having great difficulty getting convergence for my %% > restricted open-shell DFT jobs on coordinatively unsaturated %% > iron compounds. I'm using Jaguar for these (rob3lyp/lacvp**), %% > and I've used G94/98 in the past, so suggestions pertaining to %% > either package would help. In Jaguar I've used vshifts of 0.2 - %% > 1.0; accuracy settings (iacc) of quick, medium, and ultrafine; %% > As per hints in the manual I tried iacc=1 (ultrafine grids) with %% > the lac3vp** basis (largest available) and etot simply oscillated. %% Richard P. Muller wrote: %% I can't speak for Gaussian, but this is a well-known problem in Jaguar %% for DFT with transition metals. Schrodinger is working on a solution, %% and I sent them some of our group's most catastrophic convergence cases %% to test it on. Convergence difficulty for transition metal containing systems is a well know issue which affects all QM packages. As Rick says, here at Schrodinger we've been working to fix that problem. For metal clusters, we're getting close to a great solution, thanks in part to Rick's catastrophes. And for organometallics, we've already pretty much nailed the solution, which you have access to if you are using Jaguar 3.5. I'll give more on it below. As Dale Braden pointed out the best thing to do is email your Jaguar input files to help@schrodinger.com. Then we'll be able to give you more specific advice for your exact system. Short of that, here is some general advice, much of which is applicable to any QM package. Even without the complications of transition-metals in the system, both the numerical accuracy of DFT and additional basis functions can make SCF convergence more difficult. Dale touched on the basis set issue and Rick on the DFT one, so I won't go into the nitty gritty, but you should try to first converge the SCF wavefunction with HF LACVP. When that wavefunction converges, you can use the wavefunction in the restart file as a starting guess for a HF LACVP** calculation. When that converges, restart for DFT LACVP**. This step-by-step process is much more likely to succeed. It also makes it easier to see which aspect of the calculation (orbital occupations vs. DFT grids vs. basis set) is causing the convergence difficulties, which in turn makes it easier to decide which added flags are expected to help the most: choosing a different convergence scheme, virtual orbital level shifting, or finer DFT grids. For Jaguar, the use of and flags for choosing convergence schemes, virtual shifting, and DFT grids are described in the manual, especially on pp. 124-6. I think you are already familiar with some of the flags, and Dale and Rick have mentioned some others. Finally, as I mentioned above, Jaguar also provides another unique feature to improve SCF convergence (both HF and DFT) for some TM systems. We realized that most poor convergence of these systems was due to a really poor initial guess wavefunction (both orbital shapes and occupations). So we developed an algorithm based upon ligand-field theory that creates a high-quality initial guess specifically designed for organometallic systems. The success rate of this initial guess is phenomenal compared with the Huckel guess, that is used in Gaussian, for instance. Use of this feature in Jaguar 3.5 is also described on pp.124-6 of the User's Manual. The method and some results are published in: G. Vacek, J.K. Perry and J.-M. Lanlois, Chem. Phys. Lett., 310 (1999) pp. 189-94. Regards, George =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= George Vacek + Schrodinger, Inc. (503) 299-1150 + 1500 SW First, Suite 1180 vacek@schrodinger.com + Portland, OR 97201 http://www.schrodinger.com/~vacek/ As the critic gained ascendancy in theatre and concert, the journalist in the schoolroom, and the newspaper in society, art degenerated into the lowest kind of amusement and esthetic criticism into the cement of a social group that was vain, distracted, egotistic, and totally unoriginal -- Friedrich Nietzsche "The Birth of Tragedy" 1872 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From chemistry-request@server.ccl.net Tue Dec 7 13:15:25 1999 Received: from darwin.rca.ac.uk (darwin.rca.ac.uk [194.80.196.2]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id NAA26750 for ; Tue, 7 Dec 1999 13:15:24 -0500 Received: from film-08.comms.rca.ac.uk (banana) [194.80.198.10] by mail.rca.ac.uk with esmtp id 11vO4a-0000Sy-00; Tue, 7 Dec 1999 17:06:44 +0000 Message-Id: <4.2.0.58.19991207170130.00989d00@icex5.cc.ic.ac.uk> X-Sender: ic\seth/s.hogg@icex5.cc.ic.ac.uk X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 07 Dec 1999 17:06:47 +0000 To: chemistry@ccl.net From: Simon Hogg Subject: Rendering molecules Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I am making a movie of an MD time step by the following method; run dynamic trajectory in Tinker --> output 1000 xyz (tinker) files run xyzpdb as a batch job to convert xyz --> output 1000 pdb files Then I was going to use either molpov or povchem to convert to pov scenes, then render them overnight, but I just found out that those two packages don't do batch jobs (at least as far as I can see) so I went hunting for pdb2pov, but that doesn't like my pdb files (one is attached below - it should be glycerol). The message it returns is 'no atoms'. Can anyone help with either recommending a batch converter or another *freeware* program? HEADER Default title for: Tinker COMPND SOURCE HETATM 1 C 1 1 -0.058 -1.170 -0.063 HETATM 2 C 1 1 -0.158 0.374 -0.320 HETATM 3 C 1 1 -1.608 0.713 -0.401 HETATM 4 O 6 1 0.593 0.984 0.672 HETATM 5 H 5 1 0.920 -1.619 -0.291 HETATM 6 H 5 1 -0.307 -1.376 1.005 HETATM 7 H 5 1 -0.747 -1.601 -0.738 HETATM 8 H 5 1 0.272 0.698 -1.301 HETATM 9 H 5 1 -1.722 1.828 -0.380 HETATM 10 H 5 1 -2.293 0.456 -1.275 HETATM 11 H 5 1 -2.143 0.238 0.509 HETATM 12 H 21 1 0.073 1.554 1.149 CONECT 1 2 5 6 7 CONECT 2 1 3 4 8 CONECT 3 2 9 10 11 CONECT 4 2 12 CONECT 5 1 CONECT 6 1 CONECT 7 1 CONECT 8 2 CONECT 9 3 CONECT 10 3 CONECT 11 3 CONECT 12 4 END From chemistry-request@server.ccl.net Tue Dec 7 15:51:28 1999 Received: from deimos.cber.nih.gov (deimos.cber.nih.gov [128.231.52.2]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id PAA27757 for ; Tue, 7 Dec 1999 15:51:28 -0500 Received: from localhost by deimos.cber.nih.gov with SMTP (1.37.109.14/16.2) id AA203475467; Tue, 7 Dec 1999 14:37:47 -0500 Date: Tue, 7 Dec 1999 14:37:47 -0500 (EST) From: Rick Venable To: Simon Hogg Cc: chemistry@ccl.net Subject: Re: CCL:Rendering molecules In-Reply-To: <4.2.0.58.19991207170130.00989d00@icex5.cc.ic.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I found that pdb2pov doesn't recognize HETATM records; change them to ATOM records and it should work okay. You can automate the change via awk or sed. I also found that pdb2pov creates a large POV union object for the whole molecule; povray3 will render the scene a lot faster if you remove the union. I've hacked pdb2pov to make a version that creates .pov files more suited to povray3. Again, this change to the .pov file could also be automated via sed or awk. On Tue, 7 Dec 1999, Simon Hogg wrote: > I am making a movie of an MD time step by the following method; > > run dynamic trajectory in Tinker --> output 1000 xyz (tinker) files > run xyzpdb as a batch job to convert xyz --> output 1000 pdb files > > Then I was going to use either molpov or povchem to convert to pov scenes, > then render them overnight, but I just found out that those two packages > don't do batch jobs (at least as far as I can see) so I went hunting for > pdb2pov, but that doesn't like my pdb files (one is attached below - it > should be glycerol). The message it returns is 'no atoms'. Can anyone > help with either recommending a batch converter or another *freeware* program? > > HEADER Default title for: Tinker > COMPND > SOURCE > HETATM 1 C 1 1 -0.058 -1.170 -0.063 > HETATM 2 C 1 1 -0.158 0.374 -0.320 > HETATM 3 C 1 1 -1.608 0.713 -0.401 > HETATM 4 O 6 1 0.593 0.984 0.672 > HETATM 5 H 5 1 0.920 -1.619 -0.291 > HETATM 6 H 5 1 -0.307 -1.376 1.005 > HETATM 7 H 5 1 -0.747 -1.601 -0.738 > HETATM 8 H 5 1 0.272 0.698 -1.301 > HETATM 9 H 5 1 -1.722 1.828 -0.380 > HETATM 10 H 5 1 -2.293 0.456 -1.275 > HETATM 11 H 5 1 -2.143 0.238 0.509 > HETATM 12 H 21 1 0.073 1.554 1.149 > CONECT 1 2 5 6 7 > CONECT 2 1 3 4 8 > CONECT 3 2 9 10 11 > CONECT 4 2 12 > CONECT 5 1 > CONECT 6 1 > CONECT 7 1 > CONECT 8 2 > CONECT 9 3 > CONECT 10 3 > CONECT 11 3 > CONECT 12 4 > END > > > -= This is automatically added to each message by mailing script =- > CHEMISTRY@ccl.net -- To Everybody | CHEMISTRY-REQUEST@ccl.net -- To Admins > MAILSERV@ccl.net -- HELP CHEMISTRY or HELP SEARCH > CHEMISTRY-SEARCH@ccl.net -- archive search | Gopher: gopher.ccl.net 70 > Ftp: ftp.ccl.net | WWW: http://www.ccl.net/chemistry/ | Jan: jkl@ccl.net > > > > > > Rick Venable =====\ |=| "Eschew Obfuscation" FDA/CBER Biophysics Lab |____/ |=| Bethesda, MD U.S.A. | \ / |=| ( Not an official statement or Rick_Venable@nih.gov | \ / |=| position of the FDA; for that, http://www.erols.com/rvenable \/ |=| see http://www.fda.gov ) From chemistry-request@server.ccl.net Tue Dec 7 15:37:21 1999 Received: from lion.studentergaarden.dk ([130.226.169.130]) by server.ccl.net (8.8.7/8.8.7) with SMTP id PAA27640 for ; Tue, 7 Dec 1999 15:37:20 -0500 Received: (qmail 32418 invoked from network); 7 Dec 1999 19:29:39 -0000 Received: from unknown (HELO studentergaarden.dk) (172.16.15.92) by nero.studentergaarden.dk with SMTP; 7 Dec 1999 19:29:39 -0000 Message-ID: <384D5EFA.61B31B22@studentergaarden.dk> Date: Tue, 07 Dec 1999 20:24:42 +0100 From: Kasper Planeta Jensen To: chemistry@ccl.net Subject: [Fwd: CCL:Checkcoordinates] Hi all If it is to any interest, I have recieved this answer from GAUSSIAN customer service regarding the CheckCoordinates keyword in G98. I hope the next version will improve on this point. Love, Kasper > From: gaussian.com!csd@gaussian.com (Cust. Service Doug) > Subject: Re: CCL:Checkcoordinates > To: uunet!studentergaarden.dk!kpj%gaussian.com@uunet.uu.net (Kasper Planeta Jensen) > Date: Mon, 6 Dec 1999 19:12:25 -0500 (EST) > Reply-To: gaussian.com!help%gaussian.com@gaussian.com > > > This option has prven to be more difficult to implement than expected > and has been deferred to a future revision. > > > > > Hi, > > > > I am currently having some problems with the > > OPT(modred,CheckCoordinates) > > option in G98. I use both Geom(modredundant,connect) and > > Opt(modredundant) but > > the CheckCoordinates keyword, which ought to rebuild the connectivity > > matrix upon > > each optimisation step, does not seem to work. Does anybody know why? > > > > Love, > > Kasper > > > -- > > Douglas J. Fox > Technical Support > Gaussian, Inc. > help@gaussian.com > From chemistry-request@server.ccl.net Tue Dec 7 17:06:21 1999 Received: from theopzs.chem.elte.hu (seky@theopzs.chem.elte.hu [157.181.193.147]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id RAA28859 for ; Tue, 7 Dec 1999 17:06:20 -0500 Received: from localhost (seky@localhost) by theopzs.chem.elte.hu (8.9.3/8.8.7) with ESMTP id VAA15839; Tue, 7 Dec 1999 21:59:39 +0100 Date: Tue, 7 Dec 1999 21:59:39 +0100 (CET) From: Zsolt Szekeres To: chemistry@ccl.net cc: surjan@para.chem.elte.hu Subject: EOM IP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I've been calculating ionization potentials using the EOM technique. Considering the simplest ionization operator, one yields the generalized eigenvalue equation of the generalized Fockian: Fc=ePc, where P is the first-order density matrix and e is the ionization potential. Once the generalized eigenvalue problem of F is solved, several e's appear. Some of these are valid solutions, some of them are completely irreal. My question is how to tell which solutions are proper, ie. how to tell apart the "good" and the "bad" solutions. An answer to this question would be the choice of the norm of the Feyman-Dyson amplitudes belonging to the e's. This one seems to be a good choice till one attempts to do calculations in larger basis sets (cc-PTVZ). /The applied wavefunction is geminal./ Unfortunately, these numbers fail to work at some point: these norms give you not only large (close to 1) and small (close to 0) numbers, but also numbers around 0.5 ... Any detailed help or reference would be appreciated. Zsolt Szekeres --------------------------------------------------------------- seky@theopzs.chem.elte.hu Cell: 36-20-334-5134 www: duke.usask.ca/~szekeres Fax : 36- 1-209-0602