From chemistry-request@server.ccl.net Wed May 19 16:03:58 1999 Received: from gatekeeper.itqb.unl.pt (qmailr@gatekeeper.itqb.unl.pt [193.136.177.1]) by server.ccl.net (8.8.7/8.8.7) with SMTP id QAA05081 for ; Wed, 19 May 1999 16:03:53 -0400 Received: (qmail 30199 invoked from network); 19 May 1999 19:58:52 -0000 Received: from brutus.itqb.unl.pt (193.136.176.2) by gatekeeper.itqb.unl.pt with SMTP; 19 May 1999 19:58:52 -0000 Received: from model.itqb.unl.pt by brutus.itqb.unl.pt (5.65v4.0/1.1.8.2/30Apr98-1221PM) id AA16308; Wed, 19 May 1999 20:58:51 +0100 Message-Id: <3.0.6.32.19990519205820.007a9db0@brutus.itqb.unl.pt> X-Sender: claudio@brutus.itqb.unl.pt X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 19 May 1999 20:58:20 +0100 To: CHEMISTRY@ccl.net From: =?iso-8859-1?Q?Cl=E1udio?= Soares Subject: SPBf short course on simulation Cc: claudio@itqb.unl.pt Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.ccl.net id QAA05082 Dear CCL members The Portuguese Biophysical Society (SPBf) is organising its annual short course. This year the course in entitled: SIMULATION OF BIOLOGICAL PROCESSES. PRACTICAL APPROACHES. The course is mostly aimed at Portuguese and Spanish participants, although other people are also welcomed, given that the official language is English. More information about the course follows next. Regards Cláudio Soares -------------------------------------------------------------------------- Course Information 2nd short course of the Portuguese Biophysical Society SIMULATION OF BIOLOGICAL PROCESSES. PRACTICAL APPROACHES. 2-3 October 1999, ISLA Auditorium, Santarém http://www.itqb.unl.pt/~biophysics/course.html (With online registration) Organizers: C.M.Soares (ITQB-UNL), A.M.Baptista (ITQB-UNL), M.Castanho (FCUL), M.Prieto (IST-UTL) SCOPE: The aim of this course is to give an overview of the simulation techniques used in biological sciences. The course is oriented towards people working in the areas of biochemistry, biology, chemistry and related fields; the perspective will be application-oriented rather than theoretical. Topics will cover molecular dynamics simulation (classical and mixed quantum), molecular interactions, continuum electrostatic methods, protein structure prediction, membrane organization, reaction-diffusion systems, metabolic simulation and immune system modelling. PROVISIONAL PROGRAM AND SPEAKERS Friday, 1st October Registration and welcome reception (offered by Câmara Municipal de Santarém) Saturday, 2nd October Opening remarks Manuel Prieto - Chairman of the SPBf Instituto Superior Técnico, Universidade Técnica de Lisboa, Portugal The scope of simulation techniques in biophysics Cláudio M. Soares Instituto de Tecnologia Química e Biológica, Universidade Nova de Lisboa, Portugal Theoretical aspects of molecular mechanics/dynamics simulation. Some applications. Cláudio M. Soares Instituto de Tecnologia Química e Biológica, Universidade Nova de Lisboa, Portugal Hydrodynamics and Brownian dynamics. Theory and applications. José Garcia de la Torre Dep. Química Física, Universidad de Murcia, Spain Inter-molecular interactions in proteins P.Nuno Palma Dep.Química, Faculdade de Ciências e Tecnologia, Universidade Nova de Lisboa, Portugal Hybrid QM/MM studies of enzymatic systems Maria João Ramos Dep.Química, Faculdade de Ciências, Universidade do Porto, Portugal Continuum electrostatics in proteins: theoretical aspects and applications. António M. Baptista Instituto de Tecnologia Química e Biológica, Universidade Nova de Lisboa, Portugal Sunday, 3rd October Protein structure prediction. Homology modelling and sidechain prediction. Joaquim Mendes Instituto de Tecnologia Química e Biológica, Universidade Nova de Lisboa, Portugal Monte Carlo Simulation of Membrane Organization Ole G.Mouritsen Dep. Chemistry, Technical University of Denmark, Denmark A modelling and simulation approach to biological reaction-diffusion systems Joaquim Sainhas Faculdade de Motricidade Humana, Universidade Técnica de Lisboa & Instituto Gulbenkian de Ciência, Portugal Metabolic simulation Armindo Salvador Dep. Microbiology and Immunology, University of Michigan, U.S.A. Immune system modelling Jorge Carneiro Instituto Gulbenkian de Ciência, Portugal MORE INFORMATION CAN BE OBTAINED IN THE FOLLOWING WAYS: http://www.itqb.unl.pt/~biophysics/course.html (with online registration) e-mail: simul@itqb.unl.pt Tel: 351 1 4469610/613, Fax: 351 1 4433644 (Cláudio Soares, ITQB-UNL) Registrations until July 31. COURSE LOCATION: Santarém is an old town approximately 100Km north of Lisbon in the Ribatejo region of Portugal. The town is by the Tagus (Tejo) river. The course will take place at the ISLA Auditorium in the old part of Santarém, near the famous Igreja da Graça. REGISTRATION FEES: (PTE; includes the course dinner, October 2) Regular Student -------------------------------------- Non-members 12000 8000 Members SPB*/SBE** 9000 5000 Members SPBf*** 6000 2000 -------------------------------------- *Sociedade Portuguesa de Bioquímica+ **Sociedad de Biofísica de España ***Sociedade Portuguesa de Biofísica+ +You can register in the Society during the course 200.482 PTE = 1 EUR A limited number of grants will be available COURSE SPONSORS ISLA Santarém Câmara Municipal de Santarém Fundação para a Ciência e a Tecnologia Instituto de Tecnologia Química e Biológica - Universidade Nova de Lisboa, TRIPOS Inc Nextvision/SGI Micromineiro -------------------------------------------------------------------------- -------------------------------------------------------------------- Cláudio Soares | Instituto de Tecnologia | Química e Biológica |Phone:(351-1)4469610/4469100 6º Piso, Av. da Republica | Fax :(351-1)4411277 Apartado 127 |email:claudio@itqb.unl.pt 2781-901 OEIRAS Portugal |http://www.itqb.unl.pt/~claudio From chemistry-request@server.ccl.net Thu May 20 01:03:34 1999 Received: from ccl.net (atlantis.ccl.net [192.148.249.4]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id BAA09536 for ; Thu, 20 May 1999 01:03:28 -0400 Received: from pobox.csc.fi (pobox.csc.fi [128.214.46.62]) by ccl.net (8.8.6/8.8.6/OSC 1.1) with ESMTP id AAA22690 for ; Thu, 20 May 1999 00:58:26 -0400 (EDT) Received: from laaksonen.csc.fi (laaksonen.csc.fi [193.166.1.75]) by pobox.csc.fi (8.9.0.Beta5/8.9.0.Beta5/CSC/Rtrs-1.22) with ESMTP id HAA00227 for ; Thu, 20 May 1999 07:58:26 +0300 (EET DST) Date: Thu, 20 May 1999 07:59:34 +0300 (GTB Daylight Time) From: Leif Laaksonen To: CCL Mailing List Subject: First we took XML then we took RDF In-Reply-To: Message-ID: X-X-Sender: laaksone@laaksonen.csc.fi MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I have been following the discussion about XML on the CCList with great pleasure. Perhaps we chemists aren't that bad after all? The discussion has floated between many subjects, which all has been somehow connected to XML. However, when talking about making program output less difficult to be interpreted by computers we are talking about resource description. The W3 consortium has also done a great job in the resource description field. The vision is that in the future the resources would not just be readable by computers but also understandable to computers. The Resource Description Framework (RDF) is the answer to this problem. When we talk about tagging our program output in one or an other way we really mean that it should be in a form understandable by computers. If we go back and think about the root problem. We have the interaction between three fields: Information <==> Knowledge <===> Learning We have and produce all the time more information but we really don't know in detail the process how information is turned into knowledge. This is now a problem in the digital age when old analog information should be stored digitally. There isn't just enough space to store it! What we really are aiming at is to store the knowledge but how can we turn information into knowledge? We computational chemists are in a lucky positiopn because we have been modelling processes already for a long time. For example we don't have to document all laboratory measurements and other details about a chemical reaction because we know the theoretical machinery behind it and we can always reproduce it using our models and equations. The steps between knowledge and learning is to some extent known through the work people are doing in the pedagogical field. All this is of course blurred by the fact that we have an interaction in both directins. Learning can also result in information or knowledge. What we really would like the program output to produce is a description of the knowledge in our calculations in a form that would also be machine understandable and the answer to this is RDF. I doubt too many persons today place their output directly on the network but if this happens and the output is using RDF we can some time in the future look into the possibility of having software agents that talk to each other and exchange information and resources on a particular calculation. Perhaps they even write the papers and talk to the software agent at a university directly to apply a job for you. Regards, -leif laaksonen ------------------------------------------------------------------- Center for Scientific Computing | Phone: 358 9 4572378 P.O. Box 405 | Mobile: 358 400425203 FIN-02101 Espoo | Telefax: 358 9 4572302 FINLAND | Mail: Leif.Laaksonen@csc.fi -------- URL: http://laaksonen.csc.fi/leif.laaksonen.html --------- From chemistry-request@server.ccl.net Thu May 20 12:10:51 1999 Received: from comsig.nibsc.ac.uk (comsig.nibsc.ac.uk [193.62.43.13]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id MAA17245 for ; Thu, 20 May 1999 12:10:49 -0400 Received: from nibsc.ac.uk (dlinmf.nibsc.ac.uk [193.62.42.144]) by comsig.nibsc.ac.uk (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA23912 for ; Thu, 20 May 1999 17:04:14 +0100 (BST) Message-ID: <37443293.D50A610E@nibsc.ac.uk> Date: Thu, 20 May 1999 17:04:35 +0100 From: Mark Forster Organization: NIBSC X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: chemistry@server.ccl.net Subject: TINKER energy analysis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear CCLers Are there any experienced TINKER MM code users who are aware of a relatively easy way to compute the intermolecular (VDW+coulombic) energy between specified atoms or groups ? The analyze command several options but this is not among them. It would, of course, be possible to modify the code to compute and output these terms but this is something of a last resort. Thanks Mark -- Dr Mark J Forster Ph.D. Principal Scientist Informatics Laboratory National Institute for Biological Standards and Control Blanche Lane, South Mimms, Hertfordshire EN6 3QG, United Kingdom. Tel +44 (0)1707 654753 FAX +44 (0)1707 646730 E-mail mforster@nibsc.ac.uk From chemistry-request@server.ccl.net Thu May 20 13:19:23 1999 Received: from carbon.chem.ucla.edu (carbon.chem.ucla.edu [128.97.35.55]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id NAA18165 for ; Thu, 20 May 1999 13:19:23 -0400 Received: from red5 (pc-ll.chem.ucla.edu [128.97.35.245]) by carbon.chem.ucla.edu (8.9.1a/8.9.1) with SMTP id KAA17011 for ; Thu, 20 May 1999 10:14:20 -0700 (PDT) Message-Id: <4.1.19990520101719.00de6780@mbi.ucla.edu> X-Sender: lavelle@mbi.ucla.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 20 May 1999 10:19:15 -0700 To: CCL From: Laurence Lavelle Subject: Significant figures and single point calculations Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" I was hoping that the various software companies that I contacted would make an announcement to CCL. Since this has not occurred you should be aware of the following. Many software packages round off significant figures. For example, an original file with Cartesian coordinates to 6 sig fig. When saved as .pdb in HyperChem Professional 5 has 3 sig fig. When saved as Z-matrix, 4 sig fig. In Chem 3D ULTRA 5, bond lengths changed by 0.001 A. Again sig fig are different for different formats. Babel 1.3 converted a 6 sig fig file to 3 sig fig when going from .hin to .pdb Hopefully Gaussian will post significant figures for all file formats in NewZMat. These round off errors will affect single point calculations. Laurence """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" """""""""""""""" Laurence Lavelle, Ph.D. University of California Los Angeles Department of Chemistry & Biochemistry and Molecular Biology Institute Laboratory of Structural Biology & Molecular Medicine Los Angeles, CA 90095-1570, USA Email:LAVELLE@MBI.UCLA.EDU Phone (Office): (310) 825-2083 Room 3048A Young Hall Fax: (310) 206-4038 Phone (Lab): (310) 206-8270 Room 269B MBI http://www.doe-mbi.ucla.edu/people/lavelle/lavelle.html """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" """""""""""""""" From chemistry-request@server.ccl.net Thu May 20 13:20:16 1999 Received: from carbon.chem.ucla.edu (carbon.chem.ucla.edu [128.97.35.55]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id NAA18208 for ; Thu, 20 May 1999 13:20:16 -0400 Received: from red5 (pc-ll.chem.ucla.edu [128.97.35.245]) by carbon.chem.ucla.edu (8.9.1a/8.9.1) with SMTP id KAA17093 for ; Thu, 20 May 1999 10:15:13 -0700 (PDT) Message-Id: <4.1.19990520101713.00de69f0@mbi.ucla.edu> X-Sender: lavelle@mbi.ucla.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 20 May 1999 10:20:08 -0700 To: CCL From: Laurence Lavelle Subject: Converting Fractional Atomic Coordinates to Cartesian Coordinates Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Anyone know of utility/software that converts Fractional Atomic Coordinates to Cartesian Coordinates ? Thanks Laurence """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" """""""""""""""" Laurence Lavelle, Ph.D. University of California Los Angeles Department of Chemistry & Biochemistry and Molecular Biology Institute Laboratory of Structural Biology & Molecular Medicine Los Angeles, CA 90095-1570, USA Email:LAVELLE@MBI.UCLA.EDU Phone (Office): (310) 825-2083 Room 3048A Young Hall Fax: (310) 206-4038 Phone (Lab): (310) 206-8270 Room 269B MBI http://www.doe-mbi.ucla.edu/people/lavelle/lavelle.html """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" """""""""""""""" From chemistry-request@server.ccl.net Thu May 20 14:11:26 1999 Received: from ccl.net (atlantis.ccl.net [192.148.249.4]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id OAA19056 for ; Thu, 20 May 1999 14:11:25 -0400 Received: from admin.cnrs-orleans.fr (admin.cnrs-orleans.fr [163.9.1.2]) by ccl.net (8.8.6/8.8.6/OSC 1.1) with ESMTP id OAA11471 for ; Thu, 20 May 1999 14:06:19 -0400 (EDT) Received: from chinon.cnrs-orleans.fr (chinon.cnrs-orleans.fr [163.9.6.107]) by admin.cnrs-orleans.fr (8.8.8/jtpda-5.3) with ESMTP id UAA07205 ; Thu, 20 May 1999 20:06:17 +0200 (MET DST) Received: (from hinsen@localhost) by chinon.cnrs-orleans.fr (8.8.7/8.8.7) id UAA01670; Thu, 20 May 1999 20:06:24 +0200 Date: Thu, 20 May 1999 20:06:24 +0200 Message-Id: <199905201806.UAA01670@chinon.cnrs-orleans.fr> X-Authentication-Warning: chinon.cnrs-orleans.fr: hinsen set sender to hinsen@cnrs-orleans.fr using -f From: Konrad Hinsen To: shenkin@schrodinger.com CC: chemistry@ccl.net In-reply-to: (message from Peter Shenkin on Wed, 19 May 1999 12:23:39 -0400 (EDT)) Subject: Re: CCL:XML as program output? References: On Wed, 19 May 1999, Peter Shenkin wrote: > One difference among these formats is the degree of nesting of > data structures they allow. ASN.1 allows as many as one wants; > so does STAR. But STAR/CIF limits this, and CEX started out with > basically the STAR/CIF limits. I'm not sure about the XML/CML > proposal, but I suppose it allows as much as you want. The m2io XML permits arbitrary nesting, but DTDs can be designed to effectively limit this (although I see no reason to do so). > The real difficulty, however, is how semantics are to be handled. CEX > had a field called CHARGE. In CEX work-group discussusions, I used > to ask, "Is this partial charge or formal charge." The answer was > always, "It's whatever you decide to put there." The net effect > was that a reading program would not always know how to interpret > CHARGE when it got this field. IMHO, it was a failure to resolve > this sort of issue that limited the success of CEX. The XML answer to this problem is to use tag attributes. You could write for example 0.2 Programs can then easily extract - all charge data, ignoring the type - only charge data of a specific type - all charge data together with the type The DTD decides if attributes are compulsory or obligatory (perhaps with a default value) and whether the value can be any string or one out of a fixed set of values. > It would be easy to say, "Well, if I put the partial charge in > the CHARGE field and read it in one of my programs later, then > I know it's partial charge and it's not a problem." But if these > APIs and file formats are to be useful for data interchange with > someone else's program, I need to know what the other program > meant by CHARGE. That means I need not just the file, but > also the history of its generation. There was no standard > way of encoding this. That's also my main criticism about CML: the interpretation of many data items depends on "conventions", and it seems almost necessary for each program to establish its own one. Of course conventions give more flexibility, but at the cost of making much data useless without additional information, which in general would not even exist in machine-readable form. I'd prefer a more rigid DTD with clear semantics; it is always possible to extend a DTD in a particular document if something essential is missing. > is going to be much harder. What are the semantics > of "a hydrogen bond" or "an alpha helix"? A lot of the > difficulties in using PDB files have to do with this. Of The essential problem of the PDB format is that there is no provision for storing additional data in a standardized format. The choice is between REMARK records and abuse of some fields, leading more often than not to the latter choice, which permits at least simple parsing. > Let tell you how we're dealing with the semantic issue in m2io. > Part of each data tag may contain a label that identifies a > "reader", sort of an intended audience. That sounds pretty similar to CML conventions! And it leads to the same problem: what is a program supposed to do when it encounters an unknown "reader" type? > Why did we roll our own, instead of using one of the above choices? > Well, we did come close to using ASN.1, as I mentioned above. For > STAR and XML/CML, we couldn't find readers/parsers that were either > free or cheap enough -- or, if I recall correctly, for CML, that even > existed. The good ones for ASN.1 are expensive, too. All the above CML is an XML application and therefore also an SGML application, there must have been suitable parsers long ago, but perhaps quite expensive. Today there are several free XML parsers around, although some people might find GPLed parsers too free ;-) -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From chemistry-request@server.ccl.net Thu May 20 14:23:47 1999 Received: from charleston.softhome.net (qmailr@charleston.SoftHome.net [204.144.231.41]) by server.ccl.net (8.8.7/8.8.7) with SMTP id OAA19244 for ; Thu, 20 May 1999 14:23:47 -0400 Received: (qmail 26705 invoked by uid 417); 20 May 1999 18:39:26 -0000 Received: from 1cust120.tnt1.det1.da.uu.net (HELO kressj.www.microsoft.com) (153.34.15.120) by smtp.softhome.net with SMTP; 20 May 1999 18:39:26 -0000 Message-ID: <000a01bea2ed$2a9af5e0$780f2299@kressj.www.microsoft.com> From: "Jim Kress" To: "CCL" , "Laurence Lavelle" Subject: Re: CCL:Significant figures and single point calculations Date: Thu, 20 May 1999 14:18:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 "Hopefully Gaussian will post significant figures for all file formats in NewZMat. " Abandon hope, all ye that enter a relationship with Gaussian! Based on my experience, it is very unlikely that Gaussian will do ANYTHING about your concern. But, maybe you'll get lucky ... Jim Check out my web site http://www.kressworks.com/ It'll blow your mind (politically), stimulate your senses (artistically) and provide scientific insights that boggle the mind!! -----Original Message----- From: Laurence Lavelle To: CCL Date: Thursday, May 20, 1999 1:37 PM Subject: CCL:Significant figures and single point calculations >I was hoping that the various software companies that I contacted would >make an announcement to CCL. Since this has not occurred you should be >aware of the following. > >Many software packages round off significant figures. > >For example, an original file with Cartesian coordinates to 6 sig fig. > >When saved as .pdb in HyperChem Professional 5 has 3 sig fig. >When saved as Z-matrix, 4 sig fig. > >In Chem 3D ULTRA 5, bond lengths changed by 0.001 A. >Again sig fig are different for different formats. > >Babel 1.3 converted a 6 sig fig file to 3 sig fig when going from .hin to .pdb > >Hopefully Gaussian will post significant figures for all file formats in >NewZMat. > >These round off errors will affect single point calculations. > >Laurence > > >""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" " >"""""""""""""""" >Laurence Lavelle, Ph.D. >University of California Los Angeles >Department of Chemistry & Biochemistry and Molecular Biology Institute >Laboratory of Structural Biology & Molecular Medicine >Los Angeles, CA 90095-1570, USA > >Email:LAVELLE@MBI.UCLA.EDU >Phone (Office): (310) 825-2083 >Room 3048A Young Hall >Fax: (310) 206-4038 >Phone (Lab): (310) 206-8270 >Room 269B MBI >http://www.doe-mbi.ucla.edu/people/lavelle/lavelle.html >""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" " >"""""""""""""""" > >-= This is automatically added to each message by mailing script =- >CHEMISTRY@ccl.net -- To Everybody | CHEMISTRY-REQUEST@ccl.net -- To Admins >MAILSERV@ccl.net -- HELP CHEMISTRY or HELP SEARCH >CHEMISTRY-SEARCH@ccl.net -- archive search | Gopher: gopher.ccl.net 70 >Ftp: ftp.ccl.net | WWW: http://www.ccl.net/chemistry/ | Jan: jkl@ccl.net > > > > From chemistry-request@server.ccl.net Thu May 20 14:26:56 1999 Received: from smtp8.ny.us.ibm.com (smtp8.ny.us.ibm.com [198.133.22.20]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id OAA19315 for ; Thu, 20 May 1999 14:26:56 -0400 From: whuber@almaden.ibm.com Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.132.205]) by smtp8.ny.us.ibm.com (8.8.8/8.8.7) with ESMTP id OAA70446; Thu, 20 May 1999 14:18:31 -0400 Received: from d53mta03h.boulder.ibm.com (d53mta03h.boulder.ibm.com [9.99.142.3]) by westrelay02.boulder.ibm.com (8.8.8m2/NCO v1.8) with SMTP id MAA206704; Thu, 20 May 1999 12:19:48 -0600 Received: by d53mta03h.boulder.ibm.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 87256777.0064AF99 ; Thu, 20 May 1999 12:19:45 -0600 X-Lotus-FromDomain: IBMUS To: Laurence Lavelle cc: CCL Message-ID: <87256777.0064AE1E.00@d53mta03h.boulder.ibm.com> Date: Thu, 20 May 1999 11:19:39 -0700 Subject: Re: CCL:Significant figures and single point calculations Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline >> Many software packages round off significant figures. What do you mean by "significant"? Do you believe the results of your calculations (with all the approximations that go in there), or any experimental data, is that accurate? Btw, does anyone know what the uncertainty of position of a nucleus, say of a C atom in a covalent bond, is due to thermal motion? Wolfgang Huber IBM Almaden Research Center San Jose CA From chemistry-request@server.ccl.net Thu May 20 15:09:28 1999 Received: from hugh.chem.uic.edu (HUGH.CHEM.UIC.EDU [131.193.195.93]) by server.ccl.net (8.8.7/8.8.7) with SMTP id PAA19743 for ; Thu, 20 May 1999 15:09:28 -0400 Received: by hugh.chem.uic.edu (940816.SGI.8.6.9/940406.SGI.AUTO) id NAA03567; Thu, 20 May 1999 13:07:13 -0500 Date: Thu, 20 May 1999 13:07:05 +36000 From: Richard Wood To: whuber@almaden.ibm.com cc: Laurence Lavelle , CCL Subject: Re: CCL:Significant figures and single point calculations In-Reply-To: <87256777.0064AE1E.00@d53mta03h.boulder.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Based on my experience, which is limited, in calculations derived from MD simulations, that only the first place afer the decimal is significant. I other words, if a calculation gives a bond length of 1.510867 Angstroms, you should report it as 1.51 Angstroms. Richard On Thu, 20 May 1999 whuber@almaden.ibm.com wrote: > > > > >> Many software packages round off significant figures. > > What do you mean by "significant"? Do you believe the results of your > calculations (with all the approximations that go in there), or any experimental > data, is that accurate? > > Btw, does anyone know what the uncertainty of position of a nucleus, say of a C > atom in a covalent bond, is due to thermal motion? > > Wolfgang Huber > IBM Almaden Research Center > San Jose CA > > > > -= This is automatically added to each message by mailing script =- > CHEMISTRY@ccl.net -- To Everybody | CHEMISTRY-REQUEST@ccl.net -- To Admins > MAILSERV@ccl.net -- HELP CHEMISTRY or HELP SEARCH > CHEMISTRY-SEARCH@ccl.net -- archive search | Gopher: gopher.ccl.net 70 > Ftp: ftp.ccl.net | WWW: http://www.ccl.net/chemistry/ | Jan: jkl@ccl.net > > > > > From chemistry-request@server.ccl.net Thu May 20 15:52:02 1999 Received: from hugh.chem.uic.edu (HUGH.CHEM.UIC.EDU [131.193.195.93]) by server.ccl.net (8.8.7/8.8.7) with SMTP id PAA20141 for ; Thu, 20 May 1999 15:52:02 -0400 Received: by hugh.chem.uic.edu (940816.SGI.8.6.9/940406.SGI.AUTO) id NAA03751; Thu, 20 May 1999 13:49:56 -0500 Date: Thu, 20 May 1999 13:49:41 +36000 From: Richard Wood To: chemistry@ccl.net Subject: Re: CCL:Significant figures and single point calculations In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Make that 1.5 Angstroms, and not 1.51 Angstroms. Richard On Thu, 20 May 1999, Richard Wood wrote: > Based on my experience, which is limited, in calculations derived from MD > simulations, that only the first place afer the decimal is significant. > I other words, if a calculation gives a bond length of 1.510867 Angstroms, > you should report it as 1.51 Angstroms. > > Richard > > On Thu, 20 May 1999 whuber@almaden.ibm.com wrote: > > > > > > > > > >> Many software packages round off significant figures. > > > > What do you mean by "significant"? Do you believe the results of your > > calculations (with all the approximations that go in there), or any experimental > > data, is that accurate? > > > > Btw, does anyone know what the uncertainty of position of a nucleus, say of a C > > atom in a covalent bond, is due to thermal motion? > > > > Wolfgang Huber > > IBM Almaden Research Center > > San Jose CA > > > > > > > > > > > > > > > > > -= This is automatically added to each message by mailing script =- > CHEMISTRY@ccl.net -- To Everybody | CHEMISTRY-REQUEST@ccl.net -- To Admins > MAILSERV@ccl.net -- HELP CHEMISTRY or HELP SEARCH > CHEMISTRY-SEARCH@ccl.net -- archive search | Gopher: gopher.ccl.net 70 > Ftp: ftp.ccl.net | WWW: http://www.ccl.net/chemistry/ | Jan: jkl@ccl.net > > > > > From chemistry-request@server.ccl.net Thu May 20 16:18:26 1999 Received: from schrodinger.com (root@thermidore.schrodinger.com [192.156.98.99]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id QAA20462 for ; Thu, 20 May 1999 16:18:25 -0400 Received: from sandra.schrodinger.com (sandra.schrodinger.com [206.231.140.250]) by schrodinger.com (8.8.5/8.8.5) with ESMTP id NAA29424; Thu, 20 May 1999 13:17:51 -0700 Received: from localhost (shenkin@localhost) by sandra.schrodinger.com (8.8.5/8.8.5) with ESMTP id QAA04480; Thu, 20 May 1999 16:17:21 -0400 X-Authentication-Warning: sandra.schrodinger.com: shenkin owned process doing -bs Date: Thu, 20 May 1999 16:17:20 -0400 (EDT) From: Peter Shenkin To: Richard Wood cc: chemistry@ccl.net Subject: Re: CCL:Significant figures and single point calculations In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Come to think of it, make that 1 Angstrom -- or actually, do I mean 2? Wait a second -- I think I see the problem. :-) -P. On Thu, 20 May 1999, Richard Wood wrote: > Make that 1.5 Angstroms, and not 1.51 Angstroms. > > Richard > > On Thu, 20 May 1999, Richard Wood wrote: > > > Based on my experience, which is limited, in calculations derived from MD > > simulations, that only the first place afer the decimal is significant. > > I other words, if a calculation gives a bond length of 1.510867 Angstroms, > > you should report it as 1.51 Angstroms. > > > > Richard > > > > On Thu, 20 May 1999 whuber@almaden.ibm.com wrote: > > > > > > > > > > > > > > >> Many software packages round off significant figures. > > > > > > What do you mean by "significant"? Do you believe the results of your > > > calculations (with all the approximations that go in there), or any experimental > > > data, is that accurate? > > > > > > Btw, does anyone know what the uncertainty of position of a nucleus, say of a C > > > atom in a covalent bond, is due to thermal motion? > > > > > > Wolfgang Huber > > > IBM Almaden Research Center > > > San Jose CA > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -= This is automatically added to each message by mailing script =- > CHEMISTRY@ccl.net -- To Everybody | CHEMISTRY-REQUEST@ccl.net -- To Admins > MAILSERV@ccl.net -- HELP CHEMISTRY or HELP SEARCH > CHEMISTRY-SEARCH@ccl.net -- archive search | Gopher: gopher.ccl.net 70 > Ftp: ftp.ccl.net | WWW: http://www.ccl.net/chemistry/ | Jan: jkl@ccl.net > > > > > -- ********* Peter S. Shenkin; Schrodinger, Inc.; (201)433-2014 x111 ********* *********** shenkin@schrodinger.com; http://www.schrodinger.com *********** From chemistry-request@server.ccl.net Thu May 20 16:19:13 1999 Received: from carbon.chem.ucla.edu (carbon.chem.ucla.edu [128.97.35.55]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id QAA20492 for ; Thu, 20 May 1999 16:19:13 -0400 Received: from red5 (pc-ll.chem.ucla.edu [128.97.35.245]) by carbon.chem.ucla.edu (8.9.1a/8.9.1) with SMTP id NAA08305; Thu, 20 May 1999 13:14:08 -0700 (PDT) Message-Id: <4.1.19990520131800.00d8eec0@mbi.ucla.edu> X-Sender: lavelle@mbi.ucla.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 20 May 1999 13:19:04 -0700 To: whuber@almaden.ibm.com From: Laurence Lavelle Subject: Re: CCL:Significant figures and single point calculations Cc: CCL In-Reply-To: <87256777.0064AE1E.00@d53mta03h.boulder.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" My point is self consistency in calculating single point energies that will differ due to file format changes on what should be the identical file. No the calculations are not accurate to 3sf in an absolute sense. But given that much of computational chemistry involves relative energies, we should at least get it right for two identical calculations done on the "same" file/structure. By the way, high resolution structures are determined to 3sf. Very high (V low temp) small molecules structures can be determined to 4sf. Laurence At 11:19 AM 5/20/99 -0700, whuber@almaden.ibm.com wrote: > > > >>> Many software packages round off significant figures. > >What do you mean by "significant"? Do you believe the results of your >calculations (with all the approximations that go in there), or any >experimental >data, is that accurate? > >Btw, does anyone know what the uncertainty of position of a nucleus, say of a C >atom in a covalent bond, is due to thermal motion? > >Wolfgang Huber >IBM Almaden Research Center >San Jose CA > > > >-= This is automatically added to each message by mailing script =- >CHEMISTRY@ccl.net -- To Everybody | CHEMISTRY-REQUEST@ccl.net -- To Admins >MAILSERV@ccl.net -- HELP CHEMISTRY or HELP SEARCH >CHEMISTRY-SEARCH@ccl.net -- archive search | Gopher: gopher.ccl.net 70 >Ftp: ftp.ccl.net | WWW: http://www.ccl.net/chemistry/ | Jan: jkl@ccl.net > > > > From chemistry-request@server.ccl.net Thu May 20 16:26:45 1999 Received: from carbon.chem.ucla.edu (carbon.chem.ucla.edu [128.97.35.55]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id QAA20606 for ; Thu, 20 May 1999 16:26:44 -0400 Received: from red5 (pc-ll.chem.ucla.edu [128.97.35.245]) by carbon.chem.ucla.edu (8.9.1a/8.9.1) with SMTP id NAA09183; Thu, 20 May 1999 13:21:30 -0700 (PDT) Message-Id: <4.1.19990520132023.00dec270@mbi.ucla.edu> X-Sender: lavelle@mbi.ucla.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 20 May 1999 13:26:26 -0700 To: Richard Wood , whuber@almaden.ibm.com From: Laurence Lavelle Subject: Re: CCL:Significant figures and single point calculations Cc: CCL In-Reply-To: References: <87256777.0064AE1E.00@d53mta03h.boulder.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Agreed. In fact my original posting makes it clear that this is a moot point for MD and ab initio simulations because the change in atomic positions > 3sf. But single point calculations on what should be the identical file will give different answers when bond lengths change by +/- 0.001A. Laurence At 01:07 PM 5/20/99 +0000, Richard Wood wrote: >Based on my experience, which is limited, in calculations derived from MD >simulations, that only the first place afer the decimal is significant. >I other words, if a calculation gives a bond length of 1.510867 Angstroms, >you should report it as 1.51 Angstroms. > >Richard > >On Thu, 20 May 1999 whuber@almaden.ibm.com wrote: > >> >> >> >> >> Many software packages round off significant figures. >> >> What do you mean by "significant"? Do you believe the results of your >> calculations (with all the approximations that go in there), or any >experimental >> data, is that accurate? >> >> Btw, does anyone know what the uncertainty of position of a nucleus, say >of a C >> atom in a covalent bond, is due to thermal motion? >> >> Wolfgang Huber >> IBM Almaden Research Center >> San Jose CA >> >> >> >> -= This is automatically added to each message by mailing script =- >> CHEMISTRY@ccl.net -- To Everybody | CHEMISTRY-REQUEST@ccl.net -- To >Admins >> MAILSERV@ccl.net -- HELP CHEMISTRY or HELP SEARCH >> CHEMISTRY-SEARCH@ccl.net -- archive search | Gopher: gopher.ccl.net 70 >> Ftp: ftp.ccl.net | WWW: http://www.ccl.net/chemistry/ | Jan: jkl@ccl.net >> >> >> >> >> From chemistry-request@server.ccl.net Thu May 20 10:13:13 1999 Received: from cerberus.ulaval.ca (cerberus.ulaval.ca [132.203.250.10]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id KAA16117 for ; Thu, 20 May 1999 10:13:13 -0400 Received: from fluor.chm.ulaval.ca (fluor.chm.ulaval.ca [132.203.70.9]) by cerberus.ulaval.ca (8.8.7/8.7.3) with ESMTP id KAA08946 for ; Thu, 20 May 1999 10:16:23 -0400 (EDT) Received: (from anh@localhost) by fluor.chm.ulaval.ca (8.6.12/8.6.12) id DAA09649 for CHEMISTRY@ccl.net; Thu, 20 May 1999 03:13:00 -0400 From: "Nguyen N. Anh" Message-Id: <9905200312.ZM9647@fluor.chm.ulaval.ca> Date: Thu, 20 May 1999 03:12:57 -0400 X-Mailer: Z-Mail (3.2.1 6apr95 MediaMail) To: CHEMISTRY@ccl.net Subject: electric field + H2+ SUMMARY Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Dear cclers, Some days ago I posted a question concerning calculations of resonance states using quantum chemical codes. Since then I've got 2 responses and some requests for summarizing. One of the references I got seems to be very relevant and it helps me very much. ( Chao, Falcetta, Jordan, JCP, 93, 1125). I realized that resonance states calculations are difficult, but sufficient effort is being made to do it, in particular by using electronic structure programs. Thanks to all who responded and who were interested in my posting Best regards Nam-Anh Nguyen ------------------- > Dear cclers, > > I'm doing very "simple" abinitio calculations on the H2+ molecular system using > g94. A strong electric field has been applied (using Field keyword) which > distorts the original Coulomb potential of the molecule, i.e. a linear > potential is added to the Coulomb one. Thus the molecule's LUMO and HOMO can > interact with continuum states of the linear potential of the electric field to > form resonant states, and electron can tunnel out. > > The difficulty is: to generate correct resonant states, we have to provide > basis sets that can support continumm states of the electric field. Standard > Gaussian basis sets centered at the H atoms alone are not sufficient. > > My question: Does anyone know of any similar abinitio calculation? Or any basis > set that supports continuum states? > ------------------- >From Dr. Falcetta: Hi, I am not sure that I exactly understand your question, but I might have an approach that could help. Are you trying to find the resonant states of H2+ with respect to ionization (ie to form H2++) in the presence of a strong electric field on approach to introducing a continuum/resonant resolution using standard quantum chem codes is the stabilization method. Dr K. D> Jordan and I have done several calculations using this approach. We include several diffuse gaussian basis functions in the atomic basis set and do several calculations each calculation is different in that the exponents of the diffuse functions are scaled by multiplication by a constant. The eigencalues (you need to extract several) are plotted as a function of this scaling parameter. If you need the lifetimes as well you need to a bit more math. Two references, if this sounds promising: chem phys letter vol 300 page 588 and JCP vol 93 1125. I am really not sure that this is relevant because I am not quite clear on the exact problem. But if I can be of help you can e-mail me good luck Mike Falcetta ------------------ >From Dr. Valerio Hi, of course localized basis set cannot describe the ionized free electron, which is well represented by a plane wave. I am aware of theoretical studies on atoms only and I can suggest you the following refernces: H.A. Bethe, E.E. Salpeter, it Quantum Mechanics of One- and Two-Electron Atoms (Springer-Verlag 1957). L.D. Landau, E. M. Lifshitz, Quantum Mechanics. and this recent paper: D. Fisher, Y. Maron, L.P. Pitaevskii, Phys. Rev. A {\bf 58}, 2214 (1998). I hope it helps Best regards Gabriele -------------- -- Nguyen Nam Anh Quebec, Canada E-mail: anh@chm.ulaval.ca WWW: http://promethium.chm.ulaval.ca/~anh/ From chemistry-request@server.ccl.net Thu May 20 14:30:40 1999 Received: from mgcct6.nci.nih.gov (mgcct6.nci.nih.gov [137.187.211.216]) by server.ccl.net (8.8.7/8.8.7) with SMTP id OAA19399 for ; Thu, 20 May 1999 14:30:40 -0400 Received: from helix.nih.gov (localhost [127.0.0.1]) by mgcct6.nci.nih.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA12810; Thu, 20 May 1999 14:31:09 -0400 Sender: brunob@helix.nih.gov Message-ID: <374454EC.FF1FA605@helix.nih.gov> Date: Thu, 20 May 1999 14:31:08 -0400 From: Bruno Bienfait Organization: National Cancer Institute X-Mailer: Mozilla 4.5 [en] (X11; I; IRIX 6.3 IP32) X-Accept-Language: en MIME-Version: 1.0 To: "jerome f. baker" , Computer Chemistry List CC: greg@parasoft.com Subject: Re: CCL:problem with AutoDock 3.0 example files References: <000101be9438$38eeb500$90bd6420@jm> Content-Type: multipart/alternative; boundary="------------F2A005D772774D54CD51A097" --------------F2A005D772774D54CD51A097 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 "jerome f. baker" wrote: > Hello CCL subscribers, > > We have just compiled AutoDock 3.0 for Linux, and are attempting to run the > two sets of example docking files which are included in the distribution. > > There does not seem to be an electrostatics map in either set, so we have > removed all of the map files and have run AutoGrid to produce a complete set > of map files for both examples. This works perfectly. > > However, when we attempt to run AutoDock, as soon as it has read in the > various .map files and attempts to +ACI-move+ACI- the ligand (the .pdbq file), it > aborts and returns a +ACI-segmentation fault+ACI- message. > > Any suggestions from more experienced AutoDock users? I experienced the same problem on Linux, and on Linux only. It seems to be related to the stack size which is too small for Autodock. The readPDBQ() function allocates multidimensional arrays on the stack. The easiest solution (unless one wants to increase the stack space in the kernel) is to patch the source code by changing the declaration type for these arrays. For example, the line readPDBQ.cc:82 char record[ MAX_RECORDS ][ LINE_LEN ]; can be patched to : static char record[ MAX_RECORDS ][ LINE_LEN ]; . I have applied such a change to each local array declaration in readPDBQ.cc. The static keyword tells the compiler to allocates the local variables in the heap (permanent storage) and not on the stack (transient storage). This is not a problem here because this function is called only once. Also, beside crash suppression, this patch provides automatic initialization of the local variable "Rec_atomnumber" in the function readPDBQ, which otherwise would be used unitialized (i.e. might contain random data). The same patch procedure should be applied to the file analysis.cc to avoid crashing during analysis. To further improve robustness, one might also want to correct the file support.cc:630 where the function is returning a pointer to a local variable (returnedMol). I discovered these problems with the help of the programs Insure++(http://www.parasoft.com) and purify (http://www.rational.com) (in fact, these checking tools reveal many potential problems in the Autodock 3.0 package). I would like to thank Greg Hunter from ParaSoft Corp. for pointing out the Linux stack space problem. Hopes this can help, Bruno -- [ Bruno Bienfait, Ph. D. Laboratory of Medicinal Chemistry ] [ National Cancer Institute ] [ Email : brunob@helix.nih.gov National Institutes of Health ] [ Phone : (301) 402-3111 Building 37, Room 5B20 ] [ Fax : (301) 496-5839 Bethesda Maryland 20892 , USA ] [ WWW : http://www.brunob.org ] --------------F2A005D772774D54CD51A097 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit "jerome f. baker" wrote:
Hello CCL subscribers,

We have just compiled AutoDock 3.0 for Linux, and are attempting to run the
two sets of example docking files which are included in the distribution.

There does not seem to be an electrostatics map in either set, so we have
removed all of the map files and have run AutoGrid to produce a complete set
of map files for both examples.  This works perfectly.

However, when we attempt to run AutoDock, as soon as it has read in the
various .map files and attempts to +ACI-move+ACI- the ligand (the .pdbq file), it
aborts and returns a +ACI-segmentation fault+ACI- message.

Any suggestions from more experienced AutoDock users?


I experienced the same problem on Linux, and on Linux only. It seems to be related to the stack size which is too small for Autodock.
The readPDBQ() function allocates  multidimensional arrays on the stack. The easiest solution (unless one wants to increase the stack space in the kernel) is to patch the source code by changing the declaration type for these arrays. For example, the line readPDBQ.cc:82

char  record[ MAX_RECORDS ][ LINE_LEN ];

can be patched  to :

static  char  record[ MAX_RECORDS ][ LINE_LEN ];

. I have applied such a change to each local  array declaration in readPDBQ.cc.  The static keyword  tells the compiler to allocates the local variables in the heap (permanent storage) and not on the stack (transient storage). This is not a problem here because this function is called only once. Also, beside crash suppression, this  patch provides automatic initialization of the  local variable "Rec_atomnumber" in the function readPDBQ, which otherwise would be  used unitialized (i.e. might contain random data).

The same patch procedure should be applied to the file analysis.cc to avoid crashing during analysis.
 

To further improve robustness, one might also  want to correct the  file support.cc:630  where the function is returning a pointer to a local variable (returnedMol).
 

I discovered these problems with the help of  the programs Insure++(http://www.parasoft.com) and purify (http://www.rational.com) (in fact, these checking tools reveal many  potential problems in the Autodock 3.0 package).

I would like to thank Greg Hunter from ParaSoft Corp. for pointing out  the Linux  stack space problem.
 

Hopes this can help,

Bruno 

-- 
[ Bruno Bienfait, Ph. D.            Laboratory of Medicinal Chemistry ]
[                                   National Cancer Institute         ]
[ Email : brunob@helix.nih.gov      National Institutes of Health     ]
[ Phone : (301) 402-3111            Building 37, Room 5B20            ]
[ Fax   : (301) 496-5839            Bethesda Maryland 20892 , USA     ]
[ WWW   : http://www.brunob.org                                       ]
  --------------F2A005D772774D54CD51A097-- From chemistry-request@server.ccl.net Thu May 20 14:49:04 1999 Received: from judy.ic.ac.uk (judy.ic.ac.uk [155.198.5.28]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id OAA19604 for ; Thu, 20 May 1999 14:49:02 -0400 Received: from juliet.ic.ac.uk ([155.198.5.4]) by judy.ic.ac.uk with esmtp (Exim 2.12 #1) id 10kXnN-0007hb-00 for chemistry@ccl.net; Thu, 20 May 1999 18:43:53 +0000 Received: from sg1.cc.ic.ac.uk ([155.198.63.8] helo=cscmgb.cc.ic.ac.uk) by juliet.ic.ac.uk with esmtp (Exim 2.12 #1) id 10kXnB-0004Ri-00 for chemistry@ccl.net; Thu, 20 May 1999 18:43:41 +0000 Received: from [155.198.8.66] by cscmgb.cc.ic.ac.uk (980427.SGI.8.8.8/4.0) id TAA00716; Thu, 20 May 1999 19:43:25 +0100 (bst) Mime-Version: 1.0 X-Sender: rzepa@155.198.63.8 (Unverified) Message-Id: In-Reply-To: References: <9905182135.ZM3892@torvs.ccc.uni-erlangen.de> Date: Thu, 20 May 1999 19:45:43 +0100 To: chemistry@ccl.net From: "Rzepa, Henry" Subject: Re: CCL:XML as program output? Content-Type: text/plain; charset="us-ascii" >... Look at all the crappy HTML that is out there. Look at the >garbage produced by PageMill or FrontPage or most any other commercial >program. One of the most important aspects of XML is that by definition, it must be "clean". Arguably, programs such as PM or Frontpage produced highly verbose (sometimes even unclean, or at best non standard) HTML, of which perhaps 60% did nothing either to enhance the content, or really add worthwhile "style", and to a certain extent brought "HTML" conversions into disrepute. If XML is to succeed, it must be followed by high quality tools, both generic and subject specific. It was with great interest therefore that we today converted our "XML/CML" article using the new Office 2000 program from Microsoft, and displayed the result a) in a text editor and b) in Internet Explorer 5.0. I was very impressed, and must give Microsoft full due for having produced a very impressive generic tool, one on which the computational chemistry community can build upon! The HTML/XML produced by Office 2000 was clean, concise (!), and human readable (!) under a) above, and displayed faultlessly in IE5 in b) above, so much so that it was difficult to distinguish b) from the original Word document. I emphasize that it IS possible to preserve a well structured document in which the content is separated from the presentation, AND achieve a high level of printed quality. Word 2000 does this by making extensive use of internal stylesheets, cleanly separated from the content of the document, and hence its ontology (meaning). If you are in doubt, compare the original Word rtf format with the new XML format (or for that matter with Postscript). I emphasize that XML/CML produced by a computational chemistry program is fully INTER-OPERABLE with e.g. Office 2000. Indeed, we have verified that CML read into Office 2000 is 100% preserved, and suffers no loss of the type experienced by a typical chemical foo ==> babel ==> off ==> babel ==> "foo" conversion. Think what that means for preserving computational output (well, VERY large files for one thing!!). The key word is that holy grail of inter-operability, not only within chemistry but outside it. Because we have not achieved it in 40 years of digital chemistry does not mean it cannot happen! As XSL (eXtensible style sheets), develop for eg chemistry, and XQL (eXtensible query language) chemical queries become possible (making use of RDF, the Resource Description format and perhaps Dublin Core/ Dublin Chem type chemical extension schemas as suggested by us), it does seem the hold grail might be moving closer rather than further away. Henry Rzepa. +44 171 594 5774 (Office) +44 171 594 5804 (Fax) http://www.ch.ic.ac.uk/rzepa/ From chemistry-request@server.ccl.net Thu May 20 19:37:30 1999 Received: from hugh.chem.uic.edu (HUGH.CHEM.UIC.EDU [131.193.195.93]) by server.ccl.net (8.8.7/8.8.7) with SMTP id TAA23405 for ; Thu, 20 May 1999 19:37:30 -0400 Received: by hugh.chem.uic.edu (940816.SGI.8.6.9/940406.SGI.AUTO) id RAA04156; Thu, 20 May 1999 17:35:21 -0500 Date: Thu, 20 May 1999 17:35:09 +36000 From: Richard Wood To: Laurence Lavelle cc: whuber@almaden.ibm.com, CCL Subject: Re: CCL:Significant figures and single point calculations In-Reply-To: <4.1.19990520132023.00dec270@mbi.ucla.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII But 0.001/1 corresponds to 0.1%. So any propagation of this gives maybe 0.2%. Is this important? Probably not. Richard On Thu, 20 May 1999, Laurence Lavelle wrote: > Agreed. > > In fact my original posting makes it clear that this is a moot point for MD > and ab initio simulations because the change in atomic positions > 3sf. > > But single point calculations on what should be the identical file will > give different answers when bond lengths change by +/- 0.001A. > > Laurence > > > > > At 01:07 PM 5/20/99 +0000, Richard Wood wrote: > >Based on my experience, which is limited, in calculations derived from MD > >simulations, that only the first place afer the decimal is significant. > >I other words, if a calculation gives a bond length of 1.510867 Angstroms, > >you should report it as 1.51 Angstroms. > > > >Richard > > > >On Thu, 20 May 1999 whuber@almaden.ibm.com wrote: > > > >> > >> > >> > >> >> Many software packages round off significant figures. > >> > >> What do you mean by "significant"? Do you believe the results of your > >> calculations (with all the approximations that go in there), or any > >experimental > >> data, is that accurate? > >> > >> Btw, does anyone know what the uncertainty of position of a nucleus, say > >of a C > >> atom in a covalent bond, is due to thermal motion? > >> > >> Wolfgang Huber > >> IBM Almaden Research Center > >> San Jose CA > >> > >> > >> > >> -= This is automatically added to each message by mailing script =- > >> CHEMISTRY@ccl.net -- To Everybody | CHEMISTRY-REQUEST@ccl.net -- To > >Admins > >> MAILSERV@ccl.net -- HELP CHEMISTRY or HELP SEARCH > >> CHEMISTRY-SEARCH@ccl.net -- archive search | Gopher: gopher.ccl.net 70 > >> Ftp: ftp.ccl.net | WWW: http://www.ccl.net/chemistry/ | Jan: jkl@ccl.net > >> > >> > >> > >> > >> > From chemistry-request@server.ccl.net Thu May 20 20:59:37 1999 Received: from ccl.net (atlantis.ccl.net [192.148.249.4]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id UAA23961 for ; Thu, 20 May 1999 20:59:37 -0400 Received: from relay2.scripps.edu (relay2.scripps.edu [137.131.200.30]) by ccl.net (8.8.6/8.8.6/OSC 1.1) with ESMTP id UAA19656 for ; Thu, 20 May 1999 20:54:26 -0400 (EDT) Received: from redox.scripps.edu (redox.scripps.edu [137.131.240.50]) by relay2.scripps.edu (8.9.3/TSRI-3.0.2r) with ESMTP id RAA01595 for ; Thu, 20 May 1999 17:26:48 -0700 (PDT) Received: from localhost by redox.scripps.edu (8.9.1/TSRI-2.8) with SMTP id RAA12390; Thu, 20 May 1999 17:12:09 -0700 (PDT) Date: Thu, 20 May 1999 17:12:09 -0700 (PDT) From: "Jesus M. Castagnetto" Sender: jesusmc@scripps.edu To: Leif Laaksonen cc: CCL Mailing List Subject: Re: CCL:First we took XML then we took RDF In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello Leif and all, Leif's analysis hits the problem in the head. For any meaningful use of any XML application (CML, RDF, WDDX, CDF, etc.) there has to be a scaffold of metainformation about the data, one that can describe the contents and its meaning to the end application (or to a human being). The usual way of doing this in XML and SGML has been the use of DTDs, but they are difficult to extend realiably (no support for inheritance, etc.). There are in the works several meta-data desciption initiatives (schemas): DCD, XML-Data and similar things. Interestingly enough this schema are themselves written in XML (you can never find a Goedel when you need one :). In SGML/XML parlance, an application is not refering to a program, but to an schema, etc. based on the specification of the description language. Use of RDF (one of several XML applications), does not preclude the concurrent use of other ones (CML, Bioinformation Sequence Markup Language, WDDX). In fact, you can use RDF to describe the structure of a repository or database of XML documents. And also use an XML based query application to search for the information in the repository, and then use XSL (or even CSS) to display it to the user. My feeling is that all of these developments are still in a protean state, as they evolve further their usefulness will be greater, but it is something that whether we want it or not is happening and will happen. And chemist (in particular computational chemist) should be aware of it and contribute to its development. Sorry for the longish rant. -- Jesus M. Castagnetto - "Ken Zen Ichi-nyo" Program Project: http://www.scripps.edu/research/metallo/ Metalloprotein DB: http://metallo.scripps.edu/ Pilot Stuff: http://www.geocities.com/ResearchTriangle/Lab/1059/