From campagne@incm.u-nancy.fr Tue Jul 29 06:14:10 1997 Received: from brown.incm.u-nancy.fr for campagne@incm.u-nancy.fr by www.ccl.net (8.8.3/950822.1) id FAA19516; Tue, 29 Jul 1997 05:54:12 -0400 (EDT) Received: from yellow.incm.u-nancy.fr by brown.incm.u-nancy.fr via ESMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for <@brown.incm.u-nancy.fr:chemistry@www.ccl.net> id LAA20309; Tue, 29 Jul 1997 11:55:11 +0100 Received: from yellow.incm.u-nancy.fr (localhost [127.0.0.1]) by yellow.incm.u-nancy.fr (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA02655 for ; Tue, 29 Jul 1997 11:55:09 +0100 Sender: campagne@incm.u-nancy.fr Message-ID: <33DDCC0C.41C6@incm.u-nancy.fr> Date: Tue, 29 Jul 1997 11:55:08 +0100 From: Fabien Campagne Organization: Laboratoire de Chimie The'orique de Nancy X-Mailer: Mozilla 3.0SC-SGI (X11; I; IRIX64 6.2 IP28) MIME-Version: 1.0 To: chemistry@www.ccl.net Subject: CCL: Design/OO/standardization Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I found that the discussion about Object Oriented design and programming for Computational Chemistry software was interesting and raised one or two point I'd like to emphasize. Development of software for Computational Chemistry by researchers is usualy focused on new methodologies. That's a matter of specialization: people who develop and maintain scientific software have less time to use these software to applied research than people interested in applications only. These two communities have distinct needs: method development community needs software easy to extend and change, from their point of view, in order they could try one idea they have in a few days, not in a few months.. Code, if the idea is valuable, does not need, at that point, to be portable, user-friendly, or whatever. Code needs to demonstrate, on a few examples, that the idea is valuable,.. no more. application community,.. well,.., would like to work on a variety of hardware and operating systems, from a microcomputer to a paralel computer, with a fully validated software, that is very user-friendly and... free :-) This two aspects of Computational Chemistry are quite difficult to make live together. Usualy commercial companies help to make the interface between new methods and application people: they take a new method, add it to their integrated environment and sell the result.. A few problem arise when such a company have to deal with a software that was so poorly designed at the begginning that it would be necessary to write it again from scratch to make a good integration to their product line. Very often if a software present this problem and is big, the choice is to sell it as it is, with minor enhancements (no more platform supported by the original product, weak integration to the product line...). In my opinion, design and standardisation may help the three communities: new method development would make profit of a better design (more on this at the end of this text), commercial software integrators would be able to use the flexibility induced by the design to better adapt the software to application users. And these latter users will benefit from an increased quality of the overall software (available through com. soft. int. or directly from the labs) and from shorter development times. The "new methods community" needs access to third party developed software so researchers won't loose time implementing again what was alraeady done by others. That's exactly the same thing for software than for methods: I know nobody that will claim again the discover of the conjugated gradient minimisation method.. but a lot of people will tell you they HAVE HAD TO implement it again for their own research -- even though one hundred of these implementations may exist around the world, written in fortran, C or something else -- The problem is not only the design. The problem is that usualy, the interface, ie the way to reuse the implementation, is not described properly. Computer scientific community uses standardization commitees that consist of experts in one field talking together until they agree on a standard: ONE way to do something that meet experts idea of what is important (performances, reusability, extensability..). At the end of the standardization, the standard is documented and , quite often, implemented. In fact, partial implementations helps the discussions, demonstrating or invalidating one or another design. This may take some time (it usualy do) but the result is available to everybody, clearly documented, and once available, anybody can build on top of it. What about standardizing interfaces for common algorithms ? It seems to me that a minimization algorithm looks like another and should be used the same way from the code I'm writing (whatever the implementation I actually decide to retain) I mean: why should I change the part of the source code that gives parameters for a minimization (max. number of steps, threesold, system to minimize) if I decide to change the minimization algorithm. Couldn't we design our software so that algorithms are parameters for algorithms (at compile time). Maybe an example could be valuable here: do_a_minimization (system s){ m.maxSteps(10000); m.threesold(0.0001); m.system(s); m.minimize(); } there will be no need to change this code, if latter, I write an application that uses this standard interface and like to do: do_a_minimization(my_sys); or if I prefer: do_a_minimization(my_sys); The implementation will be completely different of course from one line to the other, while the source remain quite the same (changes what need to be changed, no more). That's just an idea of course, but what about thinking carefully about such interfaces to common algorithms, document them, implement the interfaces to our old -- but still worthwhile -- codes and use them while cheking new ideas (if the idea is good, we'll create a standard for it latter..). Taking this approach with an OO language may help the portability: modules of the software that need to be changed for each platform have to be isolated by the design, their type refined (inheritance implied) for each plateform, and the right type (for target plateform) used at compile time. Well, I didn't go into technical details, but if anybody is interested in taking part to technical discussions about such a standardization, or have pointers/references to tentative of standardization (this means at least two implementations sharing the same interface) relative to Computational Chemistry software (personnal interest in molecular modeling methods and algorithms), please email directly to me. I'll summarize and maintain a few web pages about the results of the discussions. Fabien Campagne -- campagne@incm.u-nancy.fr | Lab. de Chimie Theorique phone: +33 (0)3 83 91 20 00 extension 3236 | Nancy, France. http://www.lctn.u-nancy.fr/viseur/FC.html From tobisch@WAPagcc.urz.uni-halle.de Tue Jul 29 10:14:13 1997 Received: from WAPagcc.urz.uni-halle.de for tobisch@WAPagcc.urz.uni-halle.de by www.ccl.net (8.8.3/950822.1) id JAA20371; Tue, 29 Jul 1997 09:43:51 -0400 (EDT) Received: by WAPagcc.urz.uni-halle.de (940816.SGI.8.6.9/940406.SGI.AUTO) for CHEMISTRY@www.ccl.net id PAA29145; Tue, 29 Jul 1997 15:36:48 +0200 Date: Tue, 29 Jul 1997 15:36:48 +0200 From: tobisch@WAPagcc.urz.uni-halle.de (Dr. Sven Tobisch) Message-Id: <199707291336.PAA29145@WAPagcc.urz.uni-halle.de> To: CHEMISTRY@www.ccl.net Subject: MOLCAS question Dear colleagues, there is a question on the whole MOLCAS-3 user community. Within the STEWARD Integral program the following error message appears: *** (S)-level message MKSRT1002 *** nBin exceeds the limit mxBin nBin = 517 ; mxBin = 256 Increase dimension mxBin and try again What does it mean and how can this error be circumvented ? It should be noted, that it is unable to me to simply modify some array declarations in the sources, because we only have executables. Any help or hints are highly appreciated. - Sven From reichertd@mirlink.wustl.edu Tue Jul 29 13:14:14 1997 Received: from wugate.wustl.edu for reichertd@mirlink.wustl.edu by www.ccl.net (8.8.3/950822.1) id MAA21360; Tue, 29 Jul 1997 12:47:15 -0400 (EDT) Received: from mirlink.wustl.edu (mirlink.wustl.edu [128.252.155.1]) by wugate.wustl.edu (8.8.5/8.8.5) with SMTP id LAA26507 for ; Tue, 29 Jul 1997 11:47:17 -0500 (CDT) Message-ID: Date: 29 Jul 1997 11:44:43 -0500 From: "David Reichert" Return-Receipt-To: "David Reichert" Subject: Parameterization Tools To: "CCL post" X-Mailer: Mail*Link SMTP-MS 3.0.2 I'm looking for some info and/or code to help automate the development of forcefield parameters, hopefully the list readers can provide some leads. Given a set of x-ray or NMR structures and/or results from ab initio calculations are there programs that can automate the development of parameters for a given forcefield, ie eq bondlengths, angles, stretching constants etc... Any pointers would be greatly appreciated. (I'm getting tired of doing this by hand, there must be a better tool somewhere !) thanks, Dave (I apologize if this gets posted twice, e-mail problems) ************************************************ * David E. Reichert, Ph.D. * * Mallinckrodt Inst. of Radiology * * Div. Radiological Sciences, * * Washington University School of Medicine * * 510 S. Kingshighway Blvd., Campus Box 8225 * * St. Louis, MO 63110 * * * * phone: (314)362-8461 * * fax: (314)362-9940 * * e-mail: reichertd@mirlink.wustl.edu * ************************************************ From dransfld@organik.uni-erlangen.de Tue Jul 29 13:23:28 1997 Received: from faui45.informatik.uni-erlangen.de for dransfld@organik.uni-erlangen.de by www.ccl.net (8.8.3/950822.1) id MAA21353; Tue, 29 Jul 1997 12:45:43 -0400 (EDT) Received: from derioc1.organik.uni-erlangen.de (derioc1.organik.uni-erlangen.de [131.188.128.1]) by uni-erlangen.de with SMTP id SAA11037 (8.7.6/7.5c-FAU); Tue, 29 Jul 1997 18:45:36 +0200 (MET DST) Received: (from dransfld@localhost) by organik.uni-erlangen.de id SAA20808 (8.6.12/7.4f-FAU);; Tue, 29 Jul 1997 18:45:27 +0200 From: Alk Dransfeld Message-Id: <199707291645.SAA20808@derioc1.organik.uni-erlangen.de> Subject: Re: CCL:G:NICS ? To: chemistry@www.ccl.net Date: Tue, 29 Jul 1997 18:45:26 +0200 (MET) Cc: dransfld@organik.uni-erlangen.de (Alk Dransfeld), choic@gusun.acc.georgetown.edu X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit On Mon, 28 Jul 1997 19:24:35 Cheol Choi wrote: > Subject: CCL:G:NICS ? > Dear CCLers, > Is anybody out there how to calculate the NICS (Negative > nucleus-independent chemical shift) using G94 results? > Thanks, > Cheol-Ho Choi > Georgetown Univ. Dear Cheol, the authors of the basic NICS paper (J. Am. Chem. Soc., 1996, 6317) have a tool for generating NICS computation inputs at http://www.ccc.uni-erlangen.de/local/tools/xyz2dmm93.html and provide some background information on NICS at http://www.ccc.uni-erlangen.de/research/published/at/WATOC96/nics/ . The tool for generating NICS inputs for GAUSSIAN94 is under construction (comments are welcome) at http://www.ccc.uni-erlangen.de/manuals/GAUSSIAN/NICS_input.html . Looking forward to successful application of NICS as Simple and Efficient Aromaticity Probe Best regards A. Dransfeld > -- > # ALK Dransfeld # Tel: +49 9131 85 6534 # > # FAX: +49 9131 85 6566 # > # URL= http://131.188.128.1/~dransfld/ # > -- # ALK Dransfeld # Tel: +49 9131 85 6534 # # FAX: +49 9131 85 6566 # # URL= http://131.188.128.1/~dransfld/ # From wall@phys.chem.ethz.ch Tue Jul 29 13:27:22 1997 Received: from bacon.ethz.ch for wall@phys.chem.ethz.ch by www.ccl.net (8.8.3/950822.1) id MAA21306; Tue, 29 Jul 1997 12:29:54 -0400 (EDT) Received: (from wall@localhost) by bacon.ethz.ch (8.8.6/8.8.6) id SAA17414; Tue, 29 Jul 1997 18:29:51 +0200 (CEST) Date: Tue, 29 Jul 1997 18:29:51 +0200 (CEST) Message-Id: <199707291629.SAA17414@bacon.ethz.ch> From: Ernst-Udo Wallenborn To: chemistry@www.ccl.net, tobisch@WAPagcc.urz.uni-halle.de (Dr. Sven Tobisch) Subject: CCL:MOLCAS question In-Reply-To: <199707291336.PAA29145@WAPagcc.urz.uni-halle.de> References: <199707291336.PAA29145@WAPagcc.urz.uni-halle.de> Sven Tobisch writes: >Dear colleagues, > >there is a question on the whole MOLCAS-3 user community. >Within the STEWARD Integral program the following error >message appears: > > *** (S)-level message MKSRT1002 *** > nBin exceeds the limit mxBin > nBin = 517 ; mxBin = 256 > Increase dimension mxBin and try again > >What does it mean and how can this error be circumvented ? >It should be noted, that it is unable to me to simply modify >some array declarations in the sources, because we only have >executables. it means that seward has at least one array which was declared to have mxBin elements. Since fortran doesn't know dynamical allocation this means that if you request a bigger array size the program will (at best) coredump. afaik there is no way to enlarge seward beyond this limit without recompiling it. I ran into the same problem a year ago, couldn't get our folks to recompile and was finally told by a friend who works in the roos group that i'd better wait for molcas-4, which was planned to have direct integral algorithms (eliminating this problem altogether). According to the molcas web page the release date of molcas-4 will be august, 1st (that's next friday). You might try to convince your folks to upgrade. From JeffAyres@worldnet.att.net Tue Jul 29 16:14:17 1997 Received: from mtigwc03.worldnet.att.net for JeffAyres@worldnet.att.net by www.ccl.net (8.8.3/950822.1) id PAA22415; Tue, 29 Jul 1997 15:47:18 -0400 (EDT) Received: from LOCALNAME ([207.147.169.133]) by mtigwc03.worldnet.att.net (post.office MTA v2.0 0613 ) with SMTP id AAA14801 for ; Tue, 29 Jul 1997 19:46:48 +0000 Message-ID: <33DE495B.6969@worldnet.att.net> Date: Tue, 29 Jul 1997 12:49:47 -0700 From: "Jeffrey J. Ayres" Organization: independent X-Mailer: Mozilla 3.0 (Win16; I) MIME-Version: 1.0 To: chemistry@www.ccl.net Subject: converting cacao output files html Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello cclers, Is there a way to convert cacao output files, for example MO diagrams, into a .bmp or .jpg file other than a snapshot of the screen? Thanks, Jeff Ayres From jeff@bnpi.com Tue Jul 29 16:21:38 1997 Received: from mail.bnpi.com for jeff@bnpi.com by www.ccl.net (8.8.3/950822.1) id PAA22173; Tue, 29 Jul 1997 15:15:25 -0400 (EDT) Received: from beavis.bnpi.com ([198.213.32.3]) by mail.bnpi.com via smtpd (for www.ccl.net [192.148.249.5]) with SMTP; 29 Jul 1997 19:16:51 UT Received: from b27.bnpi.com (jeff [198.213.32.6]) by bnpi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA15767 for <@beavis.bnpi.com:chemistry@www.ccl.net>; Tue, 29 Jul 1997 14:16:17 -0600 Received: (from jeff@localhost) by b27.bnpi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA26159 for chemistry@www.ccl.net; Tue, 29 Jul 1997 14:16:10 -0500 From: "Jeff D. Saxe" Message-Id: <9707291416.ZM26157@b27.bnpi.com> Date: Tue, 29 Jul 1997 14:16:10 -0500 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: chemistry@www.ccl.net Subject: summary: Connolly surfaces Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii I recently asked for a program which can read a pdb or xyz file and display Connolly surfaces, preferably on an SGI, or possibly on a PC. I received many responses. Some of the software listed below is free and immediately available on the net (the ideal situation), some is available only to academic institutions, and some is available to anyone for a price. Thanks to everyone who responded. I've tried a couple and they are pretty good. Here are the responses: From: Patricia M Fulmer Have you tried GRASP by Anthony Nicolls? http://tincan.bioc.columbia.edu/Lab/grasp/ From: Dorina Kosztin If by Connolly surface you mean solvent accessible surface, then VMD or Grasp programs, both running on SGI, will do it for you. For the VMD program, look at http://www.ks.uiuc.edu/Research/vmd. It's a free software and it's very easy to install. From: Asim Kumar Debnath Try the MS-Connolly program from QCPE (QCPE #429). I think it is free. Quantum Chemistry Program Exchange Creative Arts Bldg. 181 Indiana University Bloomington, IN 47405 Tel: (812) 855-5539 Fax: (812) 855-4784 email: qcpe@ucs.indiana.edu From: pelleque@scripps.edu (Jean-Luc Pellequer) There are a couple of well known programs: InsightII from MSI: use the user:get command (read the format for the dot file) Turbo-Frodo can read directly an output from the MS (connolly) program as well as read a PDB file. Turbo-Frodo is developed at the University of Marseilles. From: Rita Arutsian - MolSoft info The ICM program allows to build, display Connolly surfaces. The program uses the fastest algorithm published recently (Totrov, M.M. & Abagyan, R.A. (1996). The contour-buildup algorithm to calculate the analytical molecular surface. J. Struct. Biol., 116, 138-143.) and is about an order of magnitude faster than the alternative program. Note that ICM creates a true analytical molecular surface rather than a rough numerical one (usually built by so called marching cubes algorithm). Some images of the molecular surface can be found on our site (http://molsoft.com). ICM can do the following: * build the analytical molecular surface (takes seconds for a protein) for any subset of atoms * display and color this surface in many different ways * combine it with other molecular representations * write this image in a VECTORIZED postscript form (rather than a pixelized image) * split it into individual shells, identify cavities and measure their volume and surface * write it in a Wavefront format or in a POV format If you are not interested in other features of the ICM program, we can offer a truncated version of what you exactly need for a steeply discounted price. From: Dr. Bruno Manunza Have you tried the MSP package from M. Connolly or the M. Sanner MSMS & MSV? Both run on SGI. You may find links to these and other surface computing packages on our software list page at http://antas.agraria.uniss.it Also, have a look at our Tutorials page where a review from Connolly plus some other tutorials on surface computing are linked. From: Luigi Cavallo Try Naccess v2.0 - Atomic solvent accessible areas written by Simon Hubbard, at http://www.biochem.ucl.ac.uk/~roman/naccess/naccess.html It computes Lee and Richards exact surface from a pdb file. It is fast and simple to use. I compiled it on a DEC ultrix. On an IBM RS/6000 it didn't compile properly. On the SGI no idea at all. From: Raf Bruyndonckx The program MOLEKEL is able to read pdb format and plot Connolly surfaces. Have a look at: http://www.cscs.ch/Official/VisMolekel.html From: Richard Woods (?) I believe that Web Lab Viewer for Windows, available at the MSI web site, will do it. (See http://www.msi.com/weblab/index.html) -- Jeff D. Saxe jeff@bnpi.com BioNumerik Pharmaceuticals, Inc. Suite 1250 8122 Datapoint Dr. San Antonio, TX 78229 210-614-1701 (phone) 210-615-8030 (fax) From SATYAM@vms.cis.pitt.edu Tue Jul 29 19:14:21 1997 Received: from myriad.cis.pitt.edu for SATYAM@vms.cis.pitt.edu by www.ccl.net (8.8.3/950822.1) id SAA23172; Tue, 29 Jul 1997 18:19:31 -0400 (EDT) From: Received: from vms.cis.pitt.edu by vms.cis.pitt.edu (PMDF V4.3-10 #16365) id <01ILTGYFUJKW936EJL@vms.cis.pitt.edu>; Tue, 29 Jul 1997 18:19:31 -0400 (EDT) Date: Tue, 29 Jul 1997 18:19:31 -0400 (EDT) Subject: Which programs have LCMO methods implemented ? To: chemistry@www.ccl.net Message-id: <01ILTGYFVHHU936EJL@vms.cis.pitt.edu> X-Envelope-to: chemistry@www.ccl.net X-VMS-To: IN%"chemistry@www.ccl.net" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Dear Netters, Please provide the name of Program(s) which have LCMO (Linear combination of MOLECULAR ORBITALS) method implemented at the SEMIempirical level of Quantum Theory. Thanks Satyam (satyam@vms.cis.pitt.edu)