From omar@crs4.it Fri Jul 16 12:31:59 1993 Message-Id: <9307160831.AA25225@malena.crs4.it> To: chemistry@ccl.net Subject: Re: Link_prg_with_GAUSSIAN_subr Date: Fri, 16 Jul 1993 10:31:59 +0200 From: "Omar G. Stradella" Your message dated: Thu, 15 Jul 1993 16:23:18 BST > >I have a problem with GAUSSIAN 92. >I write a little program for my use ( ict.f ) which calls the >GAUSSIAN routine 'ZtoC' in util.a . >I build executable like this: > ># xlf -oict.exe ict.f util.a > >Computer answers: > ># xlf -oict.exe ict.f util.a >** ict === End of Compilation 1 === >1501-510 Compilation successful for file ict.f. >0706-317 ERROR: Unresolved or undefined symbols detected: > Symbols in error (followed by references) are > dumped to the load map. > The -bloadmap: option will create a load map. >.ztoc ># > >What is wrong ? Paolo, If you look at the library symbol table: $ ar w /u/eduardo/g90/src/util.a | grep ztoc .ztoc_ ztoc.o ztoc_ ztoc.o you see that the name of the symbol is ztoc_ and not ztoc. So in your FORTRAN program you have to include the underscore: call ztoc_(......) Ciao e buon lavoro. Omar. -- **************************************************************************** * Dr. Omar G. Stradella - Omar.Stradella@crs4.it * * CRS4 - Centro di Ricerca, Sviluppo e Studi Superiori in Sardegna * * - Centre for Advanced Studies, Research and Development in Sardinia * * -------------------------+----------------------------+----------------- * * Casella Postale 488 | Via Nazario Sauro, 10 | 39 13' 19" North * * 09100 Cagliari CA | 09123 Cagliari CA | 9 6' 17" East * * Italy | Italy | * * -------------------------+----------------------------+----------------- * * Phone: +39 70 27 96 415 FAX: +39 70 27 96 400 or +39 70 24 10 18 * **************************************************************************** From omar@crs4.it Fri Jul 16 12:44:17 1993 Message-Id: <9307160844.AA27891@malena.crs4.it> To: chemistry@ccl.net Subject: Re: Link_prg_with_GAUSSIAN_subr Date: Fri, 16 Jul 1993 10:44:17 +0200 From: "Omar G. Stradella" Your message dated: Thu, 15 Jul 1993 12:54:30 PDT >Paolo: > >You don't want to just put util.a on the command line. Try compiling by >doing: That's not true. Look at the information of the "ld" command, which is the one that actually processes libraries and such. > >xlf -oict.exe -L/usr/local/g92/util -l util.a ict.f > >You will want to replace /usr/local/g92/util with the path to the util.a >library on your system. I hope this helps. > This will only try to access a library called "libutil.a" in the default directories or in /usr/local/g92/util. The "-l" flag always prepends "lib" to the name of the specified library. So the correct syntax is still xlf -oict.exe ict.f /usr/local/g92/util/util.a but the name of the routine is ztoc_ and not ztoc. Omar. -- **************************************************************************** * Dr. Omar G. Stradella - Omar.Stradella@crs4.it * * CRS4 - Centro di Ricerca, Sviluppo e Studi Superiori in Sardegna * * - Centre for Advanced Studies, Research and Development in Sardinia * * -------------------------+----------------------------+----------------- * * Casella Postale 488 | Via Nazario Sauro, 10 | 39 13' 19" North * * 09100 Cagliari CA | 09123 Cagliari CA | 9 6' 17" East * * Italy | Italy | * * -------------------------+----------------------------+----------------- * * Phone: +39 70 27 96 415 FAX: +39 70 27 96 400 or +39 70 24 10 18 * **************************************************************************** From grzesb@asp.biogeo.uw.edu.pl Fri Jul 16 13:47:20 1993 Date: Fri, 16 Jul 93 11:47:20 +0200 From: grzesb@asp.biogeo.uw.edu.pl (Grzegorz Bakalarski) Message-Id: <9307160947.AA03609@asp.biogeo.uw.edu.pl> To: CHEMISTRY@ccl.net Subject: spin contamination and dissociation Organization: Dept. of Biophys., Warsaw University Dear Netters, After few days of discussion on "What is the best: IBM or SGI" I would like to ask more chemical ( and maybe naive) question. Recently I have tested new product of BIOSYM using DFT method DMOL v2.3. Especially I have been interested in nonlocal corrections and how they work ( options: B88, Lyp) and I've also tested local hamiltonians( JMW, VWN). I've tried to compute potential energy curve for dissociation of simple molecules (e.g. N2 or CH4). In fact I've followed procedure described in J. Phys. Chem., 1993,97,4664-4669. I have found that results for region 0.9A - 1.5A are quit good and comparable to those obtained from DGauss program). But in the region 1.5A - 3.A the curves don't look nice. For nonlocal correlation correction (Lyp) curves don't seem to tend to correct limit in infinity. In article I have cited authors write:" ... restricted HF reference wave functions tend to converge to the wrong energy limit. (...) unrestricted wave functions suffer from a spin contamination ." The question is: What is a spin contamination ? What is it's origin ? Do all quantum mechanical programs ( ab initio, semi_empirical, DFT) suffer from it ? Later authors write: " ... calculations have been performed using a spin restricted, standard approach, which leads to delocalized spin densities. The localization of spin densities has been achieved by performing spin-polarized ( unrestricted) calculations .... ." What means " spin-polarized" calculations ? Is this formally correct to keep spin during dissociation ? Any comments, suggestion, explanations are welcome !! Best regards grzesb@asp.biogeo.uw.edu.pl (Grzegorz Bakalarski) PS. Please, DO NOT use REPLAY to answer. If I get any replies I'll put summary to the NET. From singer@aluminum.mps.ohio-state.edu Fri Jul 16 04:43:25 1993 Date: Fri, 16 Jul 93 08:43:25 -0400 From: singer Message-Id: <9307161243.AA01133@aluminum.mps.ohio-state.edu> To: CHEMISTRY@ccl.net Subject: IBM vs SGI vs HP vs ....... Since comparison's between different workstations is a current topic of this group, I would appreciate hearing other people's experience with workstation performance in a multiuser environment. In particular, the interactive response of our IBM RS/6000 350 (64MB memory) is quite poor when there is more than one user running a memory intensive job. As a consequence, we have not taken full advantage of IBM software (such as the workbench/softbench environment) which involves interactive tasks like editing. Interactive response degrades when another X-application, batch job, etc... starts. Our SPARCs are not as fast and do not have as much memory as the IBM, but they seem to cope this type of load much better than the RS/6000. The floating point performance of the RS/6000 has been very satisfactory. Any similar experiences, comparisons with HP or other vendors? --- Sherwin Singer internet: singer@mps.ohio-state.edu Department of Chemistry bitnet: singer@ohstpy Ohio State University (614)292-8909 FAX: (614)292-1685 From mercie@cumc.cornell.edu Fri Jul 16 05:07:09 1993 Date: Fri, 16 Jul 1993 09:07:09 -0400 (EDT) From: Gustavo Mercier Subject: adf on SGI To: chemistry@ccl.net Message-Id: Hi, Netters! Has anyone implemented ADF (Amsterdam Density Functional Package v. 1.0.1) on an SGI, preferably INDIGO R4000 ELAN running IRIX 4.0.5F? Their standard installation with their sgi settings file works, but at run time their H2O optimization examples generates a Memory Fault during the first steps of the optimization. The generation of the "fragments", ie. runs on the atoms H and O, worked well. Reducing the workspace and other arrays such as number of atoms, basisfunctions etc. did not solve the problem. Also, no optimization was used in compiling/linking the programs (i.e. option -O0). I've contact them about this problem, but it will be a few days before they have access to an SGI machine. I will ultimately port the program to a CONVEX, so any hints/potential problems that anybody may have are also welcomed. thanks gus mercier mercie@cumc.cornell.edu (notice the absence of the last "r" from my name!) From dan@omega.chem.yale.edu Fri Jul 16 05:58:10 1993 From: Dan Severance Message-Id: <9307161358.AA05907@omega.chem.yale.edu> Subject: SGI compiler options To: chemistry@ccl.net Date: Fri, 16 Jul 93 9:58:10 EDT Organization: Laboratory for Computational Chemistry Hi all, I don't want to labor this, but replies I've received indicate that many people don't know about some important compiler options for the SGI machines. Given the large percentage of this audience using them, I thought I'd comment. If you have an R4000 or R4400 machine, you need to add the "-mips2" option, since "-mips1" is the default (compatibility mode, will run on both R3000 and R4000 machines). (The fast square-root is incorporated when you specify -mips2) Our code is 1.5x faster when compiled with the -mips2 flag! R4x00: f77 -O3 -mips2 [-sopt,options] boss34.f -o BOSS34 For R3000 machines, if you do any square roots (our code spends 30% of it's time doing them), use the libfastm.a which has a fast square-root: (DecStations using MIPS chips might have libfastm.a as well) R3x00 f77 -O3 [-sopt,options] boss34.f -o BOSS34 -lfastm Another compiler option (fairly new) to try is the -sopt, and is documented in the f77 man page, and under the "fopt" manpage (-sopt runs the program fopt). One user got a 40% speedup, we don't; it depends on your code. I realize it's not chemistry, per se, but one user told me that his code was so much faster now (that they use the -mips2 flag) that they are able to run much larger systems than they could have before. That IS chemistry. Happy crunching! Dan From bak@isadora.albany.edu Fri Jul 16 06:41:16 1993 From: bak@isadora.albany.edu (Brian A. Kell) Message-Id: <9307161441.AA21441@isadora.albany.edu> Subject: Re: Tektronik Emulator To: davide@stinch6.csrsrc.mi.cnr.it Date: Fri, 16 Jul 93 10:41:16 EDT Davide Proserpio writes: > > I am looking for commercial and/or public domain programs to emulate a tektron > ik terminal on a PC and on SiliconGraphics. I have hear about EMU-TEK. I don't know about a PC, but on an SGI (and most other X-windows machines), the xterm includes tek emulation. In a shell window, type "xterm &". When the new window opens up, hold down the control key and click any mousse button inside the xterm window to get to the xterm options. See `man xterm` for more details. ------------------------------------------------------------------ Brian A. Kell Applications Support Specialist bak@biosym.com (518) 356-7934 Biosym Technologies, Inc. ------------------------------------------------------------------ From system@alchemy.chem.utoronto.ca Fri Jul 16 06:50:43 1993 Date: Fri, 16 Jul 93 10:50:43 -0400 From: system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) Message-Id: <9307161450.AA14168@alchemy.chem.utoronto.ca> To: chemistry@ccl.net Subject: Re: IBM vs SGI vs HP Slawomir Blonski wrote about some timings: > >HP 9000/750 >54.1u 0.2s 1:48 50% > >SGI Indigo 2 (100 MHz, 32 MB) >78.6u 14.4s 1:34 98% > >IBM RS/6000 550 (64 MB) >112.7u 0.50s 1:55 97% 155+1829k 0+0io 93pf+0w This topic has been discussed in the comp.benchmarks USENET news group, with the apparent result that the IBM machines seem to have a very slow floating point divide, and some examples were posted where the percentage of divides in a benchmark mix would cause the rating of the IBM to vary by over a factor of 2 (all workstations improved as the percentage of divides was lowered, but none as dramatically as the IBM). The lesson is: don't do divides if you can avoid it -- so X * 0.5d0 is much better than X / 2.0d0 if you are doing lots of them. Here are some more general comments, but beware that the vendors are improving their hardware and compilers frequently, so things may be different on the latest releases. The balance between integer and floating point speed can vary a lot between vendors, with Sun being an integer system, and the HP/IBMs doing very fast fp (in simple terms). I can't place the newest SGI Indigo 2 or DEC Alpha systems on my scale since I have no experience with them, but SGI had been falling behind in the fp race with the basic R4000. The percentage of fp in your program can make quite a difference - for G92 stuff, the impression is that the IBM is "fastest", with HP close, but for things like cellular automata (mainly integer) the SGI has been found to do a very good job given the cost/clock speed (I hesitate to use clock speed since systems like the DEC Alpha came on the scene). Something very common in computational chemistry is X ** N, where N is often an integer known at compile time - some machines invoke the ln/exp routines if N happens to contain a decimal point (X ** 2. instead of X ** 2), and others call a subroutine to deal with it. You are MUCH better to do the power operation yourself, and if N is 6 and/or 12, do something like x2 = x * x x6 = x2 * x2 * x2 x12 = x6 * x6 Never do square roots as X ** 0.5d0, since most machines now have hardware square root, so the compiler will use that directly for sqrt(X). Some compilers recognize these constructions and do the fastest operations, others don't (and it can be optimization level dependent). If you are doing work in single precision, note that the IBM does all computation internally in double precision unless you tell the compiler not to - this will slow your program, but your intermediate results have 64 bits, not 32, so you may have more accuracy/precision until you store into memory. If you are using complex arithmetic on the HP, note that the complex divide is implemented in the simplistic way which causes trouble if either the real or imaginary components of the denominator exceed the square root of the maximum/minimum real number in whatever precision you are using. All other machines I have tested do a proper scaling before complex division, which costs an couple of extra operations, and will make the HP look better. This is not corrected in the 9.01 release (it was reported too late). If your code comes near the limits of machine representation of numbers, you may start using un-normalized floating point numbers, which may slow your cpu, and/or start causing floating point exceptions which will force the operating system to become involved. This will convert your 20 Mflop system to a .2 Mflop system for those operations. Systems that suddenly give 0 instead of un-normalized numbers will gain advantage, at the expense of accuracy. As mentioned by another posting, the IBMs also have small caches compared with HP and SGI, which can also affect timings, especially on codes designed to be "cache busters". Cache design can also affect this (HP's is fairly simple, and therefore can be bigger for the same $$), and you need to explore compiler options (like "+OPn" on the HP) which will preprocess the source looking for vectorizable loops, BLAS routines that can be substituted, etc. Mike. From fant@hungryjoe.plk.af.mil Fri Jul 16 05:56:30 1993 From: fant@hungryjoe.plk.af.mil (Andrew Fant) Message-Id: <9307161856.AA21345@hungryjoe.plk.af.mil> Subject: A collection of queries To: chemistry@ccl.net Date: Fri, 16 Jul 1993 12:56:30 -0700 (MDT) Hello All: I have a few questions that I have been storing up and I thought I would dump them to the list all at once to save bandwidth, etc. 1) What is the most cost-effective way for a single independent researcher to access STN or CAS online for occasional searching (1 or 2 times a month)? I would have to pay this on my own nickel, so cost is the primary consideration. 2) Has anyone got any X or postscript based code that will generate MO energy level diagrams (such as for a correlation diagram) given a listing of the energy levels and their degeneracy? I am going to be giving a presentation (hopefully) that requires a lot of these, and I am not much of a draftsman. 3) Does anyone have any insights into using the IBM3090 for computational chemistry or other numbercrunching applications? I know that G92 and gamess are available for it, but I am also interested in the issues that typical users face when either getting used to MVS/TSO, or using RJE environments. Thanks in advance for any insight on any of these problems. On a different note, I am planning to attend the Southwestern Regional ACS meeting in Austin this fall, and I am wondering if any other comp-chem list readers will be there. It might be nice to meet the faces behind some of the names. Anyway, thanks for any information you have. Andy Andrew D. Fant Computational Chemistry Systems Analyst TAI/UTS PLSC-Kirtland AFB fant@hungryjoe.plk.af.mil (505)266-1957 Humiston's Law: When you are surrounded by alligators, it is hard to remember your original intention was to drain the swamp. From symersky@extreme.bio.cornell.edu Fri Jul 16 12:55:09 1993 Date: Fri, 16 Jul 93 16:55:09 -0400 From: symersky@extreme.bio.cornell.edu (Jindrich Symersky) Message-Id: <9307162055.AA13157@extreme.bio.cornell.edu> To: chemistry@ccl.net Subject: calculation of pK's Hello netters, I would be interested in getting information about programs to calculate pK's of small molecules. I am willing to summarize the responses and post it so that everyone can get an update on this subject (this is assuming I get an answer...) Jindrich Symersky symersky@extreme.bio.cornell.edu From shenkin@still3.chem.columbia.edu Fri Jul 16 14:19:47 1993 Date: Fri, 16 Jul 93 18:19:47 -0400 From: shenkin@still3.chem.columbia.edu (Peter Shenkin) Message-Id: <9307162219.AA03593@still3.chem.columbia.edu> To: CHEMISTRY@ccl.net, singer@mps.ohio-state.edu Subject: Re: IBM vs SGI vs HP vs ....... This is just anecdotal, but the IBM RISC machines seem to require far more real memory than SGI's do to obtain the same degree of interactive performance with the same background load (eg, a load factor of 2 or 3). On most UNIXes, including SGI, and I presume IBM (but it has to be a presumption, since I don't know AIX very well), there are kernel variables that one can tweak to adjust the relative priorities of interactive and background jobs. I don't know whether the differences I see are due to different ways in which the respective manufacturers set these parameters by default, or whether they are due to more fundamental factors, such as bus, CPU or OS design. -P. ************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb************************ Peter S. Shenkin, Box 768 Havemeyer Hall, Dept. of Chemistry, Columbia Univ., New York, NY 10027; shenkin@still3.chem.columbia.edu; (212) 854-5143 ********************** Wagner, Beame, Screvane in '93! ********************** From CMPARRYDE@VAX.SWANSEA.AC.UK Fri Jul 16 15:01:00 1993 Date: Fri, 16 Jul 1993 15:01 +0000 (GMT) From: CMPARRYDE@vax.swan.ac.uk Subject: Conference in Great Britain in September To: CHEMISTRY@ccl.net Message-Id: <01H0MIJXCBW29H4BC7@phem3.acs.ohio-state.edu> ************************************** 26th. Annual QUANTUM THEORY CONFERENCE University of Wales, Swansea, UK. 20-23 September 1993 ************************************** This conference series provides a forum for advances in research into the theoretical chemistry, theoretical physics and mathematics of molecular structure and phenomena; there is little restriction on topics - the most popular is electronic structure. Both oral presentations and posters are invited. If you wish to give an oral presentation PLEASE ACT NOW as the programme is filling up quickly; the suggested length is 30 minutes including discussion. The fee is 20 pounds (10 pounds for bona fide graduate students). Dinner, bed and breakfast costs 32.30 pounds per day, so the all-in charge is 116.90 pounds for the 3 days of the meeting (pro rata for shorter stays) which includes the conference dinner. There are direct trains from London to Swansea ( < 3 hours ). CONTACT: Dr.D.E.Parry, Quantum Theory Conference, Department of Chemistry, University of Wales, Swansea Singleton Park, Swansea. SA2 8PP U.K. TELEPHONE: +44 792 295276 FAX: +44 792 295747 E-MAIL: d.e.parry@swansea.ac.uk Closing date for receipt of registrations: 20 August 1993. ************************************** COMPUTER INFORMATION BOARD for the conference. You may call VAX.SWAN.AC.UK (Internet address 137.44.1.2) and login to username CMQTCONF with password NUMBER26. This has a registration pro-forma and up-to-date details of talks, posters, delegates, travel and the venue. It is possible to e-mail the information files back to your account. E-mail sent to CMQTCONF will be rerouted to me. David Parry.