From chemistry-request@server.ccl.net Wed May 19 02:35:02 1999 Received: from hartree.chem.kuleuven.ac.be (hartree.quantchem.kuleuven.ac.be [134.58.49.1]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id CAA28481 for ; Wed, 19 May 1999 02:35:02 -0400 Received: from localhost (sven@localhost) by hartree.chem.kuleuven.ac.be (8.9.0/8.9.0) with ESMTP id IAA17438; Wed, 19 May 1999 08:30:12 +0100 Date: Wed, 19 May 1999 08:30:12 +0100 (NFT) From: Sven Bovin Reply-To: sven.bovin@chem.kuleuven.ac.be To: Richard Wood cc: CCL Subject: Re: CCL:XML as program output? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Or not running Windows at all, for that matter. ************************************************************ *Sven BOVIN sven.bovin@chem.kuleuven.ac.be* *----------------------------------------------------------* *labo kwantumchemie |IJzerenmolenstr 26| * *Celestijnenln 200F | bus 116 |Wampenberg 88 * *B-3001 HEVERLEE |B-3001 HEVERLEE |B-2370 ARENDONK * * Belgium | Belgium |Belgium * *tel +32(0)16 327380| |tel +32(0)14 678310* *fax +32(0)16 327992| |fax +32(0)14 678310* ************************************************************ On Tue, 18 May 1999, Richard Wood wrote: > I still say why convert many file formats to one if you don't have to/not > all applications curently being used will handle them. > > It's like assuming that everyone using a PC is using Windows 95/98, when > the fact is that some are still using Windows 3.1. > > Richard > From chemistry-request@server.ccl.net Wed May 19 03:26:53 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 DAA28995 for ; Wed, 19 May 1999 03:26:52 -0400 Received: from juliet.ic.ac.uk ([155.198.5.4]) by judy.ic.ac.uk with esmtp (Exim 2.12 #1) id 10k0g4-0006dN-00 for chemistry@ccl.net; Wed, 19 May 1999 07:22:08 +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 10k0g2-0002GV-00 for chemistry@ccl.net; Wed, 19 May 1999 07:22:06 +0000 Received: from [155.198.224.86] by cscmgb.cc.ic.ac.uk (980427.SGI.8.8.8/4.0) id IAA12419; Wed, 19 May 1999 08:22:06 +0100 (bst) Mime-Version: 1.0 X-Sender: rzepa@155.198.63.8 Message-Id: Date: Wed, 19 May 1999 08:21:00 +0100 To: chemistry@ccl.net From: Peter Murray-Rust (by way of Rzepa, Henry) Subject: CML resources Content-Type: text/plain; charset="us-ascii" Greetings I am delighted to see the interest in markup languages on this list and to offer CML as a way forward for molecular information components. As Henry Rzepa has announced, we have recently submitted a paper on CML and the latest DTD has been posted on http://www.xml-cml.org CML/CML is ideal for the management of input and output to chemistry codes. A feature of many of these is that the output has an overall structure which includes well described components (e.g. coordinates, energies, frequencies, wavefunctions), but that the order and quantities of occurrence may depend on the control input and the actual course of the calculation (e.g. when convergence was reached). XML is ideal for holding this information as it is essentially a tree structure and can be built with minimal effort. The exciting thing about XML is that all the tools to manage this structure are now freely available (search, filter, diff/merge, etc.) It means that postprocessors for these codes are easy to write and the resulting XML is extremely rich. I have written a considerable number of such postprocessors (in Java) which extend the JUMBO browser. This means that a single tool (JUMBO) can browse the output of all the standard codes. [Some of the postprocessors were written for JUMBO1, now obsolete, but can be easily modified if required. I would be delighted to advise.] All these postprocessors will be mounted (with OpenSource) on xml-cml.org and you are very welcome to browse them. A number of examples of the use and power of XML are available in the tutorial and other material at http://www.xml-cml.org. It includes, for example, a postprocessor for the VAMP code. Of course the ideal place for creating CML is inside the chemistry codes themselves. This should be almost trivial, and again I'd be happy to advise. Note that the latest version of the CML DTD (the specification) has been thoroughly tested and is likely to remain stable for an appropriate time. CML is designed to be extended in a number of directions. If atoms (or bonds) have a large number of "columns" it is trivial to add these. For example if you wish to create an atom property for the calculated 13C shift the output could resemble: 111.1 ... The implication here is that there would be a publicly available ontology (dictionary) for MY_THEO_PROG explaining what "13C" meant. In this way all the scalar quantities output from a code could be described and captured precisely. Matrix properties can also be captured in CML (there is a XMLelement) and this can be contained in any CML element. Thus atoms can have matrices attached to them in irregular fashion. For example a few atoms in a list might have quadrupoles, while others might have dipoles, etc. XML an manage this irregularity very easily. It is straightforward to use *standard* XML tools to search for (say) all atoms with 3*3 matrices. using XQL this looks like: //atom/matrix[rows='3' $and% columns='3'] This comes free-out-of-the box! CML is a truly component-based approach to information. Thus CML does not define mathematics (it uses MathML), nor bibliography (uses DOCBOOK), not graphics (uses SVG). In this way a complex piece of information (e.g. a theoretical publication) can be built up from its components. This is complete synthesis of documents and data and heralds the way for "interactive publications" - including theses - that can be re-input into programs and can be read in a completely interactive manner. I have looked at a considerable number of theochem outputs and am reasonably confident that the CML tools (which include scalar and matrix primitives) can cope with everything in the common programs. The key thing is for authors to produce their dictionaries/manuals/ontologies in XML and then finally we shall have a complete markup of all the components. At Nottingham we have a project (BioDOM) to support XML in bioinformatics (essentially macro- and small molecules). Adam Moore has written converters for Swissprot and PDB and also posted a number of XML resources on the site. CML is deliberately intended to be a community approach. We are starting to get a number of organisations who are serious about building public and private systems with CML components. Moving CML i/o into the widely used codes would be a tremendous boos to the community and - we believe - to the use of codes and the re-use of the data they produce. P. ------------------------------------------------------------------------- From chemistry-request@server.ccl.net Wed May 19 04:01:13 1999 Received: from joker.chem.york.ac.uk (joker.chem.york.ac.uk [144.32.180.41]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id EAA29298 for ; Wed, 19 May 1999 04:01:12 -0400 From: meike@joker.chem.york.ac.uk Received: (from meike@localhost) by joker.chem.york.ac.uk (AIX4.2/UCB 8.7/8.7) id IAA22124 for chemistry@ccl.net; Wed, 19 May 1999 08:53:33 +0200 (DFT) Date: Wed, 19 May 1999 08:53:33 +0200 (DFT) Message-Id: <199905190653.IAA22124@joker.chem.york.ac.uk> To: chemistry@ccl.net Subject: chem3d Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-MD5: dze4Frzg6fe/gre739T4kw== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.ccl.net id EAA29299 Dear all, i experience problems when running Chem3D (Version 3.2)under WindowsNT4. The open and save option from the file pull down menu are not working. I know there have been problems under Windows 95. Did anybody come across similar problems? Any suggestions would be helpful. Thanks in advance, Meike From chemistry-request@server.ccl.net Tue May 18 17:23:49 1999 Received: from mail2.organik.uni-erlangen.de (lesath.organik.uni-erlangen.de [131.188.128.212]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id RAA23725 for ; Tue, 18 May 1999 17:23:47 -0400 Received: from wtewael.organik.uni-erlangen.de (wtewael [131.188.128.216]) by mail2.organik.uni-erlangen.de (8.8.8/8.1.4-FAU) with ESMTP id XAA04204; Tue, 18 May 1999 23:19:30 +0200 (MET DST) Received: (from wdi@localhost) by wtewael.organik.uni-erlangen.de (8.8.7/8.1.59-FAU) id VAA04080; Tue, 18 May 1999 21:19:31 GMT From: "Wolf-Dietrich Ihlenfeldt" Message-Id: <9905182319.ZM4078@torvs.ccc.uni-erlangen.de> Date: Tue, 18 May 1999 23:19:30 -0600 In-Reply-To: Dmitry Khoroshun "CCL:XML as program output?" (May 18, 16:01) References: <199905182001.QAA32996@euch4e.chem.emory.edu> Reply-To: Wolf-Dietrich.Ihlenfeldt@CCC.Chemie.Uni-Erlangen.DE X-Phones: +49-9131-85-6579 X-Fax: +49-9131-85-6566 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Dmitry Khoroshun Subject: Re: CCL:XML as program output? Cc: chemistry@ccl.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit On May 18, 16:01, Dmitry Khoroshun wrote: > Subject: CCL:XML as program output? > According to Richard Wood: > > > > But rasmol reads a "text" file format! Why change it and other programs > > that already read text files? That doesn't make any sense to me. > > This indeed makes not much sense. What use is of introducing a "type" > of the energy, like "nuclear repulsion"? You still have to read and > understand it, not just click on it with a mouse. Unix scripting > possibilities allow for many many things like sorting or similar. Most output formats of QM programs are actually very unsuitable for any scriped processing, since it is difficult to precisely locate the information you need. A hyphotical example not far from the truth: These charges you look for appear 5 lines (6 on AIX) after the magic keyword 'hooray' (provided nobody accidentially used this as job title), in multiple sets of 5-column 3-row output (7 columns if user selected 132-char paper output - this selection appears nowhere in the output -, 4 rows per set if option 'yeah' was selected, but not in conjunction with option 'nay', which results in the insertion of something completely different inbetween these lines), there is one space between the columns (on AIX, no space, but fixed column width, version-dependent magnitude), rows are separated by an empty line (before version 6.0, is was '---', after V7.0, every third row contains the program name), the end of this section can be easily identified because there are two consecutive empty lines (except on Linux with f2c V1.x, - not 2.x- there was a bug in the interpretation of the format statement, and multiple empty lines are merged into one)) And you want to write a simple script to SORT this mess? BTW, there are a number of powerful tools for XML for data extraction etc. already available. Visit alphaworks at IBM. And of course. > programs such as molden have no problems with reading text files. Have you ever looked at the code which does this? It is EVIL! No structure, no grammar, just a jungle of ad-hoc hacks. I do not want to maintain it! (And continuous maintenance is indispensible with those unstructured formats. because everythign will break with the next release) > > I guess the next step would be implementing surrounding sound into Gaussian. Only after the output has been cleaned up. > > Sincerely, > Dmitry Khoroshun > dima@euch4e.chem.emory.edu > -= 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 > >-- End of excerpt from Dmitry Khoroshun -- Dr. Wolf-D. Ihlenfeldt Computer Chemistry Center, University of Erlangen-Nuernberg Naegelsbachstrasse 25, D-91052 Erlangen (Germany) Tel (+49)-(0)9131-85-26579 Fax (+49)-(0)9131-85-26566 --- 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 From chemistry-request@server.ccl.net Tue May 18 18:26:02 1999 Received: from samba.sc.ucl.ac.be (samba.sc.ucl.ac.be [130.104.10.121]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id SAA25136 for ; Tue, 18 May 1999 18:26:02 -0400 Received: from geol.ucl.ac.be (IDENT:razvan@[130.104.92.28]) by samba.sc.ucl.ac.be (8.9.1/8.9.1/dvg-samba) with ESMTP id AAA05806 for ; Wed, 19 May 1999 00:21:23 +0200 (MET DST) Sender: razvan@samba.sc.ucl.ac.be Message-ID: <3741E702.23945279@geol.ucl.ac.be> Date: Wed, 19 May 1999 00:17:38 +0200 From: Razvan Caracas X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i586) MIME-Version: 1.0 To: chemistry@ccl.net Subject: CCL:XML as program output? Content-Type: multipart/alternative; boundary="------------E7B9626AC118AF1257AB0E4B" --------------E7B9626AC118AF1257AB0E4B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello everybody, I think that XML format (I saw its description only now) may become a good inter-exchange file format. See for example the *.CIF files (= Crystallographic Information File, documented at http://www.iucr.ac.uk) that is widespread, read and written by the most of the crystallographic softwares available now. It is a file format with definitions for every parameter etc just like XML might be. The problem is, I think, not neccesarily to find and to accept definitions like For example, energies might be marked up as: 101.8303753234 -190.784836075 the problem is in finding ways to use applet-like procedures available on different OSs. I mean, to be able to load for example 3D rendering procedures to visualize a molecule/crystal. Or to treat several *.xml files in the same time and to compare the values of the same parameters. This should be more important than just define data types (which eventually be very well made in "text" files). Also, to change the output formats of dozens of programs to a format that is not very widely used, especially considering that not everyone is using the same OS and same versions of programs, is daft. Longer we wait harder would be to impose a generally accepted file format. And it is not necessarily needed to eliminate the other formats. Besides as far as I see a text/XML file may be read by any OS and machine. The question is if we can really use XML on different OSs. Sincerely, Razvan ------------------------------------------------------------------------------------ Razvan Caracas Universite Catholique de Louvain Department of Geology and Department of Physical-Chemistry and Physics of Materials Batiment Mercator tel: 0032-(0)10-472855 3,pl. Louis Pasteur fax: 0032-(0)10-472429 1348 Louvain-la-Neuve Belgium e-mail: caracas@geol.ucl.ac.be, caracas@pcpm.ucl.ac.be ------------------------------------------------------------------------------------ --------------E7B9626AC118AF1257AB0E4B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello everybody,

I think that XML format (I saw its description only now) may become a good inter-exchange file format.
See for example the *.CIF files (= Crystallographic Information File, documented at http://www.iucr.ac.uk) that is widespread, read and written by the most of the crystallographic softwares available now. It is a file format with definitions for every parameter etc just like XML might be.
The problem is, I think,  not neccesarily to find and to accept definitions like 

For example, energies might be marked up as:
<energy type="nuclear repulsion" units="Hartrees">101.8303753234</energy>
<energy type="uhf" units="Hartrees">-190.784836075</energy>
the problem is in finding ways to use applet-like procedures available on different OSs. I mean, to be able to load for example 3D rendering procedures to visualize a molecule/crystal. Or to treat  several *.xml files in the same time and to compare the values of the same parameters. This should be more important than just define data types (which eventually be very well made in "text" files).
  
Also, to change the output formats of dozens of programs to a format that 
is not very widely used, especially considering that not everyone is 
using the same OS and same versions of programs, is daft.

Longer we wait harder would be to impose a generally accepted file format. And it is not necessarily needed to eliminate the other formats. Besides as far as I see a text/XML file may be read by any OS and machine. The question is if we can really use XML on different OSs.
 

Sincerely,
Razvan 

------------------------------------------------------------------------------------
Razvan Caracas 

Universite Catholique de Louvain
Department of Geology and Department of Physical-Chemistry and Physics of Materials
Batiment Mercator                       tel: 0032-(0)10-472855 
3,pl. Louis Pasteur                     fax: 0032-(0)10-472429
1348 Louvain-la-Neuve                   Belgium
e-mail:         caracas@geol.ucl.ac.be, caracas@pcpm.ucl.ac.be
------------------------------------------------------------------------------------
  --------------E7B9626AC118AF1257AB0E4B-- From chemistry-request@server.ccl.net Tue May 18 19:46:43 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 TAA25819 for ; Tue, 18 May 1999 19:46:43 -0400 Received: from mail.enter.net (root@mail.enter.net [63.65.0.6]) by ccl.net (8.8.6/8.8.6/OSC 1.1) with ESMTP id TAA23408 for ; Tue, 18 May 1999 19:42:01 -0400 (EDT) Received: from thinkpad.daylight.com (atmax-1-38.enter.net [207.16.153.48]) by mail.enter.net (8.9.0/8.8.8) with SMTP id TAA27439 for ; Tue, 18 May 1999 19:41:46 -0400 (EDT) Reply-To: From: "Scott Dixon" To: "CCL Mailing List" Subject: XML as program output? Date: Tue, 18 May 1999 19:40:00 -0400 Message-ID: <000401bea187$beb14ca0$163ce1cf@daylight.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Importance: Normal > > This is a pointless discussion. I'm seeing two main threads: > I don't think this is a pointless discussion at all. As one who has read the XML specs and written XML readers and writers, let me make a few points and correct a few misunderstandings about XML. First of all, XML is not "just another format". It is a language and standard to allow specification and design of data interchange languages. It is not about markup (i. e. XML is not another HTML) although another related proposed standard (XSL) allows for specification of markup, independent of the content markup (in XML). That is, >from a web point of view, one of the great advantages of XML over HTML is that XML separates semantic markup from display markup. However, for the purposes of this discussion that isn't all that important, except for the fact that there will be tools which will display XML in easy to read ways (e. g. browsers). > A) Adding vs removing tags: > The presence or absence of tags is irrelevent; the only issue is how > well-formatted the text is to start with. > o It is easy to add tags to well-formatted raw text > o It is easy to remove tags from well-formatted tagged text > o It is difficult to add tags to poorly-formatted raw text > o It is difficult to remove tags from poorly-formatted tagged text > (Spoken from the perspective of someone who spent the last several years > doing all four). XML would be appealing if it required that well-formatted > files. Unfortunately, it doesn't, or at least it doesn't any more than > HTML does. 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. Look through release notes for earlier versions of Netscape or > MSIE and see the hoops those developers had to go through to deal with all > the creative html that people cooked up. All arguments I've seen for XML > take it as an implicit fact that XML-compliant files will magically be > well-formatted and easily understandable. Guess what folks; it ain't gonna > happen. I'm not sure what "well-formatted" means in this context, but using HTML as an example is not very useful. XML, as opposed to HTL, has a way to specify exactly what is legal and what is not (the DTD or Document Type Declaration). It is possible to write legal XML which does not have a DTD, but even so, the sort of uncontrolled changes which occurred in HTML are not necessary in XML since it, as the name implies, is inherently extensible. This, in my mind, is the important advantage of XML and other self-defining formats. They allow for extension of a file format without breaking anything. For example, one of the problems with many text formats is that there is no place to put certain types of information. For example, there is no way to specify bond orders in PDB files. So if you want to write a molecule out in PDB format, you simply lose that information. However, it is possible to add another tag to an XML file and any program which parses XML can still parse that extended file. The information is not lost, although some programs which read the file may not know what to do with it. If you add bond type to a PDB file, then it is no longer a PDB file and some programs which read PDB files may fail to read your extended file format. Also, see below about name spaces. > > B) Text vs non-text > This is even more pointless. "Text" is a description of the character set > used, and not even a very good description. There is no such thing as a > program that "understands text" any more than there is a person who > "understands speech". Traditionally, "text" files are written with the 96 > ASCII characters from 32 to 127. The Gaussian file format is one such file > type. It is possible to say that "a program interprets the Gaussian file > format." Saying so does not in any way imply that it will interpret the > MOPAC file format or the PDB file format -- any more than saying that > someone understands English implies that he also understands French. XML > files *are* text in that they are written using those 96 printable ASCII > characters. So are HTML files. So is this message. So what? Actually. XML is not based on ASCII text but on Unicode, which means that it is not English language centric (a minor point to those of us in the US but it illustrates that the XML developers thought a lot more about how to do data interchange correctly that does the average designer of a file format). > > Programmatically, "text" files are often *less* easy to interpret than > binary files. There are lots of benefits to using binary file format, > including density of data and speed of interpretation. The major drawback > is that they are not readily interpretable by unassisted humans. There is also the problem that binary formats are machine specific with respect to byte order, number representation, etc. They do not make good interchange formats. They may be fine as an internal format used within a program but they are a poor choice for data interchange or archival. > > XML is "just another file format". There is no program in the world that > will magically be able to interpret XML without specific programming > effort. The programming effort to interpret XML is neither significantly > more nor significantly less than that required to interpret any other file > format (assuming a similar number of data *types* in both cases). This is the crux of the matter I think. To interpret (not parse or read) an XML file requires a common understanding about the meaning of the tags used. That is, if my XML file specifies X, Y and Z coordinates, the reader of the file still has to know that they are atomic coordinates in angstroms, for example. However, this is a issue which is dealt with in XML in a couple of ways. First of all, there is the namespace facility in XML which allows definitions of tags to be published and used. For example, the tag refers to an x datatype, the definition of which I have published at a specified URI on the net. If someone else also uses the tag it may mean an x coordinate in a unit cell. Both of these tags can be used in an XML file and the definitions can be referred to at published URIs. So there is a way to deal with conflicting definitions by specifying which one you mean or using both as appropriate. Also, the RDF (Resource Description Framework) is worth looking at (www.x3c.org/RDF) with respect to this issue. Nevertheless, it is true that XML will not magically solve all the problems with conflicting uses of terms and poorly specified concepts in chemical information. XML does not obviate the necessity for people to define what they mean. There is no such thing as a free lunch. Those software designers who don't want to play nice can still make life difficult for the rest of us. But, the designers of XML have given a lot of thought to issues of data interchange and metadata and it is worth looking hard at XML for its advantages of easy parsing, extensibility and self definition. The issue of agreeing on a commonly understood vocabulary still remains but at least with XML, there are well defined ways to deal with vocabulary definition and multiple vocabularies. Most importantly, XML allows one to extend a file format or add to a vocabulary without breaking the ability of everyone else to read that file. I notice that while I have been typing this, Henry Rzepa has also responded to many of the same issues so I'll stop here. There are a lot of other interesting issues concerning data interchange and metadata which deserve more attention than they have generally gotten from the designers of chemical file formats. There is a great deal of information about XML available on the Web. Henry mentioned some resources and the canonical XML site is www.w3c.org. Scott Dixon Metaphorics, LLC From chemistry-request@server.ccl.net Wed May 19 07:02:33 1999 Received: from org.chem.msu.su (org.chem.msu.su [158.250.32.94]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id HAA31321 for ; Wed, 19 May 1999 07:01:14 -0400 Received: from localhost (serge@localhost) by org.chem.msu.su (8.8.8/8.8.8) with SMTP id OAA15471; Wed, 19 May 1999 14:53:49 +0400 (MSD) (envelope-from serge@org.chem.msu.su) Date: Wed, 19 May 1999 14:53:49 +0400 (MSD) From: Serge Pissarev To: Vladimir Murashov cc: chemistry@ccl.net Subject: Re: CCL:Ellipsoids in OpenGL In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Vladimir! It seemed to me there is *NO* such a function but you may use different transformations to obtain the ellipsoids from spheres (accordingly to your system you may use GLU or GLAUX functions to generate spheres). The transformations is mostly See SPHERE library docs on IRIX. On Win32s, there are auxSolidSphere, auxWireSphere, gluSphere, and (for arbitrary matrix transformation) glMultMatrix functions Serge A. Pissarev QSAR and Computational Chemistry Group, Chair of Organic Chemistry Chemistry Department of Moscow State University. Email: serge@qsar.chem.msu.su WWW : http://org.chem.msu.su/~serge On Tue, 18 May 1999, Vladimir Murashov wrote: > Hi, > > I was wondering if some kind soul can direct me to an > optimized subroutine for OpenGL/GLUT > that draws an arbitrary ellipsoid. > > Thanks, > Vladimir > > Dr. Vladimir V. Murashov > Dept. Chemistry > University of British Columbia > Vancouver, BC V6T 1Z1 From chemistry-request@server.ccl.net Wed May 19 09:12:44 1999 Received: from admin.cnrs-orleans.fr (admin.cnrs-orleans.fr [163.9.1.2]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id JAA32423 for ; Wed, 19 May 1999 09:12:42 -0400 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 PAA18779 ; Wed, 19 May 1999 15:07:55 +0200 (MET DST) Received: (from hinsen@localhost) by chinon.cnrs-orleans.fr (8.8.7/8.8.7) id OAA21987; Wed, 19 May 1999 14:39:51 +0200 Date: Wed, 19 May 1999 14:39:51 +0200 Message-Id: <199905191239.OAA21987@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: bernhold@npac.syr.edu CC: chemistry@ccl.net, bernhold@npac.syr.edu In-reply-to: <199905181656.MAA02966@snake.npac.syr.edu> (bernhold@npac.syr.edu) Subject: Re: CCL:XML as program output? References: <199905181656.MAA02966@snake.npac.syr.edu> On Tue, 18 May 1999, David E. Bernholdt wrote: > You run a chemistry code -- say an SCF calculation, to be concrete. > Would you prefer that the primary output of this program be in plain > text, as nearly all packages I'm familiar with now produce, or would > you prefer it to be thoroughly marked-up XML? Both. I'd want a brief calculation protocol as text, to let me check quickly if everything looks right. But I'd want detailed results in a machine-readable format. And there XML has many advantages. > How about if the XML conformed to a standardized schema that was used > by _all_ SCF programs, so that they all marked up their output the That's of course every user's dream, but why should program developers suddenly become able to agree on standardized data formats? That sounds overly optimistic to me. I can't think of any data which is not either proprietary or insufficient! On the other hand, even with dozens of proprietary DTDs, standardizing on XML would be an advantage. All files could be fed to one and the same parser, and the fact that XML files are human-readable text files already guarantees some basic intelligibility. On Tue, 18 May 1999, David van der Spoel wrote: > chance at all to be accepted as "standard" I think the following demands > have to be met: > - Chemistry/XML format should be non proprietary, i.e. it may not be > crippled by browser vendors (like HTML). Ideally the format should be > controlled by chemists Someone will have to define one or more DTDs for chemistry, and designing DTDs is not a trivial job. If this job is left to companies (or also program authors in academia), there will probably be incompatible proprietary DTDs. If it is left to people who are not program authors, the result might be insufficient for practical use. And if it is left to some committee, it will take decades to reach a bad compromise. > - There should be a free (GPL'ed) library which programmers can use to > write xml output (callable from at least C and fortran, meaning that it > should *not* be a C++ library). Writing XML is very easy and hardly needs support libraries. The difficult part is *parsing* XML, but there are already a few parsers around. > - There need to be fast portable browsers These will probably be provided by non-chemistry people, but it remains to be seen if they will be flexible enough to permit the addition of features such as chemical structure visualization. -- ------------------------------------------------------------------------------- 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 Wed May 19 09:27:42 1999 Received: from admin.cnrs-orleans.fr (admin.cnrs-orleans.fr [163.9.1.2]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id JAA32592 for ; Wed, 19 May 1999 09:27:40 -0400 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 PAA19349 ; Wed, 19 May 1999 15:22:43 +0200 (MET DST) Received: (from hinsen@localhost) by chinon.cnrs-orleans.fr (8.8.7/8.8.7) id OAA21991; Wed, 19 May 1999 14:54:34 +0200 Date: Wed, 19 May 1999 14:54:34 +0200 Message-Id: <199905191254.OAA21991@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: Wolf-Dietrich.Ihlenfeldt@CCC.Chemie.Uni-Erlangen.DE CC: dmpc@hugh.chem.uic.edu, chemistry@ccl.net In-reply-to: <9905182216.ZM3940@torvs.ccc.uni-erlangen.de> (Wolf-Dietrich.Ihlenfeldt@CCC.Chemie.Uni-Erlangen.DE) Subject: Re: CCL:XML as program output? References: <9905182216.ZM3940@torvs.ccc.uni-erlangen.de> On Tue, 18 May 1999, Wolf-Dietrich Ihlenfeldt wrote: > with platform independence. XML IS platform-independent, > since it is ASCII and does not suffer from any byte ordering > or FP representation issues. Small correction: XML is Unicode, not ASCII. Which doesn't make it any less platform-independent, but somewhat more difficult to deal with. XML files that contain only ASCII characters and use UTF-8 encoding are of course ASCII files, and therefore writing valid XML doesn't require much effort. However, an XML-compliant parser must be able to deal with other Unicode encodings as well. -- ------------------------------------------------------------------------------- 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 Wed May 19 10:01:17 1999 Received: from ceniai.net.cu (ceniai.net.cu [169.158.128.142]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id JAA00157 for ; Wed, 19 May 1999 09:59:43 -0400 Received: from ceniai.inf.cu ([169.158.128.138]:19725 "EHLO ceniai.inf.cu" ident: "NO-IDENT-SERVICE[2]") by ceniai.net.cu with ESMTP id <47239-171>; Wed, 19 May 1999 09:52:46 -0400 Received: from oc.uh.cu by ceniai.inf.cu with bsmtp (Smail3.2) id m10k6lr-000BoAC; Wed, 19 May 1999 09:52:31 -0400 (CDT) Received: from nffuh.ff.oc.uh.cu (root@nffuh.ff.oc.uh.cu [169.158.202.134]) by ffuh.ff.oc.uh.cu (8.8.7/8.8.7/JP) with ESMTP id EAA30035; Wed, 19 May 1999 04:27:50 -0400 Received: from karin.fq.oc.uh.cu (gerardo@karin.fq.oc.uh.cu [169.158.202.18]) by nffuh.ff.oc.uh.cu (8.8.7/8.8.7/JP) with ESMTP id IAA12988; Wed, 19 May 1999 08:25:42 -0400 Received: from localhost (gerardo@localhost) by karin.fq.oc.uh.cu (8.9.0/8.8.7/JP) with SMTP id IAA17672; Wed, 19 May 1999 08:24:42 -0400 Date: Wed, 19 May 1999 08:24:42 -0400 (CDT) From: Gerardo =?ISO-8859-1?Q?Gonz=E1lez?= Aguilar To: "David E. Bernholdt" cc: chemistry@ccl.net Subject: Re: CCL:XML as program output? In-Reply-To: <199905181656.MAA02966@snake.npac.syr.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi all! My point of view is that a unified program output is a great idea, is very simple to work with it and to implement pipelines from one program to another, the principal problem will be related with their implementation in the standard packages actually used, but the effort to rewrite the code for these programs is llttle compared with the advantaged of a unified code and finally it make unnecessary translators as Babel that cannot fullfill the requirements of all people who need to do somw works with different packages Bye. -------------------------OOOooooOOO------------------------------------- | | e-mail: Gerardo Gonzalez | Dpto. de Quimica | gerardo@fq.oc.uh.cu Prof. of Chemistry | Univ. de Camaguey | or: | C. Circunv km 5 1/2 | gerardo@reduc.cmw.edu.cu | Camaguey 74650, Cuba | ------------------------<>--------<>------------------------------------- From chemistry-request@server.ccl.net Wed May 19 10:34:41 1999 Received: from ceniai.net.cu (ceniai.net.cu [169.158.128.142]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id KAA00619 for ; Wed, 19 May 1999 10:33:24 -0400 Received: from ceniai.inf.cu ([169.158.128.138]:52494 "EHLO ceniai.inf.cu" ident: "NO-IDENT-SERVICE[2]") by ceniai.net.cu with ESMTP id <47595-175>; Wed, 19 May 1999 10:26:31 -0400 Received: from oc.uh.cu by ceniai.inf.cu with bsmtp (Smail3.2) id m10k7KK-000BlvC; Wed, 19 May 1999 10:28:08 -0400 (CDT) Received: from nffuh.ff.oc.uh.cu (root@nffuh.ff.oc.uh.cu [169.158.202.134]) by ffuh.ff.oc.uh.cu (8.8.7/8.8.7/JP) with ESMTP id EAA30605; Wed, 19 May 1999 04:38:03 -0400 Received: from karin.fq.oc.uh.cu (gerardo@karin.fq.oc.uh.cu [169.158.202.18]) by nffuh.ff.oc.uh.cu (8.8.7/8.8.7/JP) with ESMTP id IAA13028; Wed, 19 May 1999 08:35:53 -0400 Received: from localhost (gerardo@localhost) by karin.fq.oc.uh.cu (8.9.0/8.8.7/JP) with SMTP id IAA17827; Wed, 19 May 1999 08:34:54 -0400 Date: Wed, 19 May 1999 08:34:54 -0400 (CDT) From: Gerardo =?ISO-8859-1?Q?Gonz=E1lez?= Aguilar To: Jonathan Brecher cc: chemistry@ccl.net Subject: Re: CCL:XML as program output? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Jonathan I am agree with your opinion, really it is usefull and standard code for chemistry, and as you wrote converters have the problem of loss of information, if these code is xml or any other is a minor problem, the principal task will be to implemment teh output of the currently used programs in the standard format, the programmers of these packages may be are disagreed with the idea and in that case and uniform output for all the chemistry programs will be a fantasy. Bye... Gerardo -------------------------OOOooooOOO------------------------------------- | | e-mail: Gerardo Gonzalez | Dpto. de Quimica | gerardo@fq.oc.uh.cu Prof. of Chemistry | Univ. de Camaguey | or: | C. Circunv km 5 1/2 | gerardo@reduc.cmw.edu.cu | Camaguey 74650, Cuba | ------------------------<>--------<>------------------------------------- From chemistry-request@server.ccl.net Wed May 19 07:34:16 1999 Received: from chris2.u-strasbg.fr (maerker@chris2.u-strasbg.fr [130.79.34.140]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id HAA31593 for ; Wed, 19 May 1999 07:34:14 -0400 Received: (from maerker@localhost) by chris2.u-strasbg.fr (8.8.8/8.8.8) id NAA01652; Wed, 19 May 1999 13:26:46 +0200 From: Christoph Maerker Message-Id: <199905191126.NAA01652@chris2.u-strasbg.fr> Subject: bystander's look: XML as program output? To: chemistry@ccl.net (ccl) Date: Wed, 19 May 1999 13:26:46 +0200 (MEST) Cc: maerker@chris2.u-strasbg.fr (Christoph Maerker) Organization: Laboratoire de Chimie biophysique, Institut Le Bel, Universite Louis Pasteur Postal-Address: 4, rue Blaise Pascal, F- 67000 Strasbourg FRANCE Phone: +33/3-88-41-53-19 Fax: +33/3-88-60-63-83 X-Mailer: ELM [version 2.4ME+ PL37 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1891 Dear all, may be the force with you and let you not implant surrounding sound in a well-known QM workhorse. (Sorry guys, I could not resist to write this TODAY). Stepping in at such a late point about text vs xml, I would like to re-focus attention to the point of "annotation", a widely-used term in bioinformatics nowadays. In this sense I agree with WDI that "tags are primarily for content decsription and not for formatting purposes". Given the millions of number- crunching machines, sequencers etc, there is an ever-increasing flood of digital information. Exa/Terabyte disk-farms could store all that, but the real problem is to find the gold-nuggets out of a heap of trash (I had no particular program in mind, I am honest). And for that purpose one needs annotated data, maybe in the form of xml or any other commonly-used format (NB I did not write agreed-upon standard). Therefore, whether current QM codes get xml-enabled in one or the other way is not the main point. They will sooner or later, e.g. by simultaneously printing tags, either for direct use by a browser or for post-processing via scripts. The full potential of annotated data is unleashed in combination with databases. This was pointed by JMC. When I did my PhD in Erlangen, we had our own, non-public archives for ab initio results (it still exists). This database just stored data from different, often unrelated projects. But now imagine a dedicated database with computed structures (e.g. potentials inhibitors of an enzyme). Tim Clark's group, as far as I know, has already done such a feasibility study of a such a "virtual" database. (Apologies to all of you working on similar projects but who I did not mention.) In short: I think there is consensus among chemists about the usefulness of and the need for annotated data; may it be in xml or any other format. Amicalement, Christoph From chemistry-request@server.ccl.net Wed May 19 11:30:28 1999 Received: from acaix1.ucis.dal.ca (acaix1.UCIS.Dal.Ca [129.173.1.50]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id LAA01521 for ; Wed, 19 May 1999 11:30:28 -0400 Received: from is2.dal.ca (murashov@IS2.Dal.Ca [129.173.1.66]) by acaix1.ucis.dal.ca (8.9.0/8.9.0) with ESMTP id MAA43588 for ; Wed, 19 May 1999 12:25:40 -0300 Received: from localhost (murashov@localhost) by is2.dal.ca (8.9.0/8.9.0) with SMTP id MAA87552 for ; Wed, 19 May 1999 12:25:39 -0300 Date: Wed, 19 May 1999 12:25:39 -0300 (ADT) From: Vladimir Murashov To: chemistry@ccl.net Subject: Ellipsoids in OpenGL Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi again, Thanks to everybody who pointed me the straightforward solution: application of glScale* command to spheres. Cheers, Vladimir P.S.: as usual the simplest is right under one's nose Dr. Vladimir V. Murashov Dept. Chemistry, University of British Columbia Vancouver, BC V6T 1Z1 Canada From chemistry-request@server.ccl.net Wed May 19 11:46:28 1999 Received: from gallium.chem.vu.nl (gallium.chem.vu.nl [130.37.144.37]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id LAA01706 for ; Wed, 19 May 1999 11:46:27 -0400 Received: from [130.37.144.139] (dysprosium.chem.vu.nl [130.37.144.139]) by gallium.chem.vu.nl (8.9.1a/8.9.1) with ESMTP id RAA47128 for ; Wed, 19 May 1999 17:41:39 +0200 X-Sender: tevelde@chem.vu.nl Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 May 1999 17:42:11 +0200 To: CCL_posting From: Bert te Velde Subject: ADF 1999 Dear all, Today we are releasing the 1999 version of the Amsterdam Density Functional (ADF). Visit our website for information about this release, or contact us directly with any questions you may have. Best regards *************************************************** * please note that our FAX number has CHANGED * *************************************************** ------------------------------------------------------------------ Bert te Velde SCIENTIFIC COMPUTING & MODELLING NV Phone: +31-20-44 47626 Vrije Universiteit, Theoretical Chemistry Fax: +31-20-44 47629 De Boelelaan 1083 E-mail:tevelde@scm.com 1081 HV Amsterdam; The Netherlands http://www.scm.com ------------------------------------------------------------------ From chemistry-request@server.ccl.net Wed May 19 12:24:27 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 MAA02198 for ; Wed, 19 May 1999 12:24:27 -0400 Received: from schrodinger.com (root@thermidore.schrodinger.com [192.156.98.99]) by ccl.net (8.8.6/8.8.6/OSC 1.1) with ESMTP id MAA09427 for ; Wed, 19 May 1999 12:19:35 -0400 (EDT) Received: from sandra.schrodinger.com (sandra.schrodinger.com [206.231.140.250]) by schrodinger.com (8.8.5/8.8.5) with ESMTP id JAA11940 for ; Wed, 19 May 1999 09:23:44 -0700 Received: from localhost (shenkin@localhost) by sandra.schrodinger.com (8.8.5/8.8.5) with ESMTP id MAA28697 for ; Wed, 19 May 1999 12:23:39 -0400 X-Authentication-Warning: sandra.schrodinger.com: shenkin owned process doing -bs Date: Wed, 19 May 1999 12:23:39 -0400 (EDT) From: Peter Shenkin To: CCL Mailing List Subject: Re: CCL:XML as program output? In-Reply-To: <000401bea187$beb14ca0$163ce1cf@daylight.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I've been enjoying this discussion. Here's an essay on the "big picture", as I see it. There have been several extensible file formats and/or APIs proposed and used in chemical applications over the past few years. These include: asn.1: Finds its greatest use in telecommunications, but is used by NIH/NCBI to encode both genetic and chemical-structural data. STAR and STAR/CIF: STAR was originally proposed in a chemical context; STAR/CIF both limits the syntax of STAR and defines a data dictionary with semantics useful to crystallographers, expecially small-molecule crystallographers. XML and XML/CML: The latter, as I understand it, attempts to define types and semantics for types that will be useful for chemists. But I know least about this one, especially today. CEX: This never really took off, but is an API which Dave Weininger of Daylight Software proposed for exchange of chemical data. We are going to be distributing a new file format, called the m2io format, with our new MacroModel interface, due out this summer. All the schrodinger products will be able to read this format and we will probably make the spec and the API to read/write it publically available, as we did with our old mmio format (whose API code happily resides in the CCL archive :-) ). However, we want to get some field experience with m2io first. The m2io format will share some of the features of those listed above. All of the above have well-defined, extensible syntaxes. So if tomorrow you decide you need to store, say, two partial charges for each atom instead of one, you can do it without worrying about forward/back compatibility. (Why two charges? Well, maybe one comes from ab-initio computations and the other comes from a forcefield assignment. Why in the same file? Well, maybe you have a graphics interface and you want to color-code the atoms where these two differ the most.) The point about the extensible nature of these formats is that, with a few exceptions, if you have data in one of these formats, it is easy in principle to convert it to another one -- including even the extended features. 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 format allows infinite nesting, but the API only supports a limited degree right now, like CEX and STAR/CIF. 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. 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. How do the other APIs/formats handle the semantics of the data tags? Well, one approach is to set up a committee to define, as precisely as possible, what the different tags (like CHARGE) are going to mean. This is the CIF and, AFAIK, the CML approach. My understanding is that CIF, at least, has been terribly successful within its application domain. The concern I have about this approach is, "Would the committee's definitions meet my own needs?". Also, life is easier when one is working in a narrow domain, as CIF does. There, the committee could use international crystallographic conventions for tagging space groups and so on, and I'm sure the crystallographers had no trouble agreeing on what a fractional coordinate is. But when we attempt to deal with the broader field of chemistry in general, where we have ambiguities as well as subtleties, defining semantics for a long list of tags 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 course, a lot also have to do with the format's inability to encode far simpler things whose semantics we would have less trouble agreeing on. ASN.1 is widely used in a variety of separate, narrow contexts in the telecommunications field. The data definitions ("abstract syntaxes") were for the most part derived by committees or in in response to RFPs within these areas. The NIH/NCBI abstract syntax definitions, in contrast, were devised within NIH and promulgated to users of their databases and software. We took a very close look at using their biostructural data definitions, but eventually determined that they were not well-suited to the encoding of general chemical structures; there was a built-in residue-based bias, appropriate to biopolymers but difficult to extend to other things. We then devised our own ASN.1 abstract syntax and even build molecules using it. But we abandoned this approach because we wanted a file format that would be more readable than any ASN.1 format (even the ascii "value notation") provides. IO was ponderous and the format was verbose. 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. For instance, we have a broader API that uses m2io called mmct, which manages ct's, or connection tables (assemblies of molecules). Some of our data tags contain an "mmct" designation; for example, in effect, "mmct_x" says "this is 'x' in the sense that mmct understands it". (For instance, it might be an atomic x coordinate.) Depending how well you feel you understand what mmct does, you may use each such item freely in your own program. You may, of course, also add to the file new data for your own reader; say, "foo_x", which might mean "x as foo understands it." Of course, anybody is free to read or write anybody else's data types. 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 standards and emerging standards are large. Just understanding them well enough to write our own parser correctly would have been a huge task -- perhaps larger, even, than that of actually writing the parser. We could have used our reader-encoding system in CEX tags of our own devising, but we wanted something with a defined file format; CEX is an API only. If CEX had caught on among others, perhaps we would have gone with it and perhaps added a file format rather like m2io to CEX. But in the end we found it easier to start >from scratch. The great thing about wheels is that they can be so easily reinvented. :-) But if one of the other formats -- say, CML -- becomes popular, and if API code becomes widely available, it will be easy to write translators to and from m2io. In the meantime, we've come up with something that we feel will be very useful to us, and hopefully, in time, to others as well. -P. -- ********* Peter S. Shenkin; Schrodinger, Inc.; (201)433-2014 x111 ********* *********** shenkin@schrodinger.com; http://www.schrodinger.com *********** From chemistry-request@server.ccl.net Wed May 19 12:52:10 1999 Received: from smb.chem.niu.edu (smb.chem.niu.edu [131.156.9.3]) by server.ccl.net (8.8.7/8.8.7) with SMTP id MAA02519 for ; Wed, 19 May 1999 12:52:10 -0400 Received: from smb by smb.chem.niu.edu via SMTP (940816.SGI.8.6.9/940406.SGI) for id LAA16932; Wed, 19 May 1999 11:39:01 -0500 Sender: smb@smb.chem.niu.edu Message-ID: <3742E924.167E@smb.chem.niu.edu> Date: Wed, 19 May 1999 11:39:00 -0500 From: Steven Bachrach X-Mailer: Mozilla 3.01 (X11; I; IRIX 5.3 IP12) MIME-Version: 1.0 To: computational chemistry list Subject: Re: XML as program output? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There have been a number of very good replies concerning the XML issue, but as one who has spent too much time on the web, I want to address the XML isssue from a slightly different perspective. I had been in communication with Perter Murray-Rust and Henry Rzepa about the CML project for about a year before I was able to finally meet Peter in person for a demo. Before that demo, I had interpreted XML/CML as being yet another file format, though one that was very flexible and non-proprietary. I was truly amazed at the demo Peter gave of the power of XML/CML and it is often quite a task now to truly capture what XML/CML can do in presentations I give. Some of this has been mentioned by many already on this list, but the key to me is this: XML/CML allows for the true separation of data from its representation. What this means is that author's work (be it a real human-written article or a computer-generated output file) can be provided with ALL of the data present. The user (reader) can then use a set of tools that he or she wants to use to interact with that data. This means that for example, one person could read the article as a pdf file, one could use a web browser to read the text coupled with a molecular visualization tool and another could use the JUMBO browser that richly integrates text and molecular data visualization tools in a dramaticlaly radical way. Instead of being forced to use single (or limited) tool set, XML/CML can open up chemical data to an unlimited variety of ways of interacting with the data and information. XML/CML is not simply a new file format. It is much richer that this. XML is to data as how SGML relates to words. I do not see leagcy formats evaporating into the mist. But I do see all major software houses providing the option to obtain XML/CML output as more XML-aware tools become widespread. Instead of this being a revolution that will require us to chuck old osftware and buy new software (i.e the Windows 3.1 to Windows 95 change), I see a slow and steady movment toward an XML information exchange that takes place behind the scenes. In fact, many web sites are already XML-based (most online catalog services for example). Steve -- Steven Bachrach Department of Chemistry and Biochemistry Northern Illinois University DeKalb, IL 60115 Phone: (815)753-6863 smb@smb.chem.niu.edu Fax: (815)753-4802 From chemistry-request@server.ccl.net Wed May 19 15:07:49 1999 Received: from fsuj20.rz.uni-jena.de (fsuj20.rz.uni-jena.de [141.35.1.18]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id PAA04349 for ; Wed, 19 May 1999 15:07:44 -0400 Received: from al.bundy.uni-jena.de (al.bundy.uni-jena.de [141.35.147.40]) by fsuj20.rz.uni-jena.de (8.9.1a/8.9.1) with SMTP id VAA25858 for ; Wed, 19 May 1999 21:02:47 +0200 (MET DST) Message-Id: <199905191902.VAA25858@fsuj20.rz.uni-jena.de> Received: by al.bundy.uni-jena.de (1.37.109.4/16.2) id AA25375; Wed, 19 May 99 21:07:56 +0200 From: Michael Braeuer Subject: NBO failure To: CHEMISTRY@server.ccl.net (chemistry list) Date: Wed, 19 May 99 21:07:56 METDST Mailer: Elm [revision: 70.85] Hi, A successful SCF run gives the error message: *************************************************** Sum of Mulliken charges= 0.00000 Electronic spatial extent (au): = 9272.9554 Charge= 0.0000 electrons Dipole moment (Debye): X= -6.8834 Y= 1.3537 Z= -8.1577 Tot= 10.7593 NBO cannot handle linearly dependant basis sets. *************************************************** and does not print the NBO analysis. Then the job continued normally until the end of the program. In a serie of calculations this was the only one to fail. Is it possible to go around this problem ? Thank you very much in advance Micha The input goes as follows: ******************************** $RunGauss #test RHF/6-31+G(d) pop=nboread scf=direct A4 sessel conf b 0 1 1 -4.469366 .014238 1.428143 6 -4.535969 -.268026 .385380 7 -3.512264 -1.282258 .129578 6 -3.375457 -2.197685 1.262078 3 -1.794357 -.075212 .053909 7 -3.041367 1.581121 -.349843 6 -4.364591 .970805 -.492356 6 -2.928038 2.375475 .874803 6 -2.710391 2.403715 -1.507505 8 -.652438 -.058577 1.394366 6 .530473 -.339173 1.704714 6 1.497965 -.508346 .472489 6 2.018527 .896560 .115493 6 2.894112 1.526263 1.004801 6 3.354545 2.808693 .763803 6 2.955616 3.499740 -.373336 6 2.082028 2.892075 -1.256143 6 1.613645 1.605535 -1.009196 16 .494035 -1.309770 -.843219 6 1.709878 -1.677727 -2.144148 6 2.877684 -2.540302 -1.674829 8 1.013038 -.453218 2.802953 16 2.848795 -1.635049 .991411 6 -3.768473 -2.030806 -1.094997 1 -5.539290 -.672163 .235031 1 -4.497906 .699747 -1.532320 1 -5.155051 1.685066 -.254417 1 -1.719880 2.821873 -1.383207 1 -2.714454 1.799772 -2.407433 1 -3.415453 3.225797 -1.641626 1 -1.921186 2.758585 .964732 1 -3.628853 3.211961 .870755 1 -3.115992 1.766496 1.747363 1 -4.302390 -2.739900 1.457129 1 -2.592524 -2.914574 1.053376 1 -3.090743 -1.648219 2.148557 1 -3.810618 -1.369498 -1.951162 1 -2.964882 -2.736788 -1.260878 1 -4.708252 -2.583298 -1.043522 1 3.319250 4.494325 -.562508 1 4.024284 3.269765 1.468066 1 3.204356 1.010403 1.892432 1 .925243 1.166366 -1.704526 1 1.758913 3.411473 -2.1418460 1 2.074263 -.753811 -2.575980 1 1.142786 -2.194656 -2.910198 1 2.510719 -3.497117 -1.319483 6 3.713229 -1.871511 -.586942 1 4.106866 -.922479 -.935808 1 3.516452 -2.732763 -2.535459 1 4.563426 -2.497246 -.339361 $nbo reson bndidx $end ********************************************* -- Michael Braeuer http://www.uni-jena.de/chemie/anders/micha.htm PhD Student E-mail: brauer@al.bundy.uni-jena.de IOMC FSU Jena Tel: ++49/3641/948217 Humboldtstrasse 10 Fax: ++49/3641/948212 07743 Jena Germany From chemistry-request@server.ccl.net Wed May 19 11:57:20 1999 Received: from pnl.gov (relay.pnl.gov [130.20.128.34]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id LAA01920 for ; Wed, 19 May 1999 11:57:20 -0400 Received: from pnlmse1.pnl.gov by pnl.gov (PMDF V5.1-12 #28154) with ESMTP id <01JBDJ9H8CJ49253TX@pnl.gov> for chemistry@ccl.net; Wed, 19 May 1999 08:50:35 PDT Received: by PNLMSE1.pnl.gov with Internet Mail Service (5.5.2448.0) id ; Wed, 19 May 1999 08:50:34 -0700 Date: Wed, 19 May 1999 08:50:24 -0700 From: "Jones, Donald R (PNNL)" Subject: NWChem/Ecce Tutorial, July 19-20, 1999 To: chemistry@ccl.net Message-id: <9E7114DE3DF0D21192F80008C7A49DC82186E1@pnlmse8.pnl.gov> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: text/plain; charset="iso-8859-1" NWChem/Ecce Tutorial July 19 & 20, 1999 Environmental Molecular Sciences Laboratory (EMSL) Pacific Northwest National Laboratory (PNNL) Richland, WA The EMSL's Theory, Modeling and Simulations directorate would like to invite you to attend a special 2 day training session for the Molecular Science Computational Facility (MSCF) parallel high performance computational chemistry software, NWChem, and the associated user interface, Ecce. This software developed by our High Performance Computational Chemistry (HPCC) and Extensible Computational Chemistry Environment (Ecce) research groups could significantly contribute to solving your computational needs in the MSCF. In the HPCC group we have been developing NWChem version 3.2.1, which is supported and maintained within the EMSL and offers unique capabilities with respect to scalability as a function of both molecular system size as well as massively parallel processor (MPP) hardware system size (see the attached NWChem Functionality and Capabilities description). In the Ecce group we have been developing Ecce version 1.4.2, which is also supported and maintained within the EMSL and offers unique capabilities, incorporating all sets of the problem solving process into an integrated graphical user interface connected to an object-oriented database. On July 19 and 20 our consultants and development groups will host an on-site tutorial/mini-symposium for NWChem/Ecce users. The intent is to spend the first day-and-a-half training potential NWChem/Ecce users and devoting the last half-day to laboratory work with the instructors/developers. This workshop will be held at the EMSL where we can provide hands on access to the MSCF software and hardware facilities. If you or any members of your research team are interested in attending this tutorial/mini-symposium please take a few moments to fill out and return the enclosed information request form. Attendance is limited, so please return the registration form by no later than June 30, 1999. If you are a Foreign National your registration has to be in by May 28, 1999. A block of rooms has been reserved for attendees at the Best Western Tower Inn in Richland, WA, (509) 946-4121 FAX (509) 946-2222. Rates are $50.00 single. Please call the hotel directly before June 18, 1999, referencing "NWChem Tutorial" to make your reservations. The hotel offers shuttle service to and from the airport. We look forward to partnering with you and using NWChem and Ecce to solve your grand challenges in computational chemistry. For Functionality and Capabilities featured please see the following web pages: NWChem 3.2.1 http://www.emsl.pnl.gov:2080/docs/nwchem/nwchem.html Ecce 1.4.2 http://www.emsl.pnl.gov:2080/docs/ecce/ Please plan on staying for the EMSL Users meeting and EMSL Symposia which will be held July 21-24. * July 21-22 - Environmental Chemistry and Transport * July 21-22 - Massively Parallel Computing in the Environmental Molecular Sciences * July 23-24 - Physics and Chemistry of Oxide Surfaces * July 23-24 - Structural and Functional Proteomics Web page for this event is at http://www.emsl.pnl.gov:2080/new/user_meeting.html NWChem/Ecce Tutorial Registration July 19 & 20, 1999 EMSL Building On-line registration for the tutorial is available (preferred) at: http://www.emsl.pnl.gov:2080/capabs/mscf/training/index.html Please complete (printed legibly or typed) the following and fax back to Lori Freeland at (509) 366-0420 by June 30, 1999. Foreign Nationals will need to submit their Registration no later than May 28, 1999. Late submissions will not be honored. Full name (middle name is mandatory): Date of birth: Place of birth (City and Country): Citizenship: Social Security number: Passport number and expiration date (if not US citizen): Position title: Business Address: Phone: Fax: email: For lodging accommodations, please contact the *Best Western Tower Inn on (509) 946-4121 FAX (509) 946-2222. Rates are $50.00 single. Please reference "NWChem Tutorial" to receive the special rates, again by June 18, 1999. Tower Inn provides a shuttle service to and from the airport. DRAFT AGENDA NWChem/Ecce Tutorial Monday, July 19: 8:00am EESB building for badging 8:20 Walk to EMSL Building (across the street from EESB) Users Training 8:30 NWChem Introduction functionality; targets; expectations; supported platforms; user support; WWW pages 9:10 Ecce Introduction functionality; targets; expectations; supported platforms; user support; WWW pages 9:50 Break 10:00 NWChem input input file structure: start, continue & restart, memory, title, print & no print, set & unset, stop, task, charge, geometry, basis & ecp 11:00 SCF & DFT 11:30 Lunch - EMSL Dining Room 1:00 Optimization & Properties optimization; properties; esp; nbo 1:45 Introduction to MSCF Scientific Consulting Ecce Input calc. manager; builder; calc. editor; basis set 2:00 Ecce Demonstrations machine browser; launcher; calc. viewer; calc. browser 3:00 Break 3:10 Lab 5:00 End for day Tuesday, July 20: 8:00am Bus departs Tower Inn to EMSL Building 8:30 Correlated Methods MP2, MCSCF, CI, CCSD(T) 9:00 Molecular Dynamics Classical MD - functionality; domain decomposition; file structure; example calculations QMD - functionality QM/MM - functionality 10:00 Break 10:10 Using the IBM-SP logging on; loadl commands; NWChem job script 11:10 Users wrap-up 11:40 Lunch Break 1:00 SDM 1:30 Optional Lab 5:00 End for day Don Jones, Ph.D. Technical Group Leader MSCF Scientific Consulting Environmental Molecular Science Laboratory Pacific Northwest National Laboratory 3335 Q Ave, MS K8-91 Richland, WA 99352 Phone: 509-376-7966 Email: dr.jones@pnl.gov FAX: 509-376-0420 Web: www.emsl.pnl.gov From chemistry-request@server.ccl.net Wed May 19 17:51:08 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 RAA06098 for ; Wed, 19 May 1999 17:51:08 -0400 Received: (qmail 20965 invoked by uid 417); 19 May 1999 22:07:53 -0000 Received: from 1cust155.tnt1.det1.da.uu.net (HELO kressj.www.microsoft.com) (153.34.15.155) by smtp.softhome.net with SMTP; 19 May 1999 22:07:53 -0000 Message-ID: <000801bea241$023738e0$9b0f2299@kressj.www.microsoft.com> From: "Jim Kress" To: "Michael Braeuer" , "chemistry list" Subject: Re: CCL:NBO failure Date: Wed, 19 May 1999 17:46:05 -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 Which version of Gaussian are you using? 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: Michael Braeuer To: chemistry list Date: Wednesday, May 19, 1999 3:28 PM Subject: CCL:NBO failure >Hi, > >A successful SCF run gives the error message: > >*************************************************** >Sum of Mulliken charges= 0.00000 >Electronic spatial extent (au): = 9272.9554 >Charge= 0.0000 electrons >Dipole moment (Debye): >X= -6.8834 Y= 1.3537 Z= -8.1577 Tot= 10.7593 >NBO cannot handle linearly dependant basis sets. >*************************************************** > >and does not print the NBO analysis. Then the job continued normally >until the end of the program. >In a serie of calculations this was the only one to fail. >Is it possible to go around this problem ? > >Thank you very much in advance > >Micha > > >The input goes as follows: > >******************************** >$RunGauss >#test RHF/6-31+G(d) pop=nboread scf=direct > >A4 sessel conf b > >0 1 >1 -4.469366 .014238 1.428143 >6 -4.535969 -.268026 .385380 >7 -3.512264 -1.282258 .129578 >6 -3.375457 -2.197685 1.262078 >3 -1.794357 -.075212 .053909 >7 -3.041367 1.581121 -.349843 >6 -4.364591 .970805 -.492356 >6 -2.928038 2.375475 .874803 >6 -2.710391 2.403715 -1.507505 >8 -.652438 -.058577 1.394366 >6 .530473 -.339173 1.704714 >6 1.497965 -.508346 .472489 >6 2.018527 .896560 .115493 >6 2.894112 1.526263 1.004801 >6 3.354545 2.808693 .763803 >6 2.955616 3.499740 -.373336 >6 2.082028 2.892075 -1.256143 >6 1.613645 1.605535 -1.009196 >16 .494035 -1.309770 -.843219 >6 1.709878 -1.677727 -2.144148 >6 2.877684 -2.540302 -1.674829 >8 1.013038 -.453218 2.802953 >16 2.848795 -1.635049 .991411 >6 -3.768473 -2.030806 -1.094997 >1 -5.539290 -.672163 .235031 >1 -4.497906 .699747 -1.532320 >1 -5.155051 1.685066 -.254417 >1 -1.719880 2.821873 -1.383207 >1 -2.714454 1.799772 -2.407433 >1 -3.415453 3.225797 -1.641626 >1 -1.921186 2.758585 .964732 >1 -3.628853 3.211961 .870755 >1 -3.115992 1.766496 1.747363 >1 -4.302390 -2.739900 1.457129 >1 -2.592524 -2.914574 1.053376 >1 -3.090743 -1.648219 2.148557 >1 -3.810618 -1.369498 -1.951162 >1 -2.964882 -2.736788 -1.260878 >1 -4.708252 -2.583298 -1.043522 >1 3.319250 4.494325 -.562508 >1 4.024284 3.269765 1.468066 >1 3.204356 1.010403 1.892432 >1 .925243 1.166366 -1.704526 >1 1.758913 3.411473 -2.1418460 >1 2.074263 -.753811 -2.575980 >1 1.142786 -2.194656 -2.910198 >1 2.510719 -3.497117 -1.319483 >6 3.713229 -1.871511 -.586942 >1 4.106866 -.922479 -.935808 >1 3.516452 -2.732763 -2.535459 >1 4.563426 -2.497246 -.339361 > >$nbo reson bndidx $end > >********************************************* >-- >Michael Braeuer http://www.uni-jena.de/chemie/anders/micha.htm >PhD Student E-mail: brauer@al.bundy.uni-jena.de >IOMC FSU Jena Tel: ++49/3641/948217 >Humboldtstrasse 10 Fax: ++49/3641/948212 >07743 Jena >Germany > >-= 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 > > > >