From chemistry-request@ccl.net Thu Dec 5 11:15:48 1991 Date: Thu, 5 Dec 1991 10:07 EST From: GRX1010@uoft02.utoledo.edu Subject: AMBER, solvents To: chemistry@ccl.net Status: R Dear AMBER users: Our group is beginning a molecular dynamics study of large molecules in solution. We would like to know if anyone has ever tried doing molecular dynamics with AMBER for systems with explicit solvents other than water (i.e., by treating the solvent-solute system as a "solute", or some other method). We are interested in using the solvent chloroform, preferably as a periodic box. I assume that in order to use a periodic box of chloroform, the Edit code of AMBER 4.0 would require considerable user modification which may be non-trivial. We would like to know if someone has already done this or can readily point out the necessary changes. We are aware that the Gibbs module handles periodic boundary conditions for solvents other than water, but the data required for the boundary conditions is passed from Edit and Parm. Or perhaps treating an entire solvent-solute system as a "solute" in AMBER would be reasonable (with the solvent molecules truncated to a given distance around the solute). In this case, the user would initially have to place the solute in the solvent and eliminate the solvent molecules which overlap with the solute--which might be done with the aid of a graphics program. One of our limitations is that we cannot afford expensive graphics programs but we will have access to Biograf. Perhaps it would be more expedient to use a program such as GROMOS or another MD program, and if so, does anyone have an address to write to to obtain such a program? (Does anyone know of a good MD program which incorporates explicit solvent models other than water?) We are only interested in explicit solvent models rather than implicit ones. Any words of wisdom regarding this would be appreciated. If there is enough interest, I will post a summary for the group. Ruth E. Nalliah grx1010@uoft02.utoledo.edu Department of Chemistry University of Toledo From jkl@ccl.net Thu Dec 5 11:27:10 1991 Date: Thu, 5 Dec 91 09:48:18 -0500 From: jkl@ccl.net Subject: Re: Massively Parallel Machines To: chemistry@ccl.net Status: R Forwarding some additions to the Massively Parallel Machines kindly submitted by Richard Gillilan: ---------- Begin Forwarded Message ---------- >From reg@chem.UCSD.EDU Wed Dec 4 19:16:51 1991 >From: reg@chem.UCSD.EDU (Richard E. Gillilan) >Subject: Re: Massively Parallel Machines >To: jkl@ccl.net >Date: Wed, 4 Dec 91 15:37:45 PST >Cc: jle@world.std.com > > >> Joe Leonard submitted a digest of parallelization efforts and I am >> forwarding it to the list(jkl@ccl.net). It is long, but worth reading >> every bit of it. Some of the messages appeared previously on the list. >> Thank you, Joe >> Jan >> jkl@ccl.net >> ================================================================== > >Here are a couple older references you may want to include: > >K.R. Wilson: "Multiprocessor Molecular Mechanics," Computer Networking >and Chemistry, ed. P. Lykos, ACS Symposium Series. Washington, D. C.: >American Chemical Society, 1975; p. 17 > >K.R. Wilson: "Many-Atom Molecular Dynamics with an Array Processor," >in Minicomputers and Large Scale Computations, ed. P. Lykos, >ACS Symposium Series, 57. Washington, D.C.: American Chemical Society, >1977; p. 147. > >----------------------------------- >Richard Gillilan >Postgraduate Research Chemist, UCSD >reg@sdchemw2.ucsd.edu ----------- End Forwarded Message ----------- From chemistry-request@ccl.net Thu Dec 5 14:55:42 1991 Date: Thu, 5 Dec 1991 14:37 EST From: "DOUGLAS A. SMITH" Subject: ACS Abstracts To: chemistry@ccl.net Status: R Can any one tell me who get the PHYSICAL and ORGANIC abstracts for the San Francisco meeting? Names, addresses, phone numbers and email addresses are all useful. Thanks. Doug Smith Assistant Professor of Chemistry The University of Toledo Toledo, OH 43606-3390 voice 419-537-2116 fax 419-537-4033 From chemistry-request@ccl.net Thu Dec 5 14:55:46 1991 Date: Thu, 5 Dec 1991 21:35:59 +0200 From: Leif Laaksonen To: chemistry@ccl.net, jle@world.std.com Subject: Re: Application development (entirely) in C Status: R Hi Joe, What do you mean by chemistry code? If you mean graphics code then most of the code is written in c or c++ (I belive) but if you refer to the so called number crunching then most of the code is still done in fortran (I believe). As far as I know there are work going on for rewriting old MD/MM code into c. I would be happy to see how close good c-coding comes to old fortran coding in the sence of computation efficiency. The tests I made on our Cray showed that good vector fortran coding is still much faster than my c-code. Does anybody know if this is still the case? On normal workstations the c-code should be pretty close to fortran code. I don't know what people think but as an old fortran programmer I now do everything in c and I really would never change back to fortran. Cheerio, -leif laaksonen From chemistry-request@ccl.net Thu Dec 5 16:01:29 1991 Date: Thu, 5 Dec 91 15:56:09 EST From: shenkin@avogadro.barnard.columbia.edu (Peter S. Shenkin) To: Leif Laaksonen , jle@world.std.com, Subject: Re: Application development (entirely) in C Status: R > From: Leif Laaksonen > As far as I know there are work going on for rewriting old MD/MM code into c. I replied personally to Joe, but I might as well mention in public that I now even write my protein modeling code in C. Part of the reason for this is that even though certain aspects of numerical computations are easier in Fortran, in fact most of the lines of code involve book-keeping operations of various sorts, and I find this easier in C. Fortran-90 looks like it has some interesting features, though. Also, Jan Hermanns recently told me that he codes exclusively in C now; this is MD code. (Jan, if you're out there, sorry for taking your name in vain.) > I would be happy to see how close good c-coding comes to old fortran coding > in the sence of computation efficiency. The tests I made on our Cray showed > that good vector fortran coding is still much faster than my c-code. Does > anybody know if this is still the case? On normal workstations the c-code > should be pretty close to fortran code. This is discussed all the time in the Usenet group comp.lang.fortran, much to the chagrin of regular readers, who are tired of the topic by now. The consensus is that there is no consensus, and the discussion rapidly devolves into a religious war. Some people say their code runs as fast or faster in C, and some people claim that their Fortran code runs much faster; some of these are vector people, but not all. And Fortran has certain language specs that make it easier for a compiler to optimize certain constructions. Chief of these features is that no two subroutine output parameters can overlap. (I think I've got this right.) Also, please be aware that there are such things as vectorizing C compilers, by Convex for example, and it would be interesting to see how vectorized C compares with vectorized Fortran code, in addition to comparing the scalar codes. There is also something called NCEG: the Numerical C Extension Group, which is in business to suggest extensions to C that will make numerical programming easier. Typical of the issues they discuss are: Can C be extended to accept real arrays as function arguments, as in: subr(a, b, n) int n; float a[n], b[n]; { etc. } this certainly makes life easier if you want to do something like write a general matrix multiplication routine in C; right now you have to use pointer notation, and in addition you have to be rather clever and write some ugly looking code to make it work efficiently. Can constructs be added to C to tell the compilers which (if any) parmeters of a given function might overlap; eg: subr(a, b) float a[], b[]; no_overlap(a,b); { etc. } This might be defined to mean that the parts of a and b that are used in the subroutine are guaranteed to be disjoint. Can constructs be added that allow better checking of IEEE floating point results -- eg, NaNs, signaling NaNs, etc. > I don't know what people think but as an old fortran programmer I now do > everything in c and I really would never change back to fortran. I still use fortran for quick and dirty numerical code that's going to be used for only a short time for a limited number of tasks. But I use C for code that must be maintained and is expected to grow. You gotta admit that C code just looks so much cooler! :-) Also, I believe that Thinking Machines, Inc. has announced that Fortran 90 will be the main development environment on their machines. Finally, somebody (if you know who, please speak up!) once said, "I don't know what the computer language of the future will look like, but it will be called Fortran." If Fortran-90 makes it, this statement might prove true in all regards. -P. ************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb************************* Peter S. Shenkin, Department of Chemistry, Barnard College, New York, NY 10027 (212)854-1418 shenkin@avogadro.barnard.columbia.edu shenkin@cunixc.BITNET ********** "I've got algorithm -- who could ask for anything more?" ********** From chemistry-request@ccl.net Thu Dec 5 17:40:00 1991 Date: Thu, 5 Dec 91 16:43:09 CST From: shepard@dirac.tcg.anl.gov (Ron Shepard) To: chemistry@ccl.net Subject: Fortran vs. C: Do we REALLY want to start this discussion? Status: R Regarding FORTRAN vs. C, there is a quite readable article by T. MacDonald in The Journal of Supercomputing, 5, 31-38 (1991) entitled "C for Numerical Computing". In my opinion, it is slanted slightly in favor of C, but he also notes some of the more obvious advantages of Fortran syntax such as variable-dimensioned arrays and user-specified subscript ranges. A primitive COMPLEX data type is also important for those who need it -- because of the possibility of introducing conflicts with user-defined structures in existing code, it appears rather difficult to simply add this syntax to the C language. With respect to runtime efficiency of the code that is produced, Fortran has several advantages over C, the most significant probably being C's use of "wild pointers". This prevents many optimizations that Fortran programmers take for granted from being even possible with C. This is discussed in fact on page 69 of the RATIONALE section of the C standard (ANSI X3.159-1989). Of course, many dialects of Fortran support "tame" pointers already, and Fortran 90 standardises the syntax of assignments and other manipulations of pointers. MacDonald discusses the possible introduction of a "restricted pointer" to the C syntax that would eliminate the hidden alias problem in C, but such solutions would only apply to new code, and not retroactively to existing code. It seems to me that the biggest reason some people prefer C to fortran is not really the language itself, but rather the close integration of the C preprocessor. Since the behavior of the preprocessor is specified in the C standard, C advocates usually argue that it is part of the language, whereas Fortran advocates prefer conceptually to separate the two entities. In either case, the preprocessor allows the programmer to avoid many of the portability problems that seem to be purposefully built into FORTRAN 77 (such as the lack of a declaration that allows one to write standard-conforming code that runs in the desired manner on an arbitrary set of 32-bit and 64-bit machines). It will be interesting to see if Fortran 90 syntax is sufficiently powerful in these respects to compensate for the lack of a standard preprocessor. With the introduction of vector-register computers 15 years ago, it became IMPOSSIBLE to write optimal code in either Fortran or C for many simple algebraic operations. Consider for example, a simple matrix-matrix product, which can be written with either a dot product inner-most loop or a saxpy-type inner-most loop. Vector-register machines such as the Cray prefer the saxpy loop, while most other machines (including most RISC machines) prefer the dot-product ordering. It doesn't matter if you write DO-loops in fortran, FOR-loops in C, use one-dimensionalized arrays, or pointer arithmetic, it is IMPOSSIBLE to write code that compiles optimally on all machines. The only way to get optimal code is for the compiler (or a preprocessor) to somehow recognize your loop-based code and to substitute the appropriate library operation. With all the possibilities of transpositions and subblocking, this is quite a challange! Why must we, as developers and programmers, (1) take our equations which are often formulated in terms of matrix and vector operations, (2) convert them to loop-based code (an error-prone process that usually requires much more debugging than coding), and (3) cross our fingers and hope that the compiler "recognizes" it and turns it back into the original matrix expression? We shouldn't, and with Fortran 90, we finally, after 15 years, have a language that allows us to turn our equations directly into code. In this respect, the only remaining question is how well the vendors are going to support this capability. What does this have to do with Fortran and C? Fortran 90 puts C TWO generations behind instead of just one. If it took us 15 years to finally get array syntax standardized in Fortran, how much longer would it take us to get it, along with variable-dimensioned arrays and user-defined subscript ranges, into C? I'm not sure that I want to know. (:-) -ron shepard shepard@tcg.anl.gov From chemistry-request@ccl.net Thu Dec 5 22:22:48 1991 Date: Thu, 5 Dec 91 19:22:44 -0800 From: ross@zeno.mmwb.ucsf.EDU To: chemistry@ccl.net Subject: gene patents Status: R My apologies in advance to those who would rather avoid policy discussions on the net. _Science_ 22 Nov: ... NIH researcher Craig Venter, who is identifying and sequencing nearly a thousand of the gene fragments a month, has no idea what the vast majority of them are. He simply buys a "library," or collection of complementary DNA (cDNA) clones representing genes active in the human brain, then randomly fishes out the clones and sequences a few hundred bases of each, a fairly trivial task on an automated sequencing machine. ... Venter and NIH ... filed a patent application on the first 350 of these fragments, laying claim not just to the fragment but to the entire gene and the protein it encodes... ... second patent application on about 2000 additional cDNA fragments... [NIH Director Bernadine Healy says] the question is not whether to file "but when and how to file the next patent or series of patents." First, I don't like the idea of patenting "natural" genes. This is a grey area, since evolutionary selection might be applied to achieve something rare enough that I would feel was patentable, but in this case no selection is involved. Nor do I like the idea of issuing patents where the understanding of what is being patented is nil, and particularly when the work is so slight. This is almost as bad as patenting random sequences of bases or binary bits in case they turn out to mean something. I hope the patent office rejects this application, e.g. on the grounds that it is too obvious (the genome project is an instance of people already recognizing the utility of knowing the genes, and anyone can apply current technology to do the sequencing). If this patent is granted, will we have to pay royalties on money we make >from our thought processes, since they employ the proteins encoded for? Does anyone have more details on the application? Bill Ross