From Foreman@cardiff.ac.uk Fri Nov 22 05:48:29 1996 Received: from stork.cf.ac.uk for Foreman@cardiff.ac.uk by www.ccl.net (8.8.3/950822.1) id FAA22642; Fri, 22 Nov 1996 05:31:23 -0500 (EST) Received: from main2s.cf.ac.uk by stork.cf.ac.uk with SMTP (PP); Fri, 22 Nov 1996 10:28:48 +0000 Received: from MAIN2S/MAILQUEUE by main2s.cf.ac.uk (Mercury 1.21); 22 Nov 96 10:30:18 GMT Received: from MAILQUEUE by MAIN2S (Mercury 1.21); 22 Nov 96 10:22:06 GMT From: Joely To: chemistry@www.ccl.net Date: Fri, 22 Nov 1996 10:22:00 GMT Subject: CADPAC 6.0 on RS6000 or DEC Alpha Priority: normal X-mailer: Pegasus Mail for Windows (v2.33) Message-ID: Dear CCL, I was wondering if anyone out there has compiled CADPAC 6.0 on a DEC Alpha or RS6000 workstation. I have had problems doing so and would appreciate any help that you could give. Cheers Joel ----------------------------------------------------------- Joel Foreman University of Wales, Cardiff Cardiff Wales foreman@cf.ac.uk CF1 3TB tel: +44(01222)874950 U.K. fax: +44(01222)874029 ----------------------------------------------------------- From ps@ocisgi7.unizh.ch Fri Nov 22 06:04:42 1996 Received: from rzusuntk.unizh.ch for ps@ocisgi7.unizh.ch by www.ccl.net (8.8.3/950822.1) id FAA22692; Fri, 22 Nov 1996 05:46:37 -0500 (EST) Received: from ocisgi7.unizh.ch by rzusuntk.unizh.ch (4.1/SMI-4.1.14) id AA16140; Fri, 22 Nov 96 11:46:37 +0100 Received: by ocisgi7.unizh.ch (950215.SGI.8.6.10/920502.SGI) id LAA14534; Fri, 22 Nov 1996 11:09:21 +0100 From: ps@ocisgi7.unizh.ch (Serge Pachkovsky) Message-Id: <199611221009.LAA14534@ocisgi7.unizh.ch> Subject: Re: CCL:F77 compiler on R10000 SGI Indigo2: buggy? To: robert@pauli.utmb.edu (Robert Fraczkiewicz) Date: Fri, 22 Nov 1996 11:09:20 +0100 (MET) Cc: CHEMISTRY@www.ccl.net In-Reply-To: <9611211428.ZM3754@pauli.utmb.edu> from "Robert Fraczkiewicz" at Nov 21, 96 02:28:44 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, > 1) f77 silly.f -o silly (this produces 32-bit mips2 code by default) > 2) f77 -O2 silly.f -o silly > 3) f77 -64 silly.f -o silly (this produces 64-bit mips4 code) > 4) f77 -64 -O2 silly.f -o silly > 5) f77 -64 -O3 silly.f -o silly > The unusual results I have obtained are shown in table below. Apart > from the fact that the 64-bit executables produce slightly different > result for x than their 32-bit counterparts, the CPU times in column > 4) are larger by a factor of TEN in comparison to other columns! > Normally, I would expect them to be in between 3) and 5). This abnormal This is a known bug in vanilla 6.2 f77. It is *not* actually a bug in Fortran compiler per se, but rather an unexpected interaction of new dynamic linking convenstions and compiler optimizations. Here is that happens: A bit of background: any program you compile with default options on IRIX (on any modern unix, for that matter) is *not* standalone. Some of the subroutines have to come from dynamic libraries (or Dynamic Shared Objects, a.k.a. DSO) at run time. In this particular case, your program has references to three dynamic libraries: 31> elfdump -Dl silly silly: **** MIPS LIBLIST INFORMATION **** .liblist : [INDEX] Timestamp Checksum Flags Name Version [1] Mar 9 13:20:05 1996 0x51f6ec32 ----- libftn.so sgi1.0 [2] Mar 9 13:16:12 1996 0xdfaae999 ----- libm.so sgi1.0 [3] Mar 9 18:58:37 1996 0x1f457b4c ----- libc.so.1 sgi1.0 The actual symbol resolution happens at run time and is performed by a run-time linker, rld (there is a nice man page on rld on your IRIX box, read it - it is a good reading if you plan to use your system effectively. While you are at it, you might also read manual page on DSOs). All the references (either subroutine calls or data access) your code makes to symbols in other DSOs are resolved through a global offsets table (GOT, there is a manual page on it, as well), which basically contains an address of a procedure in other DSO (which you don't know at compile time) at a place address of which is known at the compile time. Therefore, each cross-DSO subroutine call normally contains an indirect access to a GOT slot containing corresponding address. These adresses are filled by rld, which can operate in two modes. In immediate resolution mode, rld would resolve each and every symbol at startup. However, most of the cross-DSO references are never used in "most" programs (your definition of "most" may differ ;-). Worse, this startup-time resolution takes time. Actually, if your program makes calls to half a dosen DSOs, which in turn make calls to other DSOs (not unheard of in largish commercial programs), startup time resolution takes *quite* a time, during which the system appears to do nothing. Therefore, by default, rld uses the so-called lazy resolution mode: at startup, it replaces each and every subroutine pointer in GOT with a pointer to it's resolution routine, which resolves the symbol the first time subroutine is called, and writes it's address back into GOT, so that all the subsequent calls can go directly to the intended routine. So far, so good. Since you are calling sin() and acos() (which are actually mapped to subroutines __acos and __sinf in DSO /usr/lib64/libm.so) in a very tight loop, compiler would like to make things happen faster, so that it loads addresses of both functions in a register. However, these two functions were never called before, and GOT contains address of the rld's name resolution function instead. When it gets called, it fixed GOT entry and calls the right functions. However, the register still points to the rld's name resolution routine, because rld has no way of knowing what this register value is supposed to mean, and can't fit it. So on the next iteration rld gets called again. And again. And again. And your program runs much slower than it should. There is an easy workaround to this. Saying: setenv LD_BIND_NOW 1 at the csh prompt (or your shell's equivalent if you use something else) would force rld to resolve all inter-DSO references at startup. There is also a patch for the problem, talk to your SGI contact person about it. Regards, /Serge.P From hinsen@ibs.ibs.fr Fri Nov 22 06:07:26 1996 Received: from ibs.ibs.fr for hinsen@ibs.ibs.fr by www.ccl.net (8.8.3/950822.1) id EAA22461; Fri, 22 Nov 1996 04:51:03 -0500 (EST) Received: from lmshp2.ibs.fr (lmshp2.ibs.fr [192.134.36.228]) by ibs.ibs.fr (8.6.12/8.6.12) with SMTP id KAA19525; Fri, 22 Nov 1996 10:52:12 +0100 Message-Id: <199611220952.KAA19525@ibs.ibs.fr> Received: by lmshp2.ibs.fr (1.37.109.4/16.2) id AA29380; Fri, 22 Nov 96 10:53:11 +0100 Date: Fri, 22 Nov 96 10:53:11 +0100 From: Konrad Hinsen To: berriz@chasma.harvard.edu Cc: chemistry@www.ccl.net In-Reply-To: <9611211920.AA20812@chasma.harvard.edu> (berriz@chasma.harvard.edu) Subject: Re: CCL:Q: Scientific Fortran for C programmers > the structure of C programs. This is so much so that I am having some > difficulty grasping the overall structure of Fortran90 programs. For > example, the whole business with "data blocks" seems bizarrely archaic > to me. But this is a minor issue. More important is that I'm unclear Remember that one of the criteria in the design of Fortran 90 was compatibility with Fortran 77, which *is* archaic. > on the usefulness of "modules." How is a module different from a file > with a whole bunch of subroutines in it? How is modularization achie- A module defines a name space. Within a module, the only visible names are those defined in the same module, or explicitly imported from another module. That means you can have a function foo() in several modules without name conflicts. > ved with FORTRAN77? What was deficient about this approach that > prompted the introduction of "modules" in Fortran90? Is there more to Fortran 77 had no modularization at all. All names were global (plus limited to six characters). This is one of the reasons for the weird function names in many libraries (NAG is a good example). Using the weirdest possible name was the best way to avoid name clashes. In comparison to C, Fortran 77 is equivalent to K&R C without the "static" qualifier. > the rationale for modules than providing a finer control over variable > scoping (which, I imagine, could be achieved with not much effort by a > careful naming of variables)? I am interested in reading discussions Careful naming of variables (and functions) will lead to trouble sooner or later. As soon as you are working with many people on a big project, or are using several libraries from external sources, you will find it more and more difficult to keep up a consistent naming scheme. That's exactly the problem that C and C++ programmers have. > Two areas that I am particularly concerned about are (1) managing the > proliferation of versions of my source code; (2) high performance, in- For version control, use RCS or something similar. > cluding parallelization. (Of course, neither of these topics is spe- High performance is more a matter of compilers than of languages. On most machines Fortran 77 outperforms both C and Fortran 90, but that is largely (though not entirely) due to the long experience with Fortran 77 code optimization for numerical applications. As for parallelization, Fortran 90 doesn't care about it any more than Fortran 77, C, C++, or any other "standard" languages. There are languages which support automatic parallelization (e.g. Sisal developed at LLNL), and several support libraries for other languages. > geared for release, of my code. My situation is that I am constantly > making small changes to my not-for-release code, as part of my simula- > tion "experiments," which means that I'm dealing with, effectively, a > large number of versions, many of which differ very slightly from each > other. I keep notes on these changes (as comments on the code, or on I had the same problem in the good old days - that is before I switched to object-oriented programming. Now I have a huge collection of more or less specialized modules containing "stable" classes. Any general and/or finalized code goes in there, whereas any experimental code stays in problem-specific "application" code (which typically consists of a single very small file). This is possible because OO programming allows me to add or replace code in some class without touching the original definition. I just write a short derived class that contains the new code. I wouldn't want to go back to procedural-style development for any of my simulation code! BTW, my current preference of programming languages is a mixture of Python and C. Python is a high-level interpreted object-oriented language that allows quick code development and testing (see http://www.python.org for more information). It also has a nice interface to C (and languages that can be linked to C code, such as Fortran on most machines), which I use to write the small time-critical part of my code (e.g. energy evaluation). Plus it's free and has been ported to any major operating system. > As far as high-performance, I would like to learn about the effects of > program structure on execution speed. For example, how expensive, re- > lative to their alternatives, are subroutine calls and modules in For- > tran90? Do COMMON variables slow down execution? Does one get faster > code if one avoids COMMON variables, and instead defines subroutines > with a long list of arguments? All these questions are compiler-specific to some degree, and more importantly they are rarely relevant. I doubt that the execution time of any reasonably designed simulation code will ever be influenced strongly by the cost of variable access or subroutine calls. I would never compromise clean code structure for a minuscule gain in speed. The generally recommended approach to program design an optimization is 1) Design the basic structure for clarity and ease of modification. 2) Find the best algorithms for the key operations. 3) Write a first implementation without any special optimization. 4) Use a profiler to find performance bottlenecks (if any) and carefully optimize them. Typically this will affect only a very small part of the code. Unfortunately many scientists are so obsessed with speed that they completely forget about code design. The result is a large pool of unreliable, incomprehensible, and user-unfriendly code, which has probably caused some frustration for every CCL reader. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28 Institut de Biologie Structurale | Fax: +33-4.76.88.54.94 41, av. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- From ep7@dent.okayama-u.ac.jp Fri Nov 22 07:48:30 1996 Received: from deews1.dent.okayama-u.ac.jp for ep7@dent.okayama-u.ac.jp by www.ccl.net (8.8.3/950822.1) id HAA23183; Fri, 22 Nov 1996 07:06:42 -0500 (EST) Received: from [150.46.140.80] (yobou2.dent.okayama-u.ac.jp) by deews1.dent.okayama-u.ac.jp (5.67+1.6W/6.4JAIN-1.1) id AA04713; Fri, 22 Nov 96 21:06:24 JST Message-Id: <9611221206.AA04713@deews1.dent.okayama-u.ac.jp> Date: Fri, 22 Nov 1996 21:15:25 +0900 To: CHEMISTRY@www.ccl.net From: ep7@dent.okayama-u.ac.jp (=?ISO-2022-JP?B?GyRCQDVCPBsoQg==?=) Subject: CCL: CHELPG and MerzKollman Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-Mailer: Eudora-J(1.3.8.5-J13) I ask everybody about the selection of points for CHELPG and MerzKollman in Gaussian 94. How do the CHELPG and MerzKollman choose the point ? For example, Point which fall within the van der Waals radius of any of the atoms are discarded ? In CHELP, this is true. I will summarize the answers for my question. Thank you in advance. Masao Masamura Preventive Dentistry Okayama University Dental School Shikata-cho, 2-5-1 Okayama 700 Japan FAX: 81-86-225-3724 e-mail: ep7@dent.okayama-u.ac.jp From chpajt@bath.ac.uk Fri Nov 22 08:48:32 1996 Received: from goggins.bath.ac.uk for chpajt@bath.ac.uk by www.ccl.net (8.8.3/950822.1) id IAA23453; Fri, 22 Nov 1996 08:15:34 -0500 (EST) Received: from bath.ac.uk (actually host midge.bath.ac.uk) by goggins.bath.ac.uk with SMTP (PP); Fri, 22 Nov 1996 12:27:39 +0000 Date: Fri, 22 Nov 1996 12:27:33 +0000 (GMT) From: A J Turner To: Joely cc: chemistry@www.ccl.net Subject: Re: CCL:CADPAC 6.0 on RS6000 or DEC Alpha In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi! I have a running version of CADPAC6 on the DEC alpha axp 2000. I needed to link in some blas from netlib - but it was not too hard. Let me know the problem and I _might_ be able to help. All the best Alex ------------------------------------------------------------------- |Alexander J Turner |A.J.Turner@bath.ac.uk | |Post Graduate |http://www.bath.ac.uk/~chpajt/home.html| |School of Chemistry |+144 1225 8262826 ext 5137 | |University of Bath | | |Bath, Avon, U.K. |Field: QM/MM modeling | ------------------------------------------------------------------- From jsl@virgil.ruc.dk Fri Nov 22 08:54:01 1996 Received: from emma.ruc.dk for jsl@virgil.ruc.dk by www.ccl.net (8.8.3/950822.1) id IAA23446; Fri, 22 Nov 1996 08:14:36 -0500 (EST) Received: from virgil.ruc.dk by emma.ruc.dk (4.1/JBA-1.18) id AA13125; Fri, 22 Nov 96 14:18:43 +0100 Received: from VIRGIL/MAILQUEUE by virgil.ruc.dk (Mercury 1.21); 22 Nov 96 14:10:26 +0100 Received: from MAILQUEUE by VIRGIL (Mercury 1.21); 22 Nov 96 14:10:24 +0100 From: "Jens Spanget-Larsen" Organization: Roskilde Universitetscenter To: chemistry@www.ccl.net Date: Fri, 22 Nov 1996 14:10:19 +0100 Subject: CCL:Anharmonicity (Summary) Priority: normal X-Mailer: Pegasus Mail for Windows (v2.42a) Message-Id: <45C5465484@virgil.ruc.dk> CCL: On Friday, 15 Nov 1996, I posted the following question: > In a study of molecular vibrational structure I have encountered a > normal mode with a "symmetrical" anharmonic potential V of the form: > > V(Q) = a*Q^2 + b*Q^4 > > i.e., the potential V as a function of the normal coordinate Q can be > approximated by a fourth order polynomial in Q, containing only the > second and the fourth power. What are the solutions to the > vibrational eigenvalue problem with this potential function? I would > be most grateful for information on literature that deals with this > problem. I immediately received a number of useful replies, that are summarized below. Thank you to all that replied! Yours, Jens >--< ################################################################## Date sent: Fri, 15 Nov 96 10:21:42 PST From: hls@hafnium.cchem.berkeley.edu (Herb Strauss) Please look at papers by D. Harris et al, J Laane, et al, W D Gwinn et el and H. L. Strauss et al, mostly in the sixties. Herb Strauss ################################################################## From: "MARTIN L. SAGE X-2713" Organization: Syracuse University Date sent: Fri, 15 Nov 1996 14:52:34 EST Dear Jens, I wrote a paper "An Algebraic Treatment of Quantum Vibrations Using REDUCE" , J. Symbolic Computation (1988)5, 377-384 which treats this potential. If REDUCE isn't avaailable I would consider sending more information. Sincerely, Martin MARTIN L. SAGE DEPARTMENT OF CHEMISTRY SYRACUSE UNIVERSITY CST 1-014 SYRACUSE, NY 13244-4100 USA mlsage@syr.edu ################################################################## Date sent: Fri, 15 Nov 1996 11:21:21 -0500 From: Sam Abrash This is the potential for an anharmonic bending motion, the solution can be found in Wilson, Decius and Cross, Molecular Vibrations or any other standard text on vibrational spectroscopy. Samuel A. Abrash Department of Chemistry University of Richmond Richmond, VA 23173 Phone: (804) 289-8248 Fax: (804) 289-8482 UNTIL DECEMBER: Abrash@URVAX.URICH.EDU DECEMBER and AFTER: SABRASH@RICHMOND.EDU ################################################################### Date sent: Fri, 15 Nov 1996 13:51:20 -0500 From: Russ Johnson Hello! There is a nice paper on that potential form by Jaan Laane in Applied Spectroscopy Volume 24 Number 1 page 73 (1970). He has solved it using harmonic oscillator wavefunctions, and had provided tables from which the lowest sixteen eigenvalues can be interpolated. Russ Johnson Dr. Russell D. Johnson III Research Chemist Physical and Chemical Properties Division National Institute of Standards and Technology Gaithersburg, MD 20899 voice 301+975-2513 fax 301+975-3670 email: russell.johnson@nist.gov ################################################################### Date sent: Fri, 15 Nov 1996 14:31:57 -0500 From: Brian Teppen Hello, Jens: The eigenvalues depend on coefficients a and b of course. If a is negative and has the right proportionality to b, then you get a symmetric, double-well potential. The force constant (second derivative) can give the same value when evaluated at either minimum. Each well will be somewhat anharmonic. I have used such a potential (paper in review) to model the angle-bending of octahedral systems, so that there will be minima at both 90 and 180 degrees but not zero degrees. I used a=(-1.234)*b to get the two, symmetric minima. Another physical example (where I was first exposed to the idea) would be the inversion of NH3. Best wishes, Brian J. Teppen teppen@srel.edu Advanced Analytical Center for Environmental Sciences Savannah River Ecology Laboratory University of Georgia Drawer E Aiken, SC 29802 phone:803-725-8157 fax:803-725-3309 #################################################################### From: TOPPER ROBERT Subject: Re: CCL:Anharmonicity Well, don't quote me on this but I don't think that an exact analytical solution exists. There are only a few oscillator problems which yield analytical solutions; the most notable being the harmonic oscillator and the Morse oscillator. There are a couple of others too. Of course, you could use perturbation theory to form an approximate solution, treating the Hamiltonian H = T(p) + k*Q^2/2 as the zeroth-order part (for which the solution is known) and bQ^4 as the perturbation. Within this approximation the energy is given to first order by E = E^0_n + E'_n where E^0_n = hbar * omega * (n+0.5) with omega = sqrt (k / m ) (m the mass of the oscillator) and E'_n = b * < n | Q^4 | n > , i.e. the expectation of the Q^4 operator within the nth quantum state. This may or may not have a simple closed-form solution for all n either, but could be easily done for the case where n=0 (the ground state). I believe that the result will be on the order of hbar^2 if memory serves. I'll leave the rest of the algebra for you to work through; have a look at Chapter 7 of Donald MacQuarrie's "Quantum Chemistry" or any other comparable quantum chemistry textbook. Hope this helps, robert ********************************************************************** Robert Q. Topper, Chemistry Dept. email: topper@cooper.edu The Cooper Union phone: (212) 353-4378 51 Astor Place subway: take the 6 to Astor Place New York, NY 10003 USA or the N/R to 8th St/NYU http://www.cooper.edu/engineering/chemechem/depts_info/topper.html Molecular Monte Carlo = http://www.cooper.edu/engineering/chemechem/monte.html ********************************************************************** The Cooper Union, established by Peter Cooper in 1859, is a private engineering/ architecture/art college where all students receive full scholarships. ********************************************************************** ################################################################### Date sent: 15 Nov 1996 17:47:34 -0500 From: "John Beckerle" Reply to: RE>CCL:Anharmonicity I would be very interested to see the responses to your question. Thanks. ################################################################### From: secrest@aries.scs.uiuc.edu (Don Secrest) Date sent: Tue, 19 Nov 1996 11:58:26 -0600 (CST) Dear Dr. Spanget-Larsen: Many years ago I tried to solve the problem with the potential X**4 only. This seemed so easy, but I was unable to solve it after much work. I talked to a Professor in the math department and he was quite sure it couldn't be solved in closed form. So I settled for a numerical solution and developed a method for solving the problem X**(2*n). It is published in J. Chem. Phys. 37,830(1962). I am still not convinced that this problem is unsolvable in closed form, however. If you manage to solve your problem I would be very interested in seeing your solution. Sincerely yours Don Secrest secrest@uiuc.edu ################################################################### =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= JENS SPANGET-LARSEN Department of Chemistry Phone: +45 46757781 + 2710 Roskilde University (RUC) Fax: +45 46757721 P.O.Box 260 E-Mail: JSL@virgil.ruc.dk DK-4000 Roskilde, Denmark http://frederik.ruc.dk/dis/chem/psos =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From jose@zeus.uncor.edu Fri Nov 22 09:48:33 1996 Received: from zeus.uncor.edu for jose@zeus.uncor.edu by www.ccl.net (8.8.3/950822.1) id IAA23671; Fri, 22 Nov 1996 08:53:47 -0500 (EST) Received: by zeus.uncor.edu; id AA29613; Fri, 22 Nov 1996 10:58:33 -0200 Sender: jose@zeus.uncor.edu Message-Id: <3295A379.2F1C@zeus.uncor.edu> Date: Fri, 22 Nov 1996 10:58:33 -0200 From: "Dr. Jose Santiago Duca (h)" Organization: INFIQC - Dpto Qca Organica - Facultad de Ciencias Quimicas - Universidad Nacional de Cordoba - Agencia Postal 4 - CC 61 (5016) - Cordoba - ARGENTINA - tel.: +54-51-33-4170 / +54-51-33-4173 fax: +54-51-33-4174 X-Mailer: Mozilla 3.0Gold (X11; I; OSF1 V3.0 alpha) Mime-Version: 1.0 To: CHEMISTRY@www.ccl.net Cc: jose@zeus.uncor.edu Subject: Opt(EF) and Freq in G94 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear CCL'ers: I got a problem with Gaussian 94 trying to locate a stationary point, and I would like to know how to solve it. I run twice an optimization with (a) the Opt(EF) option (b) the usual Opt option Since both of them gave slightly different geometrical results, I run a freq calculation, based on the corresponding .chk files. My surprise was to find that when I used 'Opt(EF) Freq' for the pre-optimized (a) stationary point, the method didn't find a stationary point at first!! The first EF minimum search looked like ... ITEM VALUE THRESHOLD CONVERGED? MAXIMUM FORCE 0.301043 0.000450 NO RMS FORCE 0.107132 0.000300 NO MAXIMUM DISPLACEMENT 0.096106 0.001800 NO RMS DISPLACEMENT 0.046961 0.001200 NO PREDICTED CHANGE IN ENERGY -0.007397 EF-EF-EF-EF-EF-EF-EF-EF-EF-EF-EF-EF-EF-EF-EF-EF-EF-EF-EF-EF-EF-EF-EF-EF This means that the optimization will be carried out again!! What is supposed I have to do on the subject to avoid such a waste of cpu time? Am I doing something wrong? Helpful comments are welcome, thanks a priori, Jose -- Dr. Jose Santiago Duca (h) e-mail: jose@zeus.uncor.edu URL: http://zeus.uncor.edu/jsd/jsd.htm From xavier@stark.udg.es Fri Nov 22 11:48:34 1996 Received: from stark.udg.es for xavier@stark.udg.es by www.ccl.net (8.8.3/950822.1) id LAA24568; Fri, 22 Nov 1996 11:15:55 -0500 (EST) Received: from quantum.udg.es by stark.udg.es via SMTP (931110.SGI/930416.SGI.AUTO) for chemistry@www.ccl.net id AA20878; Fri, 22 Nov 96 17:18:20 -0800 Message-Id: <9611230118.AA20878@stark.udg.es> X-Sender: xavier@stark.udg.es X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Nov 1996 17:09:32 +0000 To: chemistry@www.ccl.net From: Xavier Subject: 3RD derivatives Dear CCLers, I am interested in computing analytical energy third derivatives respect to nuclear displacements. Does any one know about a program capable of doing this ?=20 Thanks in advance. /-------------------------------------------------------/ / Xavier Fradera i Llin=E0s - IQC - Universitat de Girona / / E-mail: xavier@stark.udg.es / /-------------------------------------------------------/ From omar@boston.sgi.com Fri Nov 22 12:01:30 1996 Received: from deliverator.sgi.com for omar@boston.sgi.com by www.ccl.net (8.8.3/950822.1) id KAA24453; Fri, 22 Nov 1996 10:59:32 -0500 (EST) Received: from sgibos.boston.sgi.com by deliverator.sgi.com via ESMTP (950413.SGI.8.6.12/951211.SGI.AUTO) id HAA23376; Fri, 22 Nov 1996 07:59:22 -0800 Received: from arkham.boston.sgi.com by sgibos.boston.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/940406.SGI) id KAA16067; Fri, 22 Nov 1996 10:59:16 -0500 Received: by arkham.boston.sgi.com (950413.SGI.8.6.12/951211.SGI) id KAA20704; Fri, 22 Nov 1996 10:59:13 -0500 From: "Omar G. Stradella" Message-Id: <9611221059.ZM20702@arkham.boston.sgi.com> Date: Fri, 22 Nov 1996 10:59:12 -0500 In-Reply-To: ps@ocisgi7.unizh.ch (Serge Pachkovsky) "CCL:F77 compiler on R10000 SGI Indigo2: buggy?" (Nov 22, 11:09am) References: <199611221009.LAA14534@ocisgi7.unizh.ch> Organization: Silicon Graphics, Inc. Reply-to: omar@boston.sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: robert@PAULI.utmb.edu, CHEMISTRY@www.ccl.net Subject: Re: CCL:F77 compiler on R10000 SGI Indigo2: buggy? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Nov 22, 11:09am, Serge Pachkovsky wrote: > Subject: CCL:F77 compiler on R10000 SGI Indigo2: buggy? > Hi, > > > 1) f77 silly.f -o silly (this produces 32-bit mips2 code by default) > > 2) f77 -O2 silly.f -o silly > > 3) f77 -64 silly.f -o silly (this produces 64-bit mips4 code) > > 4) f77 -64 -O2 silly.f -o silly > > 5) f77 -64 -O3 silly.f -o silly > > > The unusual results I have obtained are shown in table below. Apart > > from the fact that the 64-bit executables produce slightly different > > result for x than their 32-bit counterparts, the CPU times in column > > 4) are larger by a factor of TEN in comparison to other columns! > > Normally, I would expect them to be in between 3) and 5). This abnormal > > This is a known bug in vanilla 6.2 f77. It is *not* actually a bug in > Fortran compiler per se, but rather an unexpected interaction of new dynamic > linking convenstions and compiler optimizations. Here is that happens: > [...] > There is an easy workaround to this. Saying: > > setenv LD_BIND_NOW 1 > > at the csh prompt (or your shell's equivalent if you use something else) would > force rld to resolve all inter-DSO references at startup. There is also a > patch for the problem, talk to your SGI contact person about it. > Or upgrade your Fortran compiler to 7.0 or 7.0.1. They provide better support for R10000 processors. Omar. -- +---------------------------------------------------------------------+ Omar G. Stradella, Ph.D. Supercomputing Applications Silicon Graphics, Inc. Computational Chemistry One Cabot Road, Hudson, MA 01749, USA N 42 22'41" W 71 33'45" E-mail: omar@boston.sgi.com Phone: +1-508-567-2258 FAX: +1-508-562-4755 http://www.sgi.com/ChemBio http://reality.sgi.com/omar +-------- Ph-nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn -------+ From mmh1203@ggr.co.uk Fri Nov 22 12:08:21 1996 Received: from gate.ggr.co.uk for mmh1203@ggr.co.uk by www.ccl.net (8.8.3/950822.1) id KAA24406; Fri, 22 Nov 1996 10:53:16 -0500 (EST) Received: from mailhub.ggr.co.uk (uk0x07.ggr.co.uk [147.184.146.69]) by gate.ggr.co.uk; Fri, 22 Nov 1996 15:51:10 GMT Message-Id: <14561.199611221551@mailhub.ggr.co.uk> Received: from UKSYSA.ggr.co.uk (uksysa.ggr.co.uk [147.184.215.254]) by mailhub.ggr.co.uk; Fri, 22 Nov 1996 15:51:41 GMT From: Dr M M Hann To: chemistry@www.ccl.net Subject: notice of MGMS meeting in UK - Dec 6, 1996 Date: 22 Nov 96 16:42:00 BST *************************************************************************** IF YOU WISH TO ATTEND THIS MEETING PLEASE REGISTER IN ADVANCE BY MAILING MIKE HANN (mmh1203@ggr.co.uk) WITH YOUR NAME AND AFFILIATION. YOU WILL BE ABLE TO PAY (cash or cheque only please) AT THE MEETING BUT WE MUST HAVE PRIOR NOTICE OF REGISTRATION. RECEIPTS WILL BE AVAILABLE. *************************************************************************** The Molecular Graphics and Modelling Society Presents 'Future Visions' Date: 6th December 1996 Venue: Room MB303 (main building) Birkbeck College, Mallet St., London, UK (Nearest tube stations: Goodge St, Euston Square or Russell Sq) Registration: See top of document Costs: L20 Members, L30 Non-members, L10 Students A one day conference featuring top computational chemistry hardware/software vendors, discussing their latest concepts and ideas for computer-aided drug design. Participating Companies: Chemical Design Molecular Design Molecular Simulations Oxford Molecular Schrodinger Silicon Graphics Sun Microsystems Tripos The meeting includes talks given by all the above vendors, a round table discussion where you can put your questions to the assembled experts, plus a chance to see demos of some of the latest hardware and software developments. Programme: 9:00-9:45 Registration and Coffee 9:45-10:15 Silicon Graphics 10:15-10:45 Sun MicroSystems 10:45-11:15 Chemical Deisgn 11:15-11:45 Coffee and Demos 11:45-12:15 Molecular Simulations 12:15-12:45 Tripos 12:45-1:15 Oxford Molecular 1:15:2:15 Lunch and Demos 2:15-2:45 Schrodinger 2:45:3:15 Molecular Design 3:15-4:15 Round Table Discussion 4:15 Close Take a look at gopher://www.ccl.net:73/1m/info/conferences for info on conferences at the CCL From dimitris@3dp.com Fri Nov 22 17:48:36 1996 Received: from boris.3dp.com for dimitris@3dp.com by www.ccl.net (8.8.3/950822.1) id RAA26996; Fri, 22 Nov 1996 17:00:18 -0500 (EST) Received: from europa.3dp.com by boris.3dp.com via SMTP (931110.SGI/930416.SGI) for chemistry@www.ccl.net id AA16245; Fri, 22 Nov 96 17:04:58 -0500 Received: by europa.3dp.com (950413.SGI.8.6.12) id QAA13823; Tue, 22 Oct 1996 16:58:59 -0400 From: "Dimitris Agrafiotis" Message-Id: <9610221658.ZM13821@europa.3dp.com> Date: Tue, 22 Oct 1996 16:58:57 -0400 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: chemistry@www.ccl.net Subject: Help with Mathematica Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii I want to compute a rather complicated integral using Mathematica or any other equivalent symbolic math program. If any of you has access to such a program and wouldn't mind spending a few cpu cycles for a needy stranger, please send me a personal note. Thanks, -- Dimitris K. Agrafiotis, PhD | e-mail: dimitris@3dp.com 3-Dimensional Pharmaceuticals, Inc. | tel: (610) 458-6045 665 Stockton Drive, Suite 104 | fax: (610) 458-8249 Exton, PA 19341 From robert@pauli.utmb.edu Fri Nov 22 19:48:36 1996 Received: from nmr.utmb.edu for robert@pauli.utmb.edu by www.ccl.net (8.8.3/950822.1) id TAA27580; Fri, 22 Nov 1996 19:42:54 -0500 (EST) Received: from pauli.utmb.edu by nmr.utmb.edu via SMTP (931110.SGI/930416.SGI.AUTO) for CHEMISTRY@www.ccl.net id AA24953; Fri, 22 Nov 96 18:47:29 -0600 Received: (from robert@localhost) by pauli.utmb.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA07686 for CHEMISTRY@www.ccl.net; Fri, 22 Nov 1996 18:42:08 -0600 From: "Robert Fraczkiewicz" Message-Id: <9611221842.ZM7684@pauli.utmb.edu> Date: Fri, 22 Nov 1996 18:42:08 -0600 In-Reply-To: ps@ocisgi7.UNIZH.CH (Serge Pachkovsky) "CCL:F77 compiler on R10000 SGI Indigo2: buggy?" (Nov 22, 11:09am) References: <199611221009.LAA14534@ocisgi7.unizh.ch> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: CHEMISTRY@www.ccl.net Subject: Re: CCL:F77 compiler on R10000 SGI Indigo2: buggy? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Dear Netters, Many thanks to all who replied to my query, especially to Serge Pachkovsky for his very informative posting. It seems that "setenv LD_BIND_NOW 1" is right on target, all codes work now correctly. Unfortunately, other binaries like jot or netscape do not work with LD_BIND_NOW set on due to "unresolved symbols". However, setting _RLD_ARGS to "-ignore_unresolved" seems to be a good workaround. I did RTFM pages about rld(1), elfdump(1) and dso(5) and found some useful options for monitoring the execution of IRIX binaries. Setting _RLD_PATH (or _RLD64_PATH for 64-bit executables) to /usr/lib/rld.debug (/usr/lib64/rld.debug) and _RLD_ARGS to "-time_summary -trace -quickstart_info" allows for an insight into what really happens during program executions. For example, I was able to confirm existence of the f77-ld-rld bug reported by Serge in the case 4) of my program: rld is called back and forth at EVERY call to sin and acos in the loop, whereas in cases 1)-3) and 5) it is called only once at startup. What's interesting is that the 5)-th code is also optimized, but works correctly... I have also noticed that 64-bit binaries, unlike 32-bit counterparts, fail to do QUICKSTART. Next, I run some of our applications optimized with -64 -O2 and found out that rld is unnecessarily called many times for the same routine. If some of you have computational chemistry programs that perform poorly on SGI R10000, try the test run with /usr/lib64/rld.debug ... Best regards, Robert Fraczkiewicz University of Texas Medical Branch Galveston, TX 77555 From robert@pauli.utmb.edu Wed Nov 20 12:52:29 1996 Received: from nmr.utmb.edu for robert@pauli.utmb.edu by www.ccl.net (8.8.2/950822.1) id MAA29326; Wed, 20 Nov 1996 12:29:54 -0500 (EST) Received: from pauli.utmb.edu by nmr.utmb.edu via SMTP (931110.SGI/930416.SGI.AUTO) for chemistry@www.ccl.net id AA17595; Wed, 20 Nov 96 11:34:10 -0600 Received: (from robert@localhost) by pauli.utmb.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA01483; Wed, 20 Nov 1996 11:29:02 -0600 From: "Robert Fraczkiewicz" Message-Id: <9611201129.ZM1481@pauli.utmb.edu> Date: Wed, 20 Nov 1996 11:29:02 -0600 In-Reply-To: JOCHEN BUEHLER "CCL:RPAC 11.0" (Nov 20, 8:59am) References: <009ABA49.A649E095.75@chclu.chemie.uni-konstanz.de> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: JOCHEN BUEHLER , chemistry@www.ccl.net Subject: Compiling F77 on SGI and Re: CCL:RPAC 11.0 On Nov 20, 8:59am, JOCHEN BUEHLER wrote: > Dear CCL'ers, > > has anybody successfully compiled RPAC 11.0 on a SGI running IRIX 6.2 > or a Cray J916 ? > I'm getting a clean compile on the Cray but incorrect results and > failing compiles on the SGI... > Dear Jochen, Are you compiling on SGI with R10000 chip? The new MIPSpro F77 compiler may be buggy. Let me explain why: I have an experience compiling program FANTOM (refinement and Monte Carlo simulations of proteins) on SGI with R4400, SGI with R10000 and Cray J90. It compiles with or without optimization (either partial, or complete) and runs perfectly on SGI R4400, Cray J90 and SGI R10000 in 32-bit mode. The trouble begins when attempt is made to perform optimized compilation in 64-bit mode on R10000, i.e. with the "f77 -64 -O2" or "f77 -64 -O2 -r10000" commands. FANTOM is a ~17000-line code with 2200-line main program fantom.f and subroutines in separate smaller *.f files. With the set of options quoted above the compiler performs complete optimization of every subroutine, but only partial optimization of the main program because of the exceeded size limits. It does not matter in 32-bit mode: fantom.f is not fully optimized but the executable works fine. Now the real show begins when I try to run 64-bit version irregardles of what input file I use: 1) it crashes with "Segmentation fault". 2) it works perfectly when I do either of these: 2.1) remove a n y IF statement from fantom.f 2.2) replace the contents of a n y IF() THEN .... ENDIF statement with CONTINUE 2.3) force complete optimization of fantom.f with -OPT:size_limit options 2.4) recompile it without optimization (option -g) I really do not want to jump to the conclusion that there is a bug in the compiler, but this is so far the only logical solution to this puzzle. FANTOM interprets user commands interactively and there are a lot of IF statements in fantom.f; is there a limit to the number of IFs in the partial compilation of F77 code? Curious, Robert Fraczkiewicz University of Texas Medical Branch From granthan@islandnet.com Wed Nov 20 08:56:08 1996 Received: from mail for granthan@islandnet.com by www.ccl.net (8.8.2/950822.1) id HAA27188; Wed, 20 Nov 1996 07:49:57 -0500 (EST) Received: from i2-28.islandnet.com [198.53.172.28] by mail (Smail3.2) with smtp id m0vQC4e-0006cXC for ; Wed, 20 Nov 1996 04:48:16 -0800 (PST) Message-Id: Date: Wed, 20 Nov 1996 04:48:16 -0800 (PST) To: CHEMISTRY@www.ccl.net From: granthan@islandnet.com (Grant Handford) Subject: Summary: tar files Here is Part I of my summary concerning the conversion of tar files into usable form. It is designed for those who, like myself, did not know how to uudecode tar files like the ones e-mailed to us on the CCL cocerning the special announcement about the new Gaussian program which included a seven part series of program segments (tar.uu files). I wish to thank all of you who responded to my query. It was very much appreciated. Sincerely, Grant. E-mail:- granthan@islandnet.com **************************************************************************** **************************************************************************** ********>> I am just getting >> started at using a computer for e-mail, Internet, etc. I need to know how >> to convert compressed tar files into usable form. > >On the machine running UNIX you can do following: > > 1) Make a directory (say myprog) which you want to be a top of the tree > of directories for a tar archive > mkdir myprog > > 2) Copy a compressed tar file (i.e., file which has the *.tar.Z or > *.tar.gz extension, e.g., myprog.tar.Z or myprog.tar.gz) > to the myprog directory > > > 3) Execute the command: > a) for a *.tar.Z archive > zcat myprog.tar.Z | tar xvof - > a) for a *.tar.gz > gunzip -c myprog.tar.gz > >and the files from the archive will stored under the myprog directory. > >Note on uudecoding. If you receive a uuencoded file (sorry....) via e-mail, >i.e., a file which has a following format: > >begin 644 myprog.tar.Z >M86YI;6%T92YF```````````````````````````````````````````````` >M```````````````````````````````````````````````````````````` >M-------*and*so*on*------------------------------------------ > .......... many lines like this. >` >end > >then you know it is an uuencoded file, i.e., a file, usually binary, >which was converted to a special format so the electronic mail does >not mess it up (plain electronic mail, in principle, would alter most >binary files which contain unprintable characters). To convert the >uuencoded file into an original binary file, you need to save it, >e.g., as myprog.uu, and the use the uudecode program as: > uudecode myprog.uu >This will recreate the original binary file, myprog.tar.Z in our case. >Sometimes larger uuencoded files are split into smaller messages. >In this case, you need to join all the pieces together in the order >specified, delete all e-mail headers, and leave no gaps. Only then you >can use uudecode. Of course, there are e-mail programs that will do >it for you automaticall, and tools which will make it easier, but >if you do not have them, you still can do it by hand. > >Jan Labanowski >jkl@ccl.net > > > **************************************************************************** **************************************************************************** ******** Sincerely, Grant. E-mail:- granthan@islandnet.com From gmercier@mail.med.upenn.edu Thu Nov 21 14:49:49 1996 Received: from mail.med.upenn.edu for gmercier@mail.med.upenn.edu by www.ccl.net (8.8.2/950822.1) id OAA17924; Thu, 21 Nov 1996 14:31:27 -0500 (EST) Received: (from gmercier@localhost) by mail.med.upenn.edu (8.6.12/8.6.12) id OAA12943 for CHEMISTRY@www.ccl.net; Thu, 21 Nov 1996 14:30:58 -0500 From: "Gustavo A. Mercier Jr" Message-Id: <199611211930.OAA12943@mail.med.upenn.edu> Subject: Summary Linux/OpenGL/Motif To: CHEMISTRY@www.ccl.net Date: Thu, 21 Nov 1996 14:30:58 -0500 (EST) Hi, CCL'ers! Below is the summary to my query on OpenGl and Motif libraries for Linux boxes. As somebody suggested, the first thing is to find out what you want to run and then get the libraries that you need. (We did that! :-)) In a nutshell, MESA is the OpenGL for Linux. Lesstif is the MOTIF for Linux, but ... it is still in development. A few commercial vendors where mentioned. See below. One user was satisfied with f2c/g77, but another was not. Unfortunately, I must apologize to the latter user whose message I deleted by mistake (or Freudian Slip!) I also deleted Dr. Janne Ravantti's message that had personal stuff, but his recommendation is in line with the comments made by other users. Bye ****** SUMMARY starts below my signature ****** -- ("`-/")_.-'"``-._ Gustavo A. Mercier,Jr.,MD,PhD (. . `) -._ )-;-,_() Division of Nuclear Medicine (v_,)' _ )`-.\ ``- Dept. of Radiology _;- _,-_/ / ((,' University of Pennsylvania ((,.-' ((,/ 3400 Spruce St. gmercier@mail.med.upenn.edu Philadelphia, PA 19104 215-662-3069/3091 fax: 215-349-5843 --- ****** Hello I'm using OpenGL and Motif from Xinside (www.xinside.com), this is under FreeBSD but they have the same products for Linux.You'l need also de Xserver from Xinside. All the other things you use from XFree86. One observation: the OpenGL implementations around do not have hardware 3D acceleration (or are minimal) so you should use a fast card. A good free OpenGL implementation under X11 in general is Mesa by Brian Paul it does produce very high quality graphics at very good speeds that can run over the wire using standar X11 protocol (OpenGL uses GLX). You can find out more about mesa at: http://www.ssec.wisc.edu/~brianp/Mesa.html Pedro ******* Hello. Well, you can buy Motif and OpenGL. I would guess that both of them cost about $200 each but I might be wrong. Motif has been ported to Linux/Xfree by Metrolink and there are at least two companies offering OpenGL. Check e.g. www.li.org or www.linux.org - they might have links to those companies. OpenGL is - as far as I understand - VERY slow. The implementations on Linux/Xfree are basically just emulators, i.e. they run on top of X11. Someone is working on a freeware implementation of Motif, but since I have strong feelings against Motif (looks too much like M$-Windows to me), I don't know the status of that project. < stuff deleted > Best wishes Kenneth +-----------------------------------------------------------------+ | Kenneth Geisshirt Ph.D.-student | | Department of Life Sciences and Chemistry, Roskilde University | | Currently at: University of Colorado at Boulder | +-----------------------------------------------------------------+ | kneth@fatou.ruc.dk http://virgil.ruc.dk/~kneth/ | +-----------------------------------------------------------------+ | Geek Code 2.1: d++h--s!gp2!aua-w+vc+U++p+L++3EN++K-W---M- | | !V-po+Y+t!5jRG?!tvb++D+B?e---u+h--grn++y+ | +-----------------------------------------------------------------+ ****** I'd generally don't recommend to switch to commercial Xserver. You'll pay money, receive no sources and the tech sup answers that are worse than usenet replies. But this is just my humble opinion. There is a free implementation of OpenGL for Linux. It's called MESA. I don't remember the url now, but you can make search on 'OpenGl free MESA' keywords. Unfortunally, there is no working free implementation of Motif for Linux. Hungry programmers (http://www.hungry.com) are working on it, but their implementation LessTif is WIP - Work In Progress now. There are quite a lot vendors, who sell their Motif for Linux. Typical prices are $30-$50 for runtime and ~$100 for development version. Of course, to compile programs, you'll need the development versions. Check Cheapbytes http://www.cheapbytes.com/ for example. Andrey V Khavryutchenko akhavr@compchem.kiev.ua Interests: Computational Chemistry, OOA&OOP, The Net ******** Hi, maybe you should try "Lesstif" which you can find on the net (Redhat software). This is a freely available Motif clone Steven -------------------------------------------------------------------------- Steven Creve steven.creve@chem.kuleuven.ac.be Labo Quantumchemie Celestijnenlaan 200F 3001-HEVERLEE tel: (32) (16) 32 73 93 BELGIUM fax: (32) (16) 32 79 92 ******** Both of them work on top of X11, so they should be considered add-ons. There are several implementations of Motif at reasonable prices for Linux. The OpenGL clone I know of is Mesa, which is a free and portable OpenGL clone relying on nothing more than standard X functions (meaning it doesn't use specialized graphics hardware optimally). You should first make a list of the requirements of all programs you consider interesting. Preparing yourself for anything imaginable might be a waste of time. ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28 Institut de Biologie Structurale | Fax: +33-4.76.88.54.94 41, av. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- ******* From joubert@ext.jussieu.fr Fri Nov 22 04:48:38 1996 Received: from shiva.jussieu.fr for joubert@ext.jussieu.fr by www.ccl.net (8.8.3/950822.1) id EAA22302; Fri, 22 Nov 1996 04:32:07 -0500 (EST) Received: from idf.ext.jussieu.fr (idf.ext.jussieu.fr [134.157.81.129]) by shiva.jussieu.fr (8.7.6/jtpda-5.2) with ESMTP id KAA17169 for ; Fri, 22 Nov 1996 10:32:01 +0100 (MET) Received: from [134.157.11.17] by idf.ext.jussieu.fr (8.6.10/jtpda-4.0) with SMTP; Fri, 22 Nov 1996 10:31:54 +0100 X-Sender: joubert@idf.ext.jussieu.fr Message-Id: Date: Fri, 22 Nov 1996 11:38:08 +0200 To: chemistry@www.ccl.net From: joubert@ext.jussieu.fr (Laurent Joubert) Subject: Tools for G94/Scian Dear Netters, You can now download 3 little academic programs, allowing to visualize some G94 output files data with the freeware SciAn (visualization and animation program). - Transcube : convert G94 "CUBE" files to SciAn "STF" files, in order to visualize electronic density, electrostatic potential, or molecular orbitals. - transfreq : convert G94 output files (with vibrationnal analysis), in order to visualize vibrationnal frequencies (as arrows) with SciAn. (you must have an "NFF" file (created with Molnff for example) to visualize your molecule) - Molnff : creates SciAn "NFF" file from a G94 output, in order to visualize your molecule with SciAn (this is a first version, the next one (very soon !) will automatize the molecule creation). Here is the internet address : (please, send me an e-mail if you intend to download them !) : http://134.157.11.11/Pages/LECA/GP/Laurent/soft.html Any comments are welcome. Laurent Joubert ******************************************************** * Laurent JOUBERT (PhD student) * * * * Ecole Nationale Superieure de Chimie de Paris * * Laboratoire d'Electrochimie et de Chimie Analytique * * 11, rue Pierre et Marie Curie * * 75231 PARIS CEDEX 05- FRANCE * * * * Tel : 44-27-66-94 * * Fax : 44-27-67-50 * * * * E-Mail : joubert@ext.jussieu.fr * * http://www.enscp.jussieu.fr * ******************************************************** From ccl@www.ccl.net Wed Nov 20 22:39:01 1996 Received: from bedrock.ccl.net for ccl@www.ccl.net by www.ccl.net (8.8.2/950822.1) id WAA08879; Wed, 20 Nov 1996 22:35:23 -0500 (EST) Received: from rani.chem.yale.edu for lim@rani.chem.yale.edu by bedrock.ccl.net (8.8.2/950822.1) id WAA11438; Wed, 20 Nov 1996 22:35:21 -0500 (EST) Received: by rani.chem.yale.edu; Wed, 20 Nov 96 22:35:23 -0500 From: Dongchul Lim Message-Id: <9611210335.AA01963@rani.chem.yale.edu> Subject: Re: CCL:CC software/Linux/Motif? To: chemistry@ccl.net (Computational Chemistry) Date: Wed, 20 Nov 96 22:35:22 EST In-Reply-To: ; from "Kenneth Geisshirt" at Nov 20, 96 4:28 pm X-Mailer: ELM [version 2.3 PL11] Kenneth Geisshirt writes: > > Hello. > > On Wed, 20 Nov 1996, Gustavo A. Mercier Jr wrote: > > > I need to find out in what ways to extend (or replace) XFree86 > > to support the widest range of CC applications, at a reasonable > > added cost. For example, 3rd party Xserver software vendors that > > include Motif and OpenGl, etc. > > Well, you can buy Motif and OpenGL. I would guess that both of them cost > about $200 each but I might be wrong. Motif has been ported to Linux/Xfree > by Metrolink and there are at least two companies offering OpenGL. Check > e.g. www.li.org or www.linux.org - they might have links to those > companies. > > OpenGL is - as far as I understand - VERY slow. The implementations on > Linux/Xfree are basically just emulators, i.e. they run on top of X11. A free OpenGL emulator for X called 'Mesa' is available. (http://www.ssec.wisc.edu/~brianp/Mesa.html) Most programs written using OpenGL can be linked with the Mesa library alternatively. They'll be slow because there's no graphics accelerator. > > Someone is working on a freeware implementation of Motif, but since I have > strong feelings against Motif (looks too much like M$-Windows to me), I > don't know the status of that project. Information on Lesstif, a free implementation of Motif, is available from http://www.hungry.com. It's under development. Actually, the only program that runs with Lesstif without problem is their game program, 'Phaser'. You'd have to purchase Motif to use Motif-based applications... From ccl@www.ccl.net Thu Nov 21 03:39:05 1996 Received: from bedrock.ccl.net for ccl@www.ccl.net by www.ccl.net (8.8.2/950822.1) id DAA14301; Thu, 21 Nov 1996 03:23:29 -0500 (EST) Received: from brage.si.sintef.no for Ole.Swang@si.sintef.no by bedrock.ccl.net (8.8.2/950822.1) id DAA13387; Thu, 21 Nov 1996 03:23:27 -0500 (EST) Received: from lillerud.si.sintef.no (lillerud.si.sintef.no [128.39.214.12]) by brage.si.sintef.no (8.7.5/8.7.3/1.11) with ESMTP id JAA02684 for ; Thu, 21 Nov 1996 09:23:25 +0100 (MET) From: Ole Swang Received: (from ole@localhost) by lillerud.si.sintef.no (8.7.5/8.7.3) id JAA04749; Thu, 21 Nov 1996 09:23:24 +0100 (MET) Date: Thu, 21 Nov 1996 09:23:24 +0100 (MET) Message-Id: <199611210823.JAA04749@lillerud.si.sintef.no> To: chemistry@ccl.net Subject: METECC Dear fellow computational chemists, I would greatly appreciate any information on the METECC software. Searching the WWW and the CCL archives yielded a couple of mail addresses, but either my messages bounced or they went unanswered. Thanks in advance, Best regards, Ole Swang ------------------------------------------------------------------------- Ole Swang Research Scientist, Dr. Scient. Dept. of Hydrocarbon Process Chemistry, SINTEF Applied Chemistry POB. 124 Blindern, N-0314 Norway. Phone: +47 22 06 74 29 Fax: +47 22 06 73 50 Email: ole.swang@chem.sintef.no ------------------ ._.. ._ ..___ ._ __.. ----------------------------- From arthur@csb0.IPC.PKU.EDU.CN Wed Nov 20 06:38:54 1996 Received: from csb0.IPC.PKU.EDU.CN for arthur@csb0.IPC.PKU.EDU.CN by www.ccl.net (8.8.2/950822.1) id GAA26751; Wed, 20 Nov 1996 06:17:11 -0500 (EST) Received: by csb0.IPC.PKU.EDU.CN (920330.SGI/940406.SGI.AUTO) for chemistry@www.ccl.net id AA22393; Wed, 20 Nov 96 19:16:43 -0800 Date: Wed, 20 Nov 1996 19:16:41 -0800 (PST) From: Arthur Wang To: CCL mailing list Cc: Structrual Biology List Subject: Free database for small molecules Message-Id: Dear Netters, Does anyone know where we can get free databases on the net? We have special interests in those composed of small molecules, such as Available Chemical Directory (ACD) and so on. Any clues will be appreciated. I will put back the summary. Arthur Wang _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ Arthur Wang Doctoral Candidate _/ _/ Molecular Design Lab _/ _/ Institute of Physical Chemistry, Peking University _/ _/ Beijing 100871, P.R.China _/ _/ _/ _/ E-mail: arthur@ipc.pku.edu.cn _/ _/ Tel: 86-10-2751490 Fax: 86-10-2751725 _/ _/ WWW: http://www.ipc.pku.edu.cn/moldes/arthur/home.html _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From MAILER-DAEMON@www.ccl.net Wed Nov 20 09:39:01 1996 Received: from schiele for MAILER-DAEMON@www.ccl.net by www.ccl.net (8.8.2/950822.1) id JAA27679; Wed, 20 Nov 1996 09:07:15 -0500 (EST) Received: by schiele (950911.SGI.8.6.12.PATCH825/940406.SGI.AUTO) for CHEMISTRY@www.ccl.net id PAA15102; Wed, 20 Nov 1996 15:06:36 +0100 From: "Wolf-Dietrich Ihlenfeldt" Message-Id: <9611201506.ZM15100@eros.ccc.uni-erlangen.de> Date: Wed, 20 Nov 1996 15:06:34 +0100 In-Reply-To: "Dmitry E. Dmitriev" "CCL:Molecule Builder : Linux version bug" (Nov 19, 12:33) References: <199611181433.PAA20284@odysseus.informatik.uni-stuttgart.de> <32917EE3.123A71B6@nmr1.ioc.ac.ru> Reply-To: wdi@eros.ccc.uni-erlangen.de X-Phones: +49-9131-85-6579 X-Fax: +49-9131-85-6566 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: CHEMISTRY@www.ccl.net Subject: Re: CCL:Molecule Builder : Linux version bug On Nov 19, 12:33, Dmitry E. Dmitriev wrote: > Subject: CCL:Molecule Builder : Linux version bug > Dear netters, > > Is anybody there who try to run Linux version of CACTVS? I need help. > When i try to run any application from package, i got a error: > > /usr/local/lib/cactvs/tkserver: can't resolve symbol '_h_errno' > Segmentation fault > > Installation process produced no errors or warnings. > I wrote to authors, but got no answers... No. You did. Just a few days later. I was out of town. This is a known problem with an outdated dynamic C runtime library. Upgrade, and the problem will vanish. > System - Linux 1.2.13. > Dmitry > -- > ************************************************************************ > * Dmitry E. Dmitriev * Moscow , Russia * > >-- End of excerpt from Dmitry E. Dmitriev -- Dr. Wolf-D. Ihlenfeldt Computer Chemistry Center, University of Erlangen-Nuernberg Naegelsbachstrasse 25, D-91052 Erlangen (Germany) Tel (+49)-(0)9131-85-6579 Fax (+49)-(0)9131-85-6566 --- The three proven methods for ultimate success and fame: 1) Nakanu nara koroshite shimae hototogisu 2) Nakanu nara nakasete miseyou hototogisu 3) Nakanu nara naku made matou hototogisu