From owner-hyperchem@hyper.com Mon May 6 17:34:47 1996 Date: Mon, 6 May 96 13:07:22 -0400 From: polowin (Joel Polowin) To: hyperchem@hyper.com Subject: MM+ bug in HyperChem An obscure bug has been found in the MM+ force field for HyperChem. The effect is that under certain circumstances, HyperChem reads a set of parameters for one torsional angle calculation, and uses the same parameters for another torsional angle as well, instead of getting new parameters. This happens *only* when: * The MM+ force field is used * The 'default' parameters are not used -- i.e., all atoms in a dihedral angle have types * The workspace contains dihedral angles with the same atom types arranged in two different ways: A-B-C-D and A-C-B-D. This is, of course, a problem only if the parameters for the two different angles should be different. This is the case for 80 pairs of torsional parameters out of 1498 sets of parameters. In most cases, even if the error occurs it does not lead to much change in the parameters; but in the case of cyclohexa-1,4-diene, there is a significant change in the parameter values (including a sign change), and there are many incorrect parameters which overwhelm the effects of the correct ones. A list of the pairs of parameters which lead to this problem is available from our WWW site (http://www.hyper.com), or by E-mail on request. We would like to thank Alexandre Hocquet for bringing the problem to our attention. We expect to be issuing corrected versions of the MM+ backend to all of our users to correct the problem. Further details will be available soon. Joel ------------ Joel Polowin, Ph.D. Manager, Scientific Support Email to: polowin@hyper.com WWW: http://www.hyper.com/ Hypercube Inc, 419 Phillip St, Waterloo, Ont, Canada N2L 3X2 (519)725-4040 Info requests to: info@hyper.com Support questions to: support@hyper.com Email group: Send "subscribe hyperchem" (or "unsubscribe hyperchem") to hyperchem-request@hyper.com; please do not send such administrative messages to the group itself. _______________________________________________________________________________ From owner-hyperchem@hyper.com Thu May 16 15:44:43 1996 Date: Thu, 16 May 1996 08:25:50 -0500 (EST) From: Gary Wiggins X-Sender: wiggins@copper.ucs.indiana.edu To: hyperchem@hyper.com Subject: your URL Is this still the URL for the HyperChem Web site: http://www.hyper.com I couldn't connect today. Gary Wiggins _______________________________________________________________________________ From owner-hyperchem@hyper.com Tue May 21 00:33:08 1996 From: orcaro@lux.levels.unisa.edu.au (orcaro) Subject: MO/MM energies To: hyperchem@hyper.com (Hyperchem List) Date: Tue, 21 May 1996 11:41:31 +0930 (GMT+0930) Hello all, I'm trying to use Hyperchem to derive force-field parameters following Hopfinger & Pearlstein's method (JCC, vol 5, no 5, 1984). This involves curve-fitting to a plot of the difference between the MO (semi-empirical) and MM (force-field) energies. However, the values for these energies are completely different. For example, H&P give an example using H2SO with energies less than 100 kcal/mol. I get MM/FF (MM+) energies in this range, but MO/SE (MNDO) energies of the order of -13300. Are these energies on the same scale or is some conversion necessary? Thanks. * Anthony O'Dea * * orcaro@lux.levels.unisa.edu.au * * South Australian Surface Technology Centre * * Ian Wark Research Institute * * University of South Australia * _______________________________________________________________________________ From owner-hyperchem@hyper.com Tue May 21 01:13:16 1996 From: orcaro@lux.levels.unisa.edu.au (orcaro) Subject: MO/MM energies To: hyperchem@hyper.com (Hyperchem List) Date: Tue, 21 May 1996 12:54:22 +0930 (GMT+0930) Hello all (again), Further to my earlier question, when using Excel macros to run a series of calculations, the MO/SE energy reported in the Hyperchem status line and that appearing in the Excel spreadsheet are different. This is not the case for MM/FF energies, which leads me to ask whether it is the energies given in the status line, or those grabbed by Excel (total-energy) are the ones I should be looking at? Thanks (again). * Anthony O'Dea * * orcaro@lux.levels.unisa.edu.au * * South Australian Surface Technology Centre * * Ian Wark Research Institute * * University of South Australia * _______________________________________________________________________________ From owner-hyperchem@hyper.com Wed May 22 17:25:28 1996 Date: Wed, 22 May 96 18:57:48 +0200 From: ferenc@rchsg8.chemie.uni-regensburg.de (Ferenc Molnar) To: hyperchem@hyper.com Subject: forces? Dear HyperChem users: I already sent a similar request to "info@hyper.com" but got no reply, so maybe you can help me ... Please answer directly to my email address, because I am not a member of this list. Thank you! My question is (sorry if it is a FAQ): How can I obtain the cartesian forces on the atoms during a MD simulation? Is there a way to force the printing of the forces into the log file? I already tried to set the MechanicsPrintLevel to 9 but there was no avail. So ...? Cheers, Ferenc Ferenc Molnar --------------------------------------------------------------------------- Institut fuer Physikalische und Theoretische Chemie - Lehrstuhl Prof. Dick - Tel.: (+49) 941 943-4466 /-4486 Universitaet Regensburg Fax.: (+49) 941 943-4488 Universitaetsstrasse 31 D-93053 Regensburg Deutschland / Germany --------------------------------------------------------------------------- EMail (SMTP): Ferenc.Molnar@chemie.uni-regensburg.de --------------------------------------------------------------------------- Those who do not archive the past are condemned to retype it! -- Garfinkel & Spafford, Practical Unix Security --------------------------------------------------------------------------- _______________________________________________________________________________ From owner-hyperchem@hyper.com Wed May 22 17:35:20 1996 Date: Wed, 22 May 96 13:24:23 -0400 From: polowin (Joel Polowin) To: orcaro@lux.levels.unisa.edu.au (orcaro), hyperchem@hyper.com (Hyperchem List) Subject: Re: MO/MM energies > From: orcaro@lux.levels.unisa.edu.au (orcaro) > Date: Tue, 21 May 1996 11:41:31 +0930 (GMT+0930) > > I'm trying to use Hyperchem to derive force-field parameters > following Hopfinger & Pearlstein's method (JCC, vol 5, no 5, > 1984). This involves curve-fitting to a plot of the difference > between the MO (semi-empirical) and MM (force-field) energies. > However, the values for these energies are completely different. > For example, H&P give an example using H2SO with energies less > than 100 kcal/mol. I get MM/FF (MM+) energies in this range, > but MO/SE (MNDO) energies of the order of -13300. Are these > energies on the same scale or is some conversion necessary? All of the reported values are in kcal/mol, but the energy functions are completely different -- at best, you could consider that the zero points for the values are unrelated. I don't have immediate access to a copy of the paper that you mention to see if there are other problems/limitations. > Further to my earlier question, when using Excel macros to > run a series of calculations, the MO/SE energy reported in > the Hyperchem status line and that appearing in the Excel > spreadsheet are different. This is not the case for MM/FF > energies, which leads me to ask whether it is the energies > given in the status line, or those grabbed by Excel > (total-energy) are the ones I should be looking at? The value reported on the status line after a semi-empirical calculation is the binding energy, i.e., the total energy minus the isolated atom energies. You can get all of these values (and more) by starting a log file before you do a calculation; I don't know which of these is most appropriate to the fitting that you want to do. Joel ------------ Joel Polowin, Ph.D. Manager, Scientific Support Email to: polowin@hyper.com WWW: http://www.hyper.com/ Hypercube Inc, 419 Phillip St, Waterloo, Ont, Canada N2L 3X2 (519)725-4040 Info requests to: info@hyper.com Support questions to: support@hyper.com Email group: Send "subscribe hyperchem" (or "unsubscribe hyperchem") to hyperchem-request@hyper.com; please do not send such administrative messages to the group itself. _______________________________________________________________________________ From owner-hyperchem@hyper.com Thu May 23 21:01:55 1996 Date: Thu, 23 May 96 16:13:29 -0400 From: polowin (Joel Polowin) To: hyperchem@hyper.com Subject: Re: forces? > Date: Wed, 22 May 96 18:57:48 +0200 > From: ferenc@rchsg8.chemie.uni-regensburg.de (Ferenc Molnar) > > How can I obtain the cartesian forces on the atoms > during a MD simulation? Is there a way to force the > printing of the forces into the log file? Mirek Sopek found a way to calculate the forces, a couple of months ago. The forces cannot be output directly from HyperChem. But he took a structure, assigned a velocity of 0 to each atom, and then did a molecular dynamics calculation with one short time step. The resulting atomic velocities, combined with the atomic masses and the length of the time step, allowed him to calculate reasonably accurate values for the forces. He wrote a script which can produce files of atomic masses and velocities; I will append that script below. One would select a time step from the MD snapshot file, select all the atoms, use Setup/Set Velocity to set their velocities to 0, and then run the script. For each atom, F(x)=m * lim(Delta t -->0) (Delta v(x) / Delta t); or, for a small time step, F(x) = m * Delta v(x) / Delta t. The same calculation is done for y and z. Alternately, one could use a sequential pair of snapshots and simply subtract the atomic velocities in the first from the velocities in the second to get the velocity changes. I tested the procedure by model-building a water molecule, saving it, and then running the script using MM+. For one of the hydrogen atoms, I found that the mass was 1.008 amu, and the final velocity was (-0.4187416, 0.4055699, 0.0) with a time step of 0.0001 ps. This gave F(x) = -4220.9 amu A ps^-2; F(y) = 4088.1 amu A ps^-2; F(z) = 0. Then I took the original file and copied it to six other files; for two, I changed the x coordinate of that atom by +/- 0.000010 A, and in the others I changed the y and z coordinates. I ran a single-point calculation on each of the six structures and recorded the energies. Then F(x) = - Delta E / Delta x = -0.000202 kcal/mol / .000020 A = -10.1 kcal/mol/A or -4229.0 amu A ps^-2; similarly F(y) was 4082.5 amu A ps^-2 and F(z) = 0. That is, the two methods gave results that were reasonably similar. Joel ------------ Joel Polowin, Ph.D. Manager, Scientific Support Email to: polowin@hyper.com WWW: http://www.hyper.com/ Hypercube Inc, 419 Phillip St, Waterloo, Ont, Canada N2L 3X2 (519)725-4040 Info requests to: info@hyper.com Support questions to: support@hyper.com Email group: Send "subscribe hyperchem" (or "unsubscribe hyperchem") to hyperchem-request@hyper.com; please do not send such administrative messages to the group itself. ----- ; Mirek Sopek's script to save atomic velocities and masses ; For HyperChem 4, delete the parts about the atomic masses; you'll have ; to get these manually message "Extracting cartesian forces from HyperChem" dynamics-heat-time = 0.0 dynamics-run-time = 0.0001 dynamics-cool-time = 0.0 dynamics-time-step =0.0001 dynamics-starting-temp = 0.0 dynamics-simulation-temp = 0.0 dynamics-final-temp = 0.0 dynamics-restart = yes dynamics-constant-temp = no do-molecular-dynamics omsgs-to-file velo_dat.txt query-value dynamics-time-step query-value Molecule-count query-value Atom-count query-value velocities omsgs-to-file mass_dat.txt query-value Molecule-count query-value Atom-count query-value atom-mass omsgs-not-to-file message "Calculation done - velocities are in file 'velo_dat.txt' masses in 'mass_dat.txt'" _______________________________________________________________________________ From owner-hyperchem@hyper.com Fri May 24 18:33:38 1996 From: tim.porter@nau.edu Date: Fri, 24 May 1996 10:47:31 -0700 Subject: large molecules To: hyperchem@hyper.com I am attempting to do an AM1 calculation on a very large molecule (916 atoms, I know it is a century-long calculation!) using HyperChem 4.5 for windows. On startup of the single point calculation, the system indicates it is out of memory and stops the calculation. My question is twofold: about how much "memory" would I need to do this calculation (about 3500 orbitals), and if I dont have this much physical memory in the computer, why will the systen not simply use disk space as virtual memory?? -- ----------------------------------------------------------- Tim.Porter@nau.edu ----------------------------------------------------------- _______________________________________________________________________________ From owner-hyperchem@hyper.com Fri May 24 19:00:47 1996 Date: Fri, 24 May 96 14:58:56 -0400 From: polowin (Joel Polowin) To: hyperchem@hyper.com, CHEMISTRY@infomeister.osc.edu Subject: HyperChem MM+ correction We have created new versions of the MM+ computational modules which have had the earlier error in parameter selection corrected. The updated files are available from our ftp site, ftp.hyper.com, in the /pub/patch directory. The relevant files are: mmpfix40.exe for HyperChem 4 for Windows mmpfix45.exe for HyperChem 4.5 for Windows or HyperChem Lite hc45_mmplus.Z for HyperChem 4.5 for SGI. By WWW browser, please go to: http://www.hyper.com/Support/mmperr.html . If you have HyperChem for Windows, you should copy the appropriate update file to your HyperChem directory and run it (for example, by double-clicking on the file's icon in the Windows File Manager). The updated MMPLUS.EXE should over-write the old one. The file for HyperChem 4 will also work for HyperChem 3, though the software will complain about the version mismatch. If you have HyperChem for SGI, you will need to de-compress the file with "uncompress" and place it in the directory /usr/sbin (replacing the old file). We will mail the update file(s) to our registered customers on request, and we will be notifying our registered customers of the problem and solution by mail. We will also be sending the patch files to our dealers, so that they will be able to help our customers directly. Joel ------------ Joel Polowin, Ph.D. Manager, Scientific Support Email to: polowin@hyper.com WWW: http://www.hyper.com/ Hypercube Inc, 419 Phillip St, Waterloo, Ont, Canada N2L 3X2 (519)725-4040 Info requests to: info@hyper.com Support questions to: support@hyper.com _______________________________________________________________________________ From owner-hyperchem@hyper.com Mon May 27 16:14:49 1996 Date: Mon, 27 May 96 10:47:58 -0400 From: polowin (Joel Polowin) To: tim.porter@nau.edu, hyperchem@hyper.com Subject: Re: large molecules > From: tim.porter@nau.edu > Date: Fri, 24 May 1996 10:47:31 -0700 > > I am attempting to do an AM1 calculation on a very large molecule (916 > atoms, I know it is a century-long calculation!) using HyperChem 4.5 for > windows. On startup of the single point calculation, the system indicates > it is out of memory and stops the calculation. My question is twofold: > about how much "memory" would I need to do this calculation (about 3500 > orbitals), and if I dont have this much physical memory in the computer, > why will the systen not simply use disk space as virtual memory?? HyperChem *will* use virtual memory; when you start a calculation, it requests memory allocation from Windows, and Windows tries to do this from the available real and virtual RAM. But, to quote from our document on memory requirements, SCF Calculation --------------- The major contribution to memory usage (not the only one) for a 'standard' RHF calculation is 104 * (Number of orbitals)^2 bytes. If you are doing other kinds of calculation, additional memory is required: UHF: + 40 * (Number of orbitals)^2 bytes Convergence accelerator: + 160 * (Number of orbitals)^2 bytes Gradient Calculation -------------------- HyperChem computes the gradient for all kinds of calculation, so even for a single point calculation to complete, you will need space for a gradient evaluation. The gradient requirements are in addition to the SCF requirements. In the following expression, NHA = "non-hydrogen atoms", HA = "Hydrogen atoms". Memory required = 2400 * NHA * (NHA - 1) + 440 * NHA * HA + 24 * HA * (HA-1) bytes. So the amount of memory required for the RHF calculation would be about 1.27 Gb; if you're doing UHF, add 490 Mb; if you're using the convergence accelerator, add 1.96 Gb. Assuming that you've got about 700 non-hydrogen atoms and 216 hydrogen atoms, the gradient calculation requires about another 1.24 Gb. You would therefore need to have a minimum of about 2.5 Gb of hard drive space allocated as virtual memory. To do the matrix calculations, another requirement is real RAM space of 8 bytes * (#orbitals)^2 -- in this case, nearly 100 Mb. I think that you will need to reduce the scale of your calculations. Bear in mind that century-long calculations are probably not practical; not only is it *extremely* unlikely that you could keep your computer running continuously for more than a few years, but if you just wait a few years, the computers available then will probably be much more powerful! Joel ------------ Joel Polowin, Ph.D. Manager, Scientific Support Email to: polowin@hyper.com WWW: http://www.hyper.com/ Hypercube Inc, 419 Phillip St, Waterloo, Ont, Canada N2L 3X2 (519)725-4040 Info requests to: info@hyper.com Support questions to: support@hyper.com Email group: Send "subscribe hyperchem" (or "unsubscribe hyperchem") to hyperchem-request@hyper.com; please do not send such administrative messages to the group itself. _______________________________________________________________________________ From owner-hyperchem@hyper.com Tue May 28 00:51:28 1996 From: gerardo@houston.cray.com (Gerardo Cisneros) Subject: FINAL PROGRAM: 3rd UNAM-Cray Supercomputing Symposium To: amber@cgl.ucsf.edu, anneal@cs.ucla.edu, apchem@mailbase.ac.uk.cray.com, c2-l@msi.com, cache@pacificu.edu, charmm-bbs@emperor.harvard.edu, chemconf@umdd.umd.edu, chemistry@infomeister.osc.edu, dibug@comp.bioz.unibas.ch, hyperchem@hyper.com, mmodinfo@uoft02.utoledo.edu, sybyl@extreme.chem.rpi.edu Date: Mon, 27 May 1996 19:37:16 -0500 (CDT) Here is the Final Program for the 3rd UNAM-CRAY Supercomputing Conference, "Computational Chemistry". This information, along with abstracts, is available on the WWW at http://www.super.unam.mx/super/symposium/simposio96.html A registration form and hotel information are included. We hope to see you in Mexico. Saludos, Gerardo -- Dr. Gerardo Cisneros |Cray Research de Mexico, S.A. de C.V. Senior Scientist |Insurgentes Sur 1685-704, Col. Guadalupe Inn gerardo@cray.com |01020 Mexico, D.F. (+52+5)622-8584 |MEXICO ------------------------------------------------------------------------- Monday, August 12 Afternoon-Evening: Registration, Royal Hotel Pedregal 20:00 Welcoming Cocktail, Royal Hotel Pedregal - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Tuesday, August 13 8:30 Opening ceremony Auditorio "Carlos Graef", Amoxcalli, Facultad de Ciencias, Universidad Nacional Aut\'onoma de M\'exico (UNAM) 9:00 (Invited talk) Per-Olov L\"owdin, University of Uppsala and University of Florida "On the Use of Resolvent Methods and Inner Projections in the Development of Computational Quantum Chemistry in the Future" 10:00 Claudia Mancera, J. A. Cogordan and Roberto Martinez, UNAM "Molecular Dynamics Simulations of B-DNA Intercalator Complexes" 10:30 Carlos Kubli-Garfias, UNAM "Ab Initio Study of Testosterone Conformers" 11:00 Coffee Break 11:30 (Invited talk) Dennis R. Salahub, University of Montreal "Opportunities for HPCC Involving DFT" 12:30 Jorge Seminario, University of New Orleans "A Combined DFT/MD Procedure for the Study of Energetic Materials" 13:00 Ang\'elica Zacar\'\i as and Miguel Castro, UNAM "Density Functional Study of Fe-N$_2$, Fe$_2$-N$_2$ and Fe$_2$S$_2$-N$_2$" 13:30 Lunch Break 15:30 (Invited talk) R. J\'auregui, C.F. Bunge and E. Ley-Koo, UNAM "Theory of the N-electron Dirac equation with two-body interactions" 16:30 Coffee Break 17:00 Ajay C. Limaye, University of Pune "Parallel MP2 Energy Evaluation: A Simulated Shared Memory Approach on Distributed Memory Parallel Machines" 17:30 B. Dietz, T. H. Seligman and M. Lombardi, UNAM "The Rydberg Molecule: A Model Case for the Study of Chaos in Structure and Scattering" - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Wednesday, August 14 9:00 (Invited talk) Ludger Br\"ull, Bayer AG "Optimization of entire chemical production plants" 10:00 Diana Guenzburguer, Centro Brasileiro de Pesquisas Fisicas "Electronic structure and hyperfine properties of molecules and solids by cluster methods" 10:30 Andrea Gerson, University of South Australia "The Surface Modification of Kaolinite using Water Vapour Plasma" 11:00 Coffee Break 11:30 (Invited talk) Roger Elliott, Oxfor University "The development of supercomputing in the UK---past, present and future?" 12:30 Marek T. Michalewicz and Roger W. Brown, CSIRO and Cray Research, Inc. "Electronic Structure Computations of Very Large Non-Periodic Atomic Systems on PVP and MPP CRAY Architectures" 13:00 M. Cruz, M. R. Beltr\'an, C. Wang and J. Tag\"ue\~na-Mart\'\i nez, UNAM "Computational Modelling of Electronic and Optical Properties in Porous Silicon" 13:30 Lunch Break 15:30 (Invited talk) Charlotte Froese Fischer, Vanderbilt University "Large Scale Atomic Structure Calculations" 16:30 Coffee Break 17:00 Elena Charro and Inmaculada Mart\'{\i}n, Universidad de Valladolid "Systematic Trends of Silicon Sequence: a Relativistic Quantum Defect Orbital Study" 17:30 Gerardo Cisneros and Carlos F. Bunge, Cray Research de Mexico and UNAM "Analysis and evaluation of CI matrices in terms of indicial structures for singly and doubly excited substitutions from a closed shell determinant" - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Thursday, August 15 9:00 (Invited talk) Mark A. Stadtherr and Jayarama U. Mallya, U. of Notre Dame and Cray Research, Inc. "Computational Strategies for Chemical Process Engineering Using Parallel/Vector Supercomputers" 10:00 G.M. Ostrovsky, Yu.M. Volin and D.V. Golovashkin, Karpov Institute of Physical Chemistry, NIFHI "Optimization of chemical processes under uncertainty" 10:30 Jason Lye, Harold S. Freeman and David Hinks, North Carolina State University "Computational Chemistry Applied to Synthetic Dyestuffs" 11:00 Coffee Break 11:30 (Invited talk) S. B. Trickey, University of Florida "Simple DFT-LSDA Modelling of the Molecular-like Aspects of Ultra-thin Film Properties" 12:30 J. F. Rivas-Silva, A. Flores-Riveros, M. Berrondo and A. Ayuela, UNAM, Brigham Young University and Technishe Universit\"at Dresden "Optical Properties of Ce$^{+3}$ Embedded in a LIGDBO crystal" 13:00 A. F. Kovalenko, UNAM "Scattering of a Carrier by a Charged Center Situated Near a Semiconductor-Insulator Interface" 13:30 Lunch Break 15:30 (Invited talk) Michel Dupuis, Pacific Northwest Laboratory "Ab Initio Study of Mixed-Valence Complexes" 16:30 Coffee Break 17:00 M.T. Michalewicz, D.A. Winkler, M. Brunger, I.E. McCarthy and W. von Niessen CSIRO, Flinders University of South Australia and Technische Universit\"at Braunschweig "A UniChem and Electron Momentum Spectroscopy Investigation into the Valence Electronic Structure of trans 1,3 Butadiene" 17:30 Sundaravel P. Ananthavel and Manjunatha S. Hegde, Indian Institute of Science "Ab-initio MO studies of Donor-Acceptor and Hydrogen Bonded Complexes" - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Friday, August 16 9:00 (Invited talk) Ren\'{e} Ba\~{n}ares-Alc\'{a}ntara, University of Edinburgh "A Model of the Chemical Engineering Design and Modelling Processes" 10:00 Luis Javier Alvarez, Jorge E. S\'anchez-S\'anchez, Javier Fern\'andez-Sanz and Jos\'e Antonio Odriozola, UNAM, Universidad de Sevilla and CSIC "A Critical Review of Gamma-Alumina Quantum Mechanical and Molecular Dynamics Studies" 10:30 Orest Pizio and Andrij Trokhymchuk, UNAM "Solution of integral equations and Monte Carlo simulations for the models of chemically associating fluids at interfaces" 11:00 Coffee Break 11:30 (Invited talk) Matti Manninen, University of Jyv\"askyl\"a (Title to be confirmed) 12:30 Simon C. Potter, Dominic J. Tildesley, Andrew N. Burgess and Steve C. Rogers University of Southampton, University of London Imperial College od Science, Technology and Medicine; and ICI Chemicals and Polymers Ltd. "Molecular dynamics simulation of difluoromethane: orthobaric densities, enthalpies and structure" 13:00 Ignacio L. Garz\'on and Alvaro Posada-Amarillas, UNAM and Universidad de Sonora "Molecular Dynamics Study of the Structural Properties of Liquid and Amorphous Ni" 13:30 Lunch Break 15:30 (Invited talk) Walter R. Johnson, University of Notre Dame "Relativistic Many-Body Calculations of Atomic Energy Levels and Transition Probabilities" 16:30 Coffee Break 17:00 Milton Medeiros and Maria Eugenia Costas, UNAM "Monte Carlo Study of a Polarizable Model for Water" 17:30 Flor Marina Poveda and Fernando Ruette, Universidad Nacional de Colombia and Centro de Qu\'{\i}mica (Venezuela) "Theoretical Modelling of Hydrogenation Reactions of CH$_n$ ($n=0, 1, 2, 3$) Fragments on a Nickel Catalyst" - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Poster I -- Tuesday and Wednesday, August 13-14. L. H. Rodr\'{\i}guez-Merino and J. F. Rivas-Silva, Universidad Aut\'onoma de Puebla "Absorption and Emission of Alkali-Halides Doped With Thalium Through HF and DFT Approaches: A Comparison" J. Carlos Ruiz-Su\'arez, J. Torres-Jim\'enez y L. G. Ruiz-Su\'arez CINVESTAV-IPN, ITESM-Morelos and UNAM "Genetic Optimization of Random Kinetic Mechanisms" Christof Jung, UNAM "The role of unstable invariant sets in chemical reactions" B. Dietz, F. Leyvraz and T. H. Seligman, UNAM "The Transition from the Harmonic Oscillator to Chaos" K. Michaelian and E. Ram\'{\i}rez-Jaramillo, UNAM "Evolving Crystals with Genetic Al\-go\-rithms" Andrij Trokhymchuk, UNAM "Application of the Integral Equation Theory for the Treatment of Long-Range Forces in Computer Simulation of Liquids with Electrostatic Interactions" Isidoro Garc\'\i a-Cruz, V\'\i ctor Uc-Rosas and Annik Vivier-Jegoux Instituto Mexicano del Petr\'oleo and Universidad Aut\'onoma Metropolitana---Iztapalapa "Model calculations for alcane hydrogen abstractions by OH radicals" Esther Agacino, Pablo de la Mora and Miguel Castro, UNAM "Theoretical Study of Carbon Clusters" Jes\'us Hern\'andez-Trujillo, Miguel Costas and Fernando Colmenares, UNAM "Pseudopotential MP2 Ab Initio Calculations of the Benzene-Hexafluorobenzene Complex" Maria Eugenia Costas, Estrella Ramos and Rodolfo Acevedo-Ch\'avez UNAM and Universidad Au\'onoma de Puebla "DFT Study of Purine-type Heterocycles: Hypoxanthine and Allopurinol" Joel Ireta and Marcelo Galv\'an Universidad Aut\'onoma Metropolitana---Iztapalapa "Plane waves basis sets in the description of diatomic anions and valence charge density" - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Poster II -- Thursday and Friday, August 15-16. Kanidtha Hansongnern, Orawan Sirichote, Robert L. Metcalf, Philip A. Lewis, Chatchai Jantaraprim and Susan Gustafson Prince of Songkla University, University of Illinois and Cray Research, Inc. "Theoretical Studies of Some Attractants as a Probe for Receptors in the Southern Corn Rootworms (SCR)" Shridhar R. Gadre, Ajay C. Limaye and Savita S. Pundalik University of Pune "Molecular Tailoring Approach for Simulation of Electrostatic Properties and Molecular Recognition Studies" "MoO3 and a theoretical electronic calculation" Donald Homero Galv\'an, UNAM Carlos Quintanar, E. Mu\~noz, R. Gleason, J. L. Bold\'u and Miguel Castro, UNAM "Density Functional Calculations for a Mn Impurity in Cubic Symmetry Sites of NaCl" Eduardo Jardon, Fernando Colmenares, Manuel Martinez-Magadan and Octavio Novaro UNAM and Instituto Mexicano del Petr\'oleo "Theoretical Study of the Interaction of the Hydrogen Molecule with Sulfur Systems of Iron and Molybdenum." Pablo de la Mora, Sabina Ruiz and Miguel Castro, UNAM "Vibrational analysis of the Cu(2)-O(4)-Cu(1)-O(4)-Cu(2) cluster of the YBa$_2$Cu$_3$O$_7$ superconductor" A. A. Huerta and J. A. Cogordan, UNAM "Analysis of Water Distribution Around DNA-Triplex Molecules" L. E. Sansores and Roberto Salced, UNAM "Electronic Structure of the 4n{$\pi$} + 4n{$\pi$} Cyclobutadienoquinone" Gerardo G. Naumis, C. Wang and R. A. Barrio, UNAM "Renormalization Approach to Electronic Properties of Large Quasiperiodic Lattices" Rene Fournier, University of Nevada Las Vegas "Theoretical study of the photoabsorption and photodetachment spectra of niobium clusters" ------------------------------------------------------------------------- REGISTRATION The conference registration fee is US$300, which includes a copy of the proceedings and a ticket for the closing dinner. There will be a reduced registration fee for students of domestic academic institutions. Please fill in the following form and return by e-mail to: simposio@servidor.unam.mx +---------------------------------------------------------------+ | REGISTRATION FORM | | | | ----THIRD UNAM-CRAY SUPERCOMPUTING CONFERENCE---- | | ----------------------------------------- | | | | C O M P U T A T I O N A L C H E M I S T R Y | | | | A symposium to be held in Mexico City | | from August 13th through the 16th, 1996 | +---------------------------------------------------------------+ Name (last, first): E-mail address: Institution: Address: Phone: Fax: ---------------------------------------------------------------------- Contact Address: 3rd UNAM-CRAY Supercomputing Conference DGSCA/UNAM Apdo. Postal 20-059 01000 Mexico, D.F. MEXICO Electronic Mail: simposio@servidor.unam.mx Fax: (+52+5) 622-8043 ----------------------------------------------------------------------- HOTEL INFORMATION A block of rooms has been reserved at the Royal Hotel Pedregal, which is a five-star hotel near the UNAM main campus. The rate per night will be Mex$494.50, Value Added Tax (15%) included. At the current rate of exchange this is about US$66.00. Transportation will be provided between the hotel and the Amoxcalli building where the conference sessions will be held. Attendees are requested to make their own reservations directly with the hotel. MAKE SURE YOU MENTION THE "UNAM-CRAY II" GROUP RATE WHEN MAKING YOUR RESERVATION. Name, address and numbers at the hotel follow: Royal Hotel Pedregal Periferico Sur 4363 Col. Jardines en la Monta~na 14210 Mexico, D.F. MEXICO Phone: (+52+5)726-9036 Fax: (+52+5)645-7964 ----------------------------------------------------------------------- _______________________________________________________________________________ From owner-hyperchem@hyper.com Tue May 28 05:08:07 1996 From: hoock@hki-jena.de (Christoph Hoock) Subject: script / AbInitio To: hyperchem@hyper.com Date: Tue, 28 May 1996 08:21:20 +0200 (MDT) Dear HyperChem users, does anybody know how to to change to a differnet AbInitio basis set using the hyperchem script language? The command "assign-basisset STO3G" or similiar commands seem to have no effect. Kind regards -- Christoph hoock@imb-jena.de Hans-Knoell-Institut fuer Naturstofforschung Beutenbergstrasse 11, Jena Tel.: +49-3641-65-6710 Postfach 100 813, D-07708 Jena, Germany Fax: +49-3641-65-6700 _______________________________________________________________________________ From owner-hyperchem@hyper.com Tue May 28 05:40:45 1996 From: ps@ocisgi7.unizh.ch (Serge Pachkovsky) Subject: Re: large molecules To: polowin (Joel Polowin) Date: Tue, 28 May 1996 08:37:56 +0200 (MDT) Cc: tim.porter@nau.edu, hyperchem@hyper.com > > From: tim.porter@nau.edu > > Date: Fri, 24 May 1996 10:47:31 -0700 > > > > I am attempting to do an AM1 calculation on a very large molecule (916 > > atoms, I know it is a century-long calculation!) using HyperChem 4.5 for 916 atoms with AM1 need not be (and is not) a century-long calculation. Full geometry optimizations were done on larger molecules, e.g. C_{960} with 3840 orbitals (Bakowies, Buehl and Thiel, Chem. Phys. Lett. 247, 491 (1995)) using semiempirical code of the classical structure, and much larger systems are treatable with sparseness-aware codes (Stewart, Intl. J. Quantum Chem, 58, 133 (1996)) or divide-and-conquer codes (Dixon and Merz, J. Chem. Phys. 104, 6643 (1996)). I happen to know that the C_{960} was done fully in-core on a machine with 1Gb of memory, with execution times below one week (with 75MHz R8000 CPU, with is may be just two times faster than current crop of Pentium Pro's, if even that). > Gradient Calculation > -------------------- > HyperChem computes the gradient for all kinds of > calculation, so even for a single point calculation to > complete, you will need space for a gradient > evaluation. The gradient requirements are in addition > to the SCF requirements. > In the following expression, NHA = "non-hydrogen > atoms", HA = "Hydrogen atoms". > > Memory required = 2400 * NHA * (NHA - 1) + 440 * NHA * > HA + 24 * HA * (HA-1) bytes. Isn't that a tad too much, at least in the SCF case? The figure above means that 600 double precision words are stored for each pair of (non-hydrogen) atoms. Even if you choose to store derivative integrals (which is absolutely not necessary and is even harmful, since it decreases memory locality), you should have at most 3*(4*(4+1)/2)^2 = 300 double precision words for a pair of (non-hydrogen) atoms. Regards, /Serge.P _______________________________________________________________________________ From owner-hyperchem@hyper.com Tue May 28 20:40:08 1996 Date: Tue, 28 May 96 16:15:20 -0400 From: polowin (Joel Polowin) To: ps@ocisgi7.unizh.ch (Serge Pachkovsky) Subject: Re: large molecules Cc: hyperchem@hyper.com > From: ps@ocisgi7.unizh.ch (Serge Pachkovsky) > Date: Tue, 28 May 1996 08:37:56 +0200 (MDT) > > 916 atoms with AM1 need not be (and is not) a century-long calculation. > Full geometry optimizations were done on larger molecules, e.g. C_{960} > with 3840 orbitals (Bakowies, Buehl and Thiel, Chem. Phys. Lett. 247, 491 > (1995)) using semiempirical code of the classical structure, and much > larger systems are treatable with sparseness-aware codes (Stewart, Intl. > J. Quantum Chem, 58, 133 (1996)) or divide-and-conquer codes (Dixon and Merz, > J. Chem. Phys. 104, 6643 (1996)). I happen to know that the C_{960} was > done fully in-core on a machine with 1Gb of memory, with execution times > below one week (with 75MHz R8000 CPU, with is may be just two times > faster than current crop of Pentium Pro's, if even that). Of course, anything that is run fully in-core will be *much* faster than the same calculation that requires disk storage. I don't think that even the Pentium Pros are getting anywhere near 1Gb of RAM? > > Memory required = 2400 * NHA * (NHA - 1) + 440 * NHA * > > HA + 24 * HA * (HA-1) bytes. > > Isn't that a tad too much, at least in the SCF case? The figure > above means that 600 double precision words are stored for each > pair of (non-hydrogen) atoms. Even if you choose to store derivative > integrals (which is absolutely not necessary and is even harmful, since > it decreases memory locality), you should have at most 3*(4*(4+1)/2)^2 > = 300 double precision words for a pair of (non-hydrogen) atoms. As one of my colleagues just pointed out to me, 300 double precision words = 2400 bytes, as above. (He also noted that the '440' above should be '480' instead.) The above memory requirement is for storing the gradient; the storage requirement for the SCF value itself is 1/3 of the above. Joel ------------ Joel Polowin, Ph.D. Manager, Scientific Support Email to: polowin@hyper.com WWW: http://www.hyper.com/ Hypercube Inc, 419 Phillip St, Waterloo, Ont, Canada N2L 3X2 (519)725-4040 Info requests to: info@hyper.com Support questions to: support@hyper.com Email group: Send "subscribe hyperchem" (or "unsubscribe hyperchem") to hyperchem-request@hyper.com; please do not send such administrative messages to the group itself. _______________________________________________________________________________ From owner-hyperchem@hyper.com Tue May 28 20:49:11 1996 Date: Tue, 28 May 96 17:54:46 -0400 From: polowin (Joel Polowin) To: "Wolfgang Ziche" , Subject: Re: Saving results for later use > Date: Tue, 28 May 96 17:51:34 MET > From: "Wolfgang Ziche" > > 1. Can I save the results from single point calculations in such a way that I > can re-use them for a later or additional visualization in ChemPlus Presen- > tations? Can the *.log files be read? > > 2: Is it possible to do the same for "foreign" ab initio results, e.g. > transition states from Gaussian94, or do I just perform a single point > calculation (needs extra time) on the basis of the obtained geometry? Unfortunately, there is no way for the current versions of HyperChem to import or read things like the orbital coefficients; although these values can be output through script commands, or saved in a log file, they cannot be brought back in later. To work with the results of QM calculations from other software, you would have to import the geometry and then do the calculation in HyperChem. (For HyperChem for SGI, there is a utility that can convert Gaussian grid data into a form that HyperChem can read and display. It *should* be possible to do the same sort of thing to let the ChemPlus Molecule Presentations module display grid data, but we do not know of anyone who has built such a utility.) Correcting this limitation is high on our development wish list, but it is impossible to predict when it might happen. Joel ------------ Joel Polowin, Ph.D. Manager, Scientific Support Email to: polowin@hyper.com WWW: http://www.hyper.com/ Hypercube Inc, 419 Phillip St, Waterloo, Ont, Canada N2L 3X2 (519)725-4040 Info requests to: info@hyper.com Support questions to: support@hyper.com Email group: Send "subscribe hyperchem" (or "unsubscribe hyperchem") to hyperchem-request@hyper.com; please do not send such administrative messages to the group itself. _______________________________________________________________________________ From owner-hyperchem@hyper.com Wed May 29 07:35:26 1996 Date: Wed, 29 May 1996 14:38:24 +1000 (EST) From: Chris Kladis To: hyperchem@hyper.com Subject: Possible Stupid Question I am using HyperChem's MM+ force field to calculate Ligand Repulsion Energies (LRE's) and I am having some problems. I am using a Cobalt(III) complex containing a pentadentate polyamine ligand as a steric probe and docking various amino acids to the sixth position to calculate the strain energy. The problem is, when I dock a new amino acid to the probe, the atom type for the cobalt(III) probe changes from CO3 to CO2. Can any person tell me what is going wrong (if anything is going wrong) ? and how the problem can be rectified. All responses to: Mr. Chris Kladis Department of Environmental Management Victoria University of Technology Melbourne, Australia Email: s9250605@cougar.vut.edu.au _______________________________________________________________________________ From owner-hyperchem@hyper.com Wed May 29 10:17:31 1996 From: ps@ocisgi7.unizh.ch (Serge Pachkovsky) Subject: Re: large molecules To: polowin (Joel Polowin) Date: Wed, 29 May 1996 11:11:53 +0200 (MDT) Cc: hyperchem@hyper.com Hi, > > > Memory required = 2400 * NHA * (NHA - 1) + 440 * NHA * > > > HA + 24 * HA * (HA-1) bytes. > > > > Isn't that a tad too much, at least in the SCF case? The figure > > above means that 600 double precision words are stored for each > > pair of (non-hydrogen) atoms. Even if you choose to store derivative > > integrals (which is absolutely not necessary and is even harmful, since > > it decreases memory locality), you should have at most 3*(4*(4+1)/2)^2 > > = 300 double precision words for a pair of (non-hydrogen) atoms. > > As one of my colleagues just pointed out to me, 300 double precision words > = 2400 bytes, as above. (He also noted that the '440' above should be '480' 300 DP words is 2400 bytes true enough (at least, in the IEEE world ;-). However, this has nothing to do with my remark on memory usage, since MNDO and the ilk require 300 DP words for derivative two-electron integrals *per pair* of non-hydrogen atoms. Since there are only NHA*(NHA-1)/2 (note this /2!) pairs of non-hydrogen atoms, the expression above translates into *4800* bytes per atoms pair. I can imagine several reasons for this: a. The documentation is incorrect. This one is benign typo, but the code is still not quite as good as it can be, see below. b. The code fails to take into account translational invariance of the two-electron integral derivatives. This one can come in several shades: b.1) Translational invariance is ignored for the storage purposes, but is used properly during computation stage. b.2) Translational invariance is ignored throughout, which means that the derivatives are not only stored twice (modulo the sign), but are also computed twice, once by moving atom A and the second time by moving atom B for each integral (\mu_A\nu_A|\lambda_B\sigma_B). b.1 is marginally better than b.2 from the performance point of view, but both are very bad if you are memory limited (aren't you always memory limited on an PC?). c. The code does take translational invariance into account, but computes integrals derivatives by first evaluating *all* integrals for all possible displacements, and then dirrefentiating them numerically all at once. This is better than b.*, but is still very bad from the memory usage perspective. Since you (I mean HyperChem, not personally you ;-) are the owner of the source, you tell us which one of my guesses is right. > instead.) The above memory requirement is for storing the gradient; the > storage requirement for the SCF value itself is 1/3 of the above. Now, may be I had not made myself clear. *If* the density comes from the SCF computation (and hence "the SCF case"), the energy gradient is completely determined by the zero-order density. All the contributions from the derivatives of the two-electron integrals enter the energy derivatives as linear contractions with a density matrix, and can be evaluated *without* storing the derivative integrals. One can choose to use ordinary density matrix (thereby limiting himself to the SCF wavefunctions) or two-particle density matrix (which, in the MNDO case, has not much more significant elements than one-particle density) thus obtaining a general gradient procedure. However, the derivative integrals *never ever* need to be stored. In this sence, *any* non-constant additional memory requirements for the gradient of the SCF energy are bogus, and should be avoided. They are most certainly avoided in all generally used research codes (Mopac, Ampac, Thiel's & Cray Research's MNDO9X), and it is a disappointment to learn that HyperChem in effect imposes unnecessary restrictions on the size of the systems which can be studied with this excellent tool. Regards, /Serge.P P.S. Everything stated above is very much commonplace, but if you would like to see actual references (which are mostly to the 70-s and early 80-s), I would be obliged to furnish them. _______________________________________________________________________________ From owner-hyperchem@hyper.com Wed May 29 18:13:08 1996 Date: Wed, 29 May 96 12:43:43 -0400 From: polowin (Joel Polowin) To: Chris Kladis , hyperchem@hyper.com Subject: Re: Possible Stupid Question > Date: Wed, 29 May 1996 14:38:24 +1000 (EST) > From: Chris Kladis > > I am using HyperChem's MM+ force field to calculate Ligand Repulsion Energies > (LRE's) and I am having some problems. I am using a Cobalt(III) complex > containing a pentadentate polyamine ligand as a steric probe and docking > various amino acids to the sixth position to calculate the strain energy. > The problem is, when I dock a new amino acid to the probe, the atom type > for the cobalt(III) probe changes from CO3 to CO2. Can any person tell me > what is going wrong (if anything is going wrong) ? and how the problem can be > rectified. In the atom-type rules file CHEM.RUL, under "MM+", the only definition given is that "If the element is Co, the atom type is CO2". In the MM+ parameter files, the only parameters for either CO2 or CO3 are the non- bonded parameters in MMPNBD.TXT, and the same parameters are given for both. So any time you have a Co atom bonded to something else in an MM+ calculation, HyperChem will have to use its default scheme to determine parameters, and that doesn't depend on the atom type. Any time you do a model build or otherwise recalculate the atoms types, any Co atoms that you have will be given type CO2, but it doesn't make a difference anyways (unless you add your own parameters that distinguish between the types). If you would be more comfortable with HyperChem using type CO3, you just have to change the CHEM.RUL file -- just remove the ";" at the beginning of the line for CO3, and put one at the beginning of the line for CO2. Or you could get fancier and make up your own typing rules that would let HyperChem distinguish between the two cases. Joel ------------ Joel Polowin, Ph.D. Manager, Scientific Support Email to: polowin@hyper.com WWW: http://www.hyper.com/ Hypercube Inc, 419 Phillip St, Waterloo, Ont, Canada N2L 3X2 (519)725-4040 Info requests to: info@hyper.com Support questions to: support@hyper.com Email group: Send "subscribe hyperchem" (or "unsubscribe hyperchem") to hyperchem-request@hyper.com; please do not send such administrative messages to the group itself. _______________________________________________________________________________ From owner-hyperchem@hyper.com Wed May 29 19:02:32 1996 Date: Wed, 29 May 1996 16:57:27 +0100 (BST) From: Michael Hodgson To: hyperchem@hyper.com Subject: DNA simulations Hi... I am reletively new to the field of molecular modelling, but am trying to set up a simulation of an intercalator binding to B-DNA. Whilst many NMR studies have been done that utilise restrained MD, I have none for the system I'm trying to study. I am looking for advise on methods of simulating this system. Is it important to add explicit water molecules and/or counter ions? if counter ions are added how are they placed ?, and should they all be monovalent sodium type ions or should I attempt to use Mg etc too. if counter ions are not used to what degree and where exactly do I need to scale charges to represent there presence. Are there any other ways of simulating counter ions ? Also if the system is solvated with explicit waters, to what distance is sufficient to represent bulk solvent. My early attempts, seem to have the problem of too little solvent (solvating residues to 8A). Has anyone come up with a method of constraining a cylinder of water in which to carry out the simulation of DNA. I have heard that this is the case, but can't find a referance or any help anywhere. Is there an easy way of solvating things using Hyperchem ? Finally, I am looking for suggestions on how to actually evaluate binding energy, as it is not a simple concept. Can binding be represented simply by an interaction energy, or does desolvation etc need to be taken into account? With this in mind how would I go about doing this ? ,----- Michael Hodgson < mkh100@unix.york.ac.uk > ,----- | __/ | __/ l_F-< A_A_A,-mmmmm--=_ =---<==r==- l_F-< L \ _ _H_H_H_,-------|..|-,_,--| L \ r-i ) I I=L|==L<_ >L|: : : :|..|>|_<>:II r-i ) I \ " / H H H `-------|_ |-' `--' \ " / `---' U U U `---' (http://www.york.ac.uk/~mkh100) "I say we should listen to the customers and give them what they want." "What they want is better products for free." --Scott Adams _______________________________________________________________________________ From owner-hyperchem@hyper.com Wed May 29 19:55:32 1996 Date: Wed, 29 May 96 15:14:08 -0400 From: polowin (Joel Polowin) To: ps@ocisgi7.unizh.ch (Serge Pachkovsky) Subject: Re: large molecules Cc: hyperchem@hyper.com From: ps@ocisgi7.unizh.ch (Serge Pachkovsky) Date: Wed, 29 May 1996 11:11:53 +0200 (MDT) > > > Memory required = 2400 * NHA * (NHA - 1) + 440 * NHA * > > > HA + 24 * HA * (HA-1) bytes. > 300 DP words is 2400 bytes true enough (at least, in the IEEE world ;-). > However, this has nothing to do with my remark on memory usage, since MNDO > and the ilk require 300 DP words for derivative two-electron integrals > *per pair* of non-hydrogen atoms. Since there are only NHA*(NHA-1)/2 > (note this /2!) pairs of non-hydrogen atoms, the expression above translates > into *4800* bytes per atoms pair. I can imagine several reasons for this: I checked with one of my colleagues, who told me that the problem is not that HyperChem calculates integrals twice nor stores them twice, but that the code was originally designed for parallel processing. Since the current versions of HyperChem do not use parallel computing, some of these aspects have been removed over the years. There has been considerable optimization for speed, but not so much for memory usage, and the storage requirements are still those for the parallelized code. Re: derivatives, all the derivatives are calculated analytically, not numerically. He also comments: > > instead.) The above memory requirement is for storing the gradient; the > > storage requirement for the SCF value itself is 1/3 of the above. > Now, may be I had not made myself clear. *If* the density comes from the > SCF computation (and hence "the SCF case"), the energy gradient is completely > determined by the zero-order density. All the contributions from the > derivatives of the two-electron integrals enter the energy derivatives as > linear contractions with a density matrix, and can be evaluated *without* > storing the derivative integrals. One can choose to use ordinary density > matrix (thereby limiting himself to the SCF wavefunctions) or two-particle > density matrix (which, in the MNDO case, has not much more significant > elements than one-particle density) thus obtaining a general gradient > procedure. However, the derivative integrals *never ever* need to be > stored. This is absolutely right. We can calculate the derivatives of Coulomb integrals without storing them for computing the gradient. But it is difficult for the parallel version of HyperChem, because each node has only part of the density matrix. The density matrix elements have to be passed around all the nodes for gradient calculation. Thus HyperChem stores the derivatives of Coulomb integrals and reuses them when the current node gets another part of the density matrix from another node. If the memory requirment is a major problem, we will need to do something to clean up this aspect of our code. > In this sence, *any* non-constant additional memory requirements for the > gradient of the SCF energy are bogus, and should be avoided. They are most > certainly avoided in all generally used research codes (Mopac, Ampac, Thiel's > & Cray Research's MNDO9X), and it is a disappointment to learn that HyperChem > in effect imposes unnecessary restrictions on the size of the systems which can > be studied with this excellent tool. This is not true. MOPAC and AMPAC (at least the old versions) compute the gradient numerically, so they don't need extra memory to calculate gradient. However, you have to spend more time to wait for all the SCF calculations to be done. _______________________________________________________________________________ From owner-hyperchem@hyper.com Thu May 30 01:46:51 1996 Date: Wed, 29 May 1996 16:29:31 -0900 (PDT) From: Jerry To: hyperchem@hyper.com Subject: Help I am running hyperchem version 4 under windows-95 and I have just observed some interesting bonding on a peptide. To complete the peptide I ordered ADD HYDROGENS and when the command was complete the bonding was really unusual. There were three places where either a hydrogen or carbon had a valance that was impossable, a divalent hydrogen or a carbonyl with bonds to two carbons and a hydrogen bonded to yet another carbon. Has anyone else observed this problem or is my computer water impared in New Mexico? jlb _______________________________________________________________________________ From owner-hyperchem@hyper.com Thu May 30 07:58:43 1996 From: ps@ocisgi7.unizh.ch (Serge Pachkovsky) Subject: Re: large molecules To: polowin (Joel Polowin) Date: Thu, 30 May 1996 10:29:07 +0200 (MDT) Cc: hyperchem@hyper.com > > gradient of the SCF energy are bogus, and should be avoided. They are most > > certainly avoided in all generally used research codes (Mopac, Ampac, Thiel's > > & Cray Research's MNDO9X), and it is a disappointment to learn that HyperChem > This is not true. MOPAC and AMPAC (at least the old versions) compute > the gradient numerically, so they don't need extra memory to calculate This is most certainly true. Mopac (as of version 7. I *think* it was in place in version 6 as well, but I am not sure on this point) uses finite difference procedure to evaluate derivatives of the *integrals*. However, the rest of the procedure is essentially analytical, since: a. No SCF iterations are performed at the distorted geometries and b. Only pair contributions arising from the displacement of a single atom are recomputed for each component of the gradient. Concerning Ampac, I do not think the source of the latest version is publicly available, so it is sort of difficult to comment on that. However, since Dewar and Yamaguchi do have a 1978 publication on implementation of analytical derivatives of energy in Ampac (which includes fully analytical expressions for ERI cartesian derivatives), I would be really surprised if they had dropped it later on. Concerning Thiel's MNDO9X (which is also included in Cray Research's UniChem), I can assure you that it does compute geometric derivatives of the SCF energy analytically. Both numerical differentiation of the ERIs and analytical expressions for those can be used. The results (both the computed values and execution times) are essentially equivalent in both cases. (*) > gradient. However, you have to spend more time to wait for all the SCF > calculations to be done. Please, please! You might be able to pull the trick of comparing Mopac 3 (which is more than ten years old) to your current version of HyperChem while talking to corporate executive types, but most of the audience on this list is none of the sort. *No* current semiempirical code does an SCF computations at the distorted geometry. In the worst case, the Fock matrix might be completely recomputed for each displaced geometry in the numeric differentiation, rather than just updated (thus making the whole derivative evaluation O(N^3) instead of O(N^2)), but this is still a far cry from the O(N^4) case (which results from performing an SCF at each displaced geometry) seen in the early semiempirical codes. Regards, /Serge.P (*) "Essentially equivalent" stands for the difference in the computed gradient less than 10^-7 kcal/mol/angstrom and execution times differing by less than 20%. _______________________________________________________________________________ From owner-hyperchem@hyper.com Thu May 30 14:39:59 1996 Date: 30 May 96 04:10:05 From: "Dr. Jack Isidor" Subject: Re: large molecules To: "Serge Pachkovsky" Cc: polowin, hyperchem@hyper.com Serge and Joel, could we all please get real. I presume that there are very few users of HyperChem who consider it to be a "top-of-the-line" computational tool. HyperChem gets a lot out of the limited capabilities of today's inexpensive desktop PC's, but it is being increasingly misused and mis-marketed (the two are undoubtedly related). In moving from the PC to the SGI workstation, the software should have been completely redesigned and marketed separately from the PC version. HyperChem is, and should remain as a very good desktop/PC tool for those of us who are able to restrict modelling to small systems, and who are primarily interested in what might be called "exploratory" modelling. In addition, as many of us have discovered, HyperChem is an exceptionally usefull tool for teaching many aspects of chemistry, particularly computational chemistry. While the "freindly" discussion about the limitations of HyperChem was occassionally interesting, it was a bit like listening to someone complain about the lack of acceleration of a Toyota Corolla. The Corolla is a great car, but no one buys it for racing. _______________________________________________________________________________ From owner-hyperchem@hyper.com Thu May 30 16:32:36 1996 Date: Thu, 30 May 96 12:53:13 -0400 From: polowin (Joel Polowin) To: Jerry Subject: Re: Help Cc: hyperchem@hyper.com > Date: Wed, 29 May 1996 16:29:31 -0900 (PDT) > From: Jerry > > I am running hyperchem version 4 under windows-95 and I have just > observed some interesting bonding on a peptide. To complete the peptide > I ordered ADD HYDROGENS and when the command was complete the bonding > was really unusual. There were three places where either a hydrogen or > carbon had a valance that was impossable, a divalent hydrogen or a > carbonyl with bonds to two carbons and a hydrogen bonded to yet another > carbon. There appears to be a bug in the "Add Hydrogens" routine. Everything is fine if all atoms have less than or equal to their normal numbers of attachments, but there is an error if one or more atoms have more connections than they should. The residues HIP, HIS, HIE, HID, ARG, and TRP all have aromatic nitrogens with additional bonds to H; the residues CYS, CYX, and MET have sulfur atoms with attached lone pairs. If I run "Add Hydrogens" on a protein that has one "extra connection", the hydrogens are added correctly to the terminal residues to complete their valences, but the status line reports that only one H was added even though two were. If I run "Add Hydrogens" on a protein that has two or more "extra connections", the terminal residues get the extra H atoms, but both H atoms are placed at the centre of mass of the protein (on top of each other) with long bonds to the atoms they are attached to; the status line reports that no hydrogens were added. If I select the system but unselect the atoms with "extra connections", "Add Hydrogens" produces the correct result. This goes into the bug list... Joel ------------ Joel Polowin, Ph.D. Manager, Scientific Support Email to: polowin@hyper.com WWW: http://www.hyper.com/ Hypercube Inc, 419 Phillip St, Waterloo, Ont, Canada N2L 3X2 (519)725-4040 Info requests to: info@hyper.com Support questions to: support@hyper.com Email group: Send "subscribe hyperchem" (or "unsubscribe hyperchem") to hyperchem-request@hyper.com; please do not send such administrative messages to the group itself. _______________________________________________________________________________ From owner-hyperchem@hyper.com Fri May 31 14:26:23 1996 From: "Thomas Futterer" To: hyperchem@hyper.com Date: Fri, 31 May 1996 15:50:00 +100 Subject: print to file (SGI Re. 4.5) Dear HyperChem users and developer, i`m preparing a poster with some rgb-graphicfiles printed with Hyperchem (Re. 4.5 for SGI) under the the option PRINT TO FILE. The type of rendering is Ball and Sticks. After zooming these graphics to a suitable size for my poster, the resolution gets worse. So my question is, if there is any (easy, quick and cheap) possibility to get a better output for printing. thanks for reading Thomas _________________________________________________ Thomas Futterer AK Prof.Dr.A.Merz Universitaetsstrasse 31 93053 Regensburg Germany Tel: 0/941/9434633 Fax: 0/941/9434505 __________________________________________________ _______________________________________________________________________________ From owner-hyperchem@hyper.com Fri May 31 17:01:28 1996 Date: Fri, 31 May 1996 11:23:41 -0500 From: Maciej Tasz Subject: Windows95 and hardware lock To: hyperchem@hyper.com Organization: Marquette University Dear Hyperchem users: We have just upgraded from a standalone 4.0 version to a network 4.5 version of Hyperchem. It was installed under Windows 95, which we use for networking. Unfortunately, the users installations cannot find the network license. Could anybody help us to configure the server so that clients could get the license? The manual does not mention anything about Windows 95 and our Autoexec.bat file does not contain anything similar to what is described there. Thanks for reading Maciej K. Tasz, Ph.D. Marquette University Chemistry Department _______________________________________________________________________________ From polowin Fri May 31 18:46:48 1996 Date: Fri, 31 May 96 15:17:55 -0400 From: polowin (Joel Polowin) To: Maciej Tasz Subject: Re: Windows95 and hardware lock Cc: hyperchem@hyper.com > Date: Fri, 31 May 1996 11:23:41 -0500 > From: Maciej Tasz > > We have just upgraded from a standalone 4.0 version to a network 4.5 version of Hyperchem. > It was installed under Windows 95, which we use for networking. Unfortunately, the users > installations cannot find the network license. Could anybody help us to configure the server > so that clients could get the license? The manual does not mention anything about Windows 95 > and our Autoexec.bat file does not contain anything similar to what is described there. The driver that you need to use is NSRVGX.EXE, and all that you should need to do is to run that driver in an MS-DOS shell in Windows 95. The network administrator's manual was written before Win'95 came out, and it probably should be updated. If you have just got the upgrade, you should have the current version of the drivers. If not, the current version is available from our ftp site as: ftp://www.hyper.com/support/newnet.exe (for license servers other than NT) ftp://www.hyper.com/support/nsrvgx.exe for a Win NT license server You may also find that the network setup guide that Rainbow wrote will help you. I am not sure that it is designed for the same version of the drivers as what we are using, but the general principles should be the same. You can get it as: ftp://www.hyper.com/support/ns_guide.exe Joel ------------ Joel Polowin, Ph.D. Manager, Scientific Support Email to: polowin@hyper.com WWW: http://www.hyper.com/ Hypercube Inc, 419 Phillip St, Waterloo, Ont, Canada N2L 3X2 (519)725-4040 Info requests to: info@hyper.com Support questions to: support@hyper.com Email group: Send "subscribe hyperchem" (or "unsubscribe hyperchem") to hyperchem-request@hyper.com; please do not send such administrative messages to the group itself. _______________________________________________________________________________ From owner-hyperchem@hyper.com Fri May 31 18:50:06 1996 Date: Fri, 31 May 96 14:53:47 -0400 From: polowin (Joel Polowin) To: "Thomas Futterer" , hyperchem@hyper.com Subject: Re: print to file (SGI Re. 4.5) > From: "Thomas Futterer" > Date: Fri, 31 May 1996 15:50:00 +100 > > i`m preparing a poster with some rgb-graphicfiles printed with > Hyperchem (Re. 4.5 for SGI) under the the option PRINT TO FILE. > The type of rendering is Ball and Sticks. > > After zooming these graphics to a suitable size for my poster, the > resolution gets worse. So my question is, if there is any (easy, quick > and cheap) possibility to get a better output for printing. With HyperChem for SGI printing only sticks, you can save the picture in a PostScript format, which prints at the printer resolution. (This is like getting a Windows Metafile picture with HyperChem for Windows.) But for the other modes, all that you can get is the pixel-based RGB format (like getting a BMP picture from Windows). For the pixel-based formats, the only way of getting finer resolution is to make the window as large as possible so that the picture has the largest possible size in pixels. Apart from that, all that I can think of is to use graphics software to expand the image. I have used Jef Poskanzer's freeware PBMPLUS package for image manipulation, and I like it. I had little trouble installing it, and its tools work well. According to the SGI man page for 'toppm', The latest version is always available via anonymous FTP as expo.lcs.mit.edu:contrib/pbmplus.tar.Z and ftp.ee.lbl.gov:pbmplus.tar.Z Joel ------------ Joel Polowin, Ph.D. Manager, Scientific Support Email to: polowin@hyper.com WWW: http://www.hyper.com/ Hypercube Inc, 419 Phillip St, Waterloo, Ont, Canada N2L 3X2 (519)725-4040 Info requests to: info@hyper.com Support questions to: support@hyper.com Email group: Send "subscribe hyperchem" (or "unsubscribe hyperchem") to hyperchem-request@hyper.com; please do not send such administrative messages to the group itself. _______________________________________________________________________________ From owner-hyperchem@hyper.com Fri May 31 19:31:50 1996 Date: Fri, 31 May 96 17:07:25 -0400 From: polowin (Joel Polowin) To: Michael Hodgson , hyperchem@hyper.com Subject: Re: DNA simulations > Date: Wed, 29 May 1996 16:57:27 +0100 (BST) > From: Michael Hodgson > > Also if the system is solvated with explicit waters, to what distance is > sufficient to represent bulk solvent. My early attempts, seem to have > the problem of too little solvent (solvating residues to 8A). Has anyone > come up with a method of constraining a cylinder of water in which to > carry out the simulation of DNA. I have heard that this is the case, but > can't find a referance or any help anywhere. Is there an easy way of > solvating things using Hyperchem ? It's simple enough to solvate a system in a rectangular prism in HyperChem -- that's what the "solvent box" is all about. I do not know of any good way of constraining a cylinder. The best method that I can think of would be to set up such a system, and then select all of the molecules except the solvent molecules at the surface of the cylinder. If you then run a geometry optimisation or molecular dynamics, the unselected molecules will remain fixed in space, and so will act to contain the molecules inside the cylinder. I don't know enough about MD on proteins to make useful suggestions about your other questions re: counter-ions, desolvation and binding energy, etc. Perhaps someone else on the list who is more familiar with these matters can advise. Joel ------------ Joel Polowin, Ph.D. Manager, Scientific Support Email to: polowin@hyper.com WWW: http://www.hyper.com/ Hypercube Inc, 419 Phillip St, Waterloo, Ont, Canada N2L 3X2 (519)725-4040 Info requests to: info@hyper.com Support questions to: support@hyper.com Email group: Send "subscribe hyperchem" (or "unsubscribe hyperchem") to hyperchem-request@hyper.com; please do not send such administrative messages to the group itself. _______________________________________________________________________________ From owner-hyperchem@hyper.com Fri May 31 21:35:20 1996 Date: Sat, 1 Jun 1996 01:05:18 +0100 (BST) From: Michael Hodgson To: Thomas Futterer Cc: hyperchem@hyper.com Subject: Re: print to file (SGI Re. 4.5) > > i`m preparing a poster with some rgb-graphicfiles printed with > Hyperchem (Re. 4.5 for SGI) under the the option PRINT TO FILE. > The type of rendering is Ball and Sticks. > I haven't actually tryed this on an SGI version, but if you make the screen image as large as possible and then take a snapshot of it (using snapshot on an SGI) you will end up with an RGB file at screen resolution. This is normally far higher than printer resolution, so you will be able to scale the RGB, rather than the graphics to fit your poster. If you want to produce higher quality outputs than your printer can manage you may want to consider getting your pictures photographed. If you use the command slide *.rgb, it will scale the rgb to fill the screen as best it can, on a black background. This can then be photographed. Some Labs may offer this service to you if you don't have facilities to do it yourself. > After zooming these graphics to a suitable size for my poster, the > resolution gets worse. So my question is, if there is any (easy, quick > and cheap) possibility to get a better output for printing. > In summary make the RGB from as big an image as possible and scale that RGB. -Michael Hodgson