From rgab@proteus.co.uk Fri Jul 11 10:06:26 1997 Received: from petersgate.proteus.co.uk for rgab@proteus.co.uk by www.ccl.net (8.8.3/950822.1) id JAA07220; Fri, 11 Jul 1997 09:49:50 -0400 (EDT) Received: from Icthus.proteus.co.uk (Icthus [193.115.24.114]) by petersgate.proteus.co.uk (8.6.12/8.6.6) with ESMTP id OAA28712; Fri, 11 Jul 1997 14:12:26 GMT Message-Id: <199707111412.OAA28712@petersgate.proteus.co.uk> From: Richard Bone Date: Fri, 11 Jul 1997 14:39:10 +0100 To: CHEMISTRY@www.ccl.net Subject: SMILES Database? Cc: diversity@LISTSERV.ARIZONA.EDU Does anyone know of a public-domain database of SMILES strings for commonly- occurring small organic molecules and functional groups? I'm looking for something containing several hundred or more species. It would need to be something in ASCII format, for general utility, i.e., not in a format specific to some commercial package. Richard Bone P.S. #1 - Yes - I've done a web-search already; P.S. #2 - No, I don't have the Daylight software here. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Richard G. A. Bone, Ph.D. | | | Senior Computational Chemist | | | Proteus Molecular Design Ltd. | Tel: +44 (0)1625 500555 | | Lyme Green Business Park | Fax: +44 (0)1625 500666 | | Macclesfield, Cheshire | Email: rgab@proteus.co.uk | | United Kingdom SK11 0JL | Web: http://www.proteus.co.uk | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From support@mathtrek.com Fri Jul 11 10:14:51 1997 Received: from granite.sentex.net for support@mathtrek.com by www.ccl.net (8.8.3/950822.1) id JAA07153; Fri, 11 Jul 1997 09:40:06 -0400 (EDT) Received: from p22a.lithium.sentex.ca (p7a.neon.sentex.ca [207.245.212.200]) by granite.sentex.net (8.8.5/8.6.9) with SMTP id JAA06840; Fri, 11 Jul 1997 09:48:49 -0400 (EDT) Message-Id: <3.0.16.19970711093433.2f5f6850@mathtrek.com> X-Sender: mathtrek@mathtrek.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Fri, 11 Jul 1997 09:37:27 -0400 To: Konrad Hinsen , online@mactech.com, chemistry@www.ccl.net From: "W. R. Smith" Subject: Re: CCL:Object-oriented means for computational chemistry programming Cc: chemistry@www.ccl.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hello again, At 12:25 PM 7/11/97 +0200, Konrad Hinsen wrote: >> But, in a completely undefensible statement of preference: today, new >> code should be built in C/C++ (IMHO). I respect the fact that a huge [...] > >I don't disagree in principle, but a few clarifications can't hurt >(which are of course largely my personal opinion!): > >- C is no more OO than Fortran, but it doesn't have most of Fortran's > most severe problems. But Fortran-90 is no worse than C, and in some > respects better. i.e. Fortran can be OO too. A quote by a distinguished scientist that I recall from a scientific meeting about 10 years ago: "I don't know what type of programming language scientists will be using in the next millenium, but it will be CALLED Fortran" i.e. Fortran will evolve over time to incorporate newly desired features > >- The main advantage of C is support: there is a C compiler for every > imaginable machine, and there are plenty of high-quality libraries. > But there is little support for numerical work, and indeed many C > compilers are rather bad at optimizing standard numerical code. Note also that Microsoft seems to have dropped Fortran support - passed it on to DEC, it would appear. > >- C++ is an exceedingly complicated language, largely due to its > compatibility to C. It may seem simple at first, but the more > you get into the details the more surprises you will find. > Worse, there is a frightening number of "undefined" situations, > meaning that the meaning of certain pieces of code is compiler > dependent. Writing solid and portable C++ code requires a lot of > experience. The payoff may be worth it for professional programmers, > but most scientists are not professional programmers. > >The bottom line: no single language is perfect. I think scientists >should get used to the idea of mixed-language programming. For >a small number-crunching subroutine the best choice may well be >Fortran, but for the majority of a non-trivial program it certainly >isn't. But all modern operating systems have provisions to link >code in different languages together. > >Scientists should also have a closer look at high-level languages. >They make development and testing substantially easier by taking care >of much detail automatically. Of course that comes at a price in terms >of speed, but the majority of a typical scientific program is *not* >time-critical. The CPU intensive parts are specific subroutines that >can still be implemented in a low-level language. e.g. a Visual Basic front-end with Fortran or C .DLL's > >My personal recommendation for a high-level language is Python. It is >sufficiently simple, has a clear syntax, and a very convenient >interface to low-level languages. For C code, a Python interface can >even be generated automatically with a tool called SWIG. More on >Python at http://www.python.org, and on my "Python for Science" page >at http://starship.skyport.net/crew/hinsen/. Finally, for those who >don't mind a trip to San Jose, the 6th International Python Conference >from 14-17 October in San Jose will have tutorials, presentations, and >discussions on scientific applications of Python. No slight against Python, but we all remember the following historical sequence: Algol vs Fortran (1960's) PL1 vs Fortran (1970's) Pascal vs Fortran (1980's) and now, it's C vs Fortran On the left-hand side, it has usually been CS (computer-science) types. On the RH side, it has usually been scientists/engineers. > >-------This is added Automatically by the Software-------- >-- Original Sender Envelope Address: hinsen@lmspc1.ibs.fr >-- Original Sender From: Address: hinsen@ibs.ibs.fr >CHEMISTRY@www.ccl.net: Everybody | CHEMISTRY-REQUEST@www.ccl.net: Coordinator >MAILSERV@www.ccl.net: HELP CHEMISTRY or HELP SEARCH | Gopher: www.ccl.net 73 >Anon. ftp: www.ccl.net | CHEMISTRY-SEARCH@www.ccl.net -- archive search > Web: http://www.ccl.net/chemistry.html > > > -- W. R. Smith, PhD, P. Eng., Senior Scientist, Mathtrek Systems -- 3-304 Stone Road West, Suite 165, Guelph, Ontario CANADA N1G 4W4 EMail: support@mathtrek.com Tel:519-763-1356,FAX:519-763-4525 --------------------- http://www.mathtrek.com --------------------- -Mathtrek Systems - Home of EQS4WIN Chemical Equilibrium Software - From ccl@www.ccl.net Fri Jul 11 11:17:35 1997 Received: from bedrock.ccl.net for ccl@www.ccl.net by www.ccl.net (8.8.3/950822.1) id KAA07749; Fri, 11 Jul 1997 10:57:27 -0400 (EDT) Received: from relay5.UU.NET for frisch@lorentzian.com by bedrock.ccl.net (8.8.6/950822.1) id KAA07109; Fri, 11 Jul 1997 10:57:23 -0400 (EDT) Received: from uucp6.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp6.UU.NET [192.48.96.37]) id QQcxtb26576; Fri, 11 Jul 1997 10:57:31 -0400 (EDT) Received: from m10.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Fri, 11 Jul 1997 10:57:23 -0400 Received: from holly by m10.lorentzian.com; Fri, 11 Jul 1997 10:08:21 -0400 Received: (from frisch@localhost) by holly (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA11011 for chemistry@ccl.net; Fri, 11 Jul 1997 10:08:16 -0400 From: frisch@lorentzian.com (Mike Frisch) Message-Id: <199707111408.KAA11011@holly> Subject: Re: CCL:G:G:Gaussian on a Mac ? ---Or Other Platforms To: chemistry@ccl.net Date: Fri, 11 Jul 1997 10:08:16 -0400 (EDT) In-Reply-To: <199707102154.RAA07432@helix.nih.gov> from "M. Nicklaus" at Jul 10, 97 05:54:37 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit M. Nicklaus writes: > > Hi, > > On Thu, 10 Jul 97, "Frederick R. Bennett" > > I know that Gaussian Inc. hates this sort of thing but I will ask anyway. I > > am wondering whether anyone has G94 running on a PowerMac running one of the > > Linux operating systems (MKLinux or the non-Micro Kernal). > > > > Just as a matter of opinion, I think that Gaussian Inc. should seriously > > consider supporting this platform, as they do the various Unices running on > > Intel machines. The motorola PowerPC chips are leaving Intel Pentiums for > > dead at the moment and with the new generation motorola chips on the way > > out, fast system buses and new cacheing technology, Mac's or Mac clones > > should/can provide the hardware for some high power/cost ratio workstations > > for chemistry. > > Since this can has been opened, let me chip in with a remark and a question. > > 1. I agree with Frederick R. Bennett in that Gaussian Inc. should support > more of the new fast, and *cheap*, platforms such as PowerPC systems > running Linux. I'd like to expand this request to include Alpha CPU systems > running axp Linux. These chips are even faster than the PowerPC's. We've > benchmarked them with other software. 500 MHz machines (non-DEC) can be had > for $5,000-6,000. The 600 MHz 21164 chip based systems are basically shipping > (albeit expensive, ~$11k), and the 800 MHz CPUs are in the pipeline. > We at Gaussian, Inc. agree with this, but in practice it requires a reliable operating system, and this is definately not the case for Linux/Alpha, and is questionable for Linux/PPC. > 2. We've tried to compile G94, Rev. E.1 for such a 21164 500 MHz Alpha based > system, running RedHat Linux 4.1, kernel v. 2.0.27 --- unfortunately, > unsuccessfully so far. We've experienced problems with f2c, gcc, as well as > the linker. So therefore my question: Has anyone been able to get G94 to > run on this platform? If yes, how? > We have an Alphax/Linux machine in house but Linux for Alpha has turned out to be very, very far from the stable environment Linux is for Intel machines. For example, there are well-documented and very serious problems linking large programs which have not yet been resolved. Anyone interested can subscribe to the Linux/Alpha mailing list and receive a dozen or so examples PER DAY of things that work under Linux/Intel but not under Linux/Alpha. When Linux is actually stable for production use on processors other than Intel, we certainly intend to support Gaussian there. Mike Frisch Gaussian, Inc. From bernhold@tarkovsky.npac.syr.edu Fri Jul 11 12:11:33 1997 Received: from postoffice.npac.syr.edu for bernhold@tarkovsky.npac.syr.edu by www.ccl.net (8.8.3/950822.1) id LAA07939; Fri, 11 Jul 1997 11:15:50 -0400 (EDT) Received: from tarkovsky.npac.syr.edu (tarkovsky-007.npac.syr.edu [128.230.7.175]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with ESMTP id LAA28557 for ; Fri, 11 Jul 1997 11:15:52 -0400 (EDT) Received: from localhost (bernhold@localhost) by tarkovsky.npac.syr.edu (8.8.5/8.7.1) with SMTP id LAA26253 for ; Fri, 11 Jul 1997 11:15:52 -0400 (EDT) Message-Id: <199707111515.LAA26253@tarkovsky.npac.syr.edu> X-Authentication-Warning: tarkovsky.npac.syr.edu: bernhold@localhost didn't use HELO protocol To: chemistry@www.ccl.net Subject: Re: CCL:Object-oriented means for computational chemistry In-reply-to: <9706118686.AA868636205@sctepsc2.sct.co.uk> Date: Fri, 11 Jul 1997 11:15:52 -0400 From: "David E. Bernholdt" There have been a lot of interesting and useful messages in this thread, but I think there is a core point that hasn't been emphasized enough: There is a difference between what I will refer to as "object-oriented design" (OOD) and "object-oriented languages" (OOL). I am intentionally avoiding the phrase "object-oriented programming" because I think it muddies the distinction. According to Booch ("Object-Oriented Analysis and Design"), the four basic elements of the object model of programming are o Abstraction -- extracting the essential characteristics that distinguish one object from another. o Encapsulation -- serves to separate the outside world's interface to and abstraction from its (internal) implementation o Modularity -- being able to decompose a system into a set of loosely coupled modules. o Hierarchy -- ranking or ordering of abstractions. At a basic level, these are little more than the ideas of what constitutes "good programming" that most of us have heard or read about from time immemorial, and which most of us (based on chemistry code I've seen) largely ignore. One can DESIGN software based on these principles (OOD) regardless of what language the software is to be implemented in. There are some languages around these days which support (or enforce) an object-oriented model to a greater extent than others. These we might refer to as object-oriented LANGUAGES. The problem with the popular phrase "object-oriented programming" is that people tend to lump the DESIGN and the IMPLEMENTATION together when they think of PROGRAMMING. In a discipline where Fortran remains the dominant implementation language, the distinction is important. Most people would agree that even Fortran90 is not an OOL. However it is most definitely possible to implement OOD software architectures in Fortran (and other non-OOLs). It takes more care and discipline. It may take more time, because it implies a serious effort at design, which I don't think a lot of people pay much attention to. I definitely think the benefits are worth it. The NWChem parallel computational chemistry package (http://www.emsl.pnl.gov:2080/docs/nwchem/nwchem.html) was developed using OOD principles and implemented in a mixture of Fortran and C. It is on the order of 700,000 lines of code, and it works (contrary to the opinion someone else expressed about being unable to create a Fortran code so large). We made a carefully-considered decision to go this route rather than using C++ at the time the project began. I think we would make the same decision today, though that doesn't mean that it might not change down the road. I disagree with the person who proposed C++ is "the" langauge for future work because it is an OOL. There are a lot of other considerations that (should) factor into the decision of which language to use. However I think that ALL projects should consider object-oriented DESIGN regardless of implementation language. -- David E. Bernholdt | Email: bernhold@npac.syr.edu Northeast Parallel Architectures Center | Phone: +1 315 443 3857 111 College Place, Syracuse University | Fax: +1 315 443 1973 Syracuse, NY 13244-4100 | URL: http://www.npac.syr.edu From ccl@www.ccl.net Fri Jul 11 13:06:28 1997 Received: from bedrock.ccl.net for ccl@www.ccl.net by www.ccl.net (8.8.3/950822.1) id MAA08559; Fri, 11 Jul 1997 12:58:38 -0400 (EDT) Received: from nmho05u.rohmhaas.com for rahsjc@rohmhaas.com by bedrock.ccl.net (8.8.6/950822.1) id MAA10351; Fri, 11 Jul 1997 12:58:32 -0400 (EDT) Received: by nmho05u.rohmhaas.com; id NAA08568; Fri, 11 Jul 1997 13:13:13 -0400 (EDT) Received: from fermi.sh.rohmhaas.com(136.141.248.15) by nmho05u.rohmhaas.com via smap (V3.1.1) id xma008481; Fri, 11 Jul 97 13:12:56 -0400 Received: from localhost (rahsjc@localhost) by fermi.sh.rohmhaas.com (AIX4.2/UCB 8.7/8.7) with SMTP id MAA40070 for ; Fri, 11 Jul 1997 12:58:25 -0400 (EDT) X-Authentication-Warning: fermi.sh.rohmhaas.com: rahsjc owned process doing -bs Date: Fri, 11 Jul 1997 12:58:24 -0400 (EDT) From: "Subhas J. Chakravorty" X-Sender: rahsjc@fermi.sh.rohmhaas.com Reply-To: "Subhas J. Chakravorty" To: chemistry@ccl.net Subject: OOP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I think this C program was pretty humorous : while (1) { status = GetRadarInfo(); if (status = 1) LaunchMissiles(); } As soon as our Computer Science freinds decide which language and which computer is the best, we will buy that computer and learn and use that language. The problem is that they keep changing their minds on us from : Pascal, C, C++, Java, Python, Cobra oops, Corba, .... whereas FORTRAN plans to be Fortran, Fortran-2, Fortran-4, Fortran-66, Fortran-77,.... While they change their minds several times over the next century we can hold our breath and program in Fortran on our very old computers. Subhas J. Chakravorty, sjchakravorty@rohmhaas.com (215)-619-5481 Rohm and Haas Company Spring House, PA-19447 ************************************************************************** Disclaimer : Opinions in the above text are not of Rohm and Haas Company + ************************************************************************** From online@mactech.com Fri Jul 11 13:06:37 1997 Received: from neon.chem.ucla.edu for online@mactech.com by www.ccl.net (8.8.3/950822.1) id MAA08419; Fri, 11 Jul 1997 12:16:16 -0400 (EDT) Received: from [164.67.23.39] (ts40-10.wla.ts.ucla.edu [164.67.23.39]) by neon.chem.ucla.edu (8.8.0/8.8.0) with ESMTP id JAA19857 for ; Fri, 11 Jul 1997 09:17:17 -0700 (PDT) X-Sender: nick@neon.chem.ucla.edu Message-Id: In-Reply-To: <3.0.16.19970711093433.2f5f6850@mathtrek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 11 Jul 1997 09:22:18 -0800 To: chemistry@www.ccl.net From: "nick.c" Subject: Re: CCL:Object-oriented means for computational chemistry programming me: >>> But, in a completely undefensible statement of preference: today, new >>> code should be built in C/C++ (IMHO). I respect the fact that a huge ("undefensible"... I gotta stop posting articles after midnight... :-) Konrad: >>- C is no more OO than Fortran, but it doesn't have most of Fortran's >> most severe problems. But Fortran-90 is no worse than C, and in some >> respects better. W.R.: >i.e. Fortran can be OO too. I respectfully disagree. I'm no language theory expert, but my understanding is Fortran isn't OOP (for reasons I've already posted). For that matter neither is C (I believe Konrad said exactly this). The only reason I mentioned C in the first place, was by way of a disclaimer. Each job is unique, and sometimes C++ is not the best way to solve the problem at hand. Frequently I find a procedural solution is sufficient or preferable. For that matter, in many cases Fortran is probably the way to go on a specific project. Issues of what compilers are available for a platform, what programming languages your team is comfortable with, what legacy code you have available, who you're going to turn the code over to for maintenance, how fast your dev cycle is, what your budget looks like, does your customer have a preference, which way the wind is blowing, and others end up deciding how a project is going to get coded. That said, C++ offers tremendous benefits for managing large projects. C++ has unique and powerful resources for easily reusing and improving on old code-- even that piece of code that you had no idea you were going to ever need to reuse, and so would not have made modular if you were using C or Fortran. It's the industry standard: there's a C++ compiler for every platform, there are huge commercial libraries of classes, there is a wealth of books, formatting tools, class browsers, visual development tools, and other neat toys for the C++ set. Anyway, I'm not going to convince anyone here that C++ is the "next-great-thing" (I think Java might have that title by now anyway :-), but I would strongly encourage anyone starting a new project to at least weigh the benefits of the C++ language against the speed of recycling Fortran legacy. That code is going to wear out sometime, the only question is: do you want to rewrite it in C++ now, or two years from now when it's that much larger? >A quote by a distinguished scientist that I recall from a scientific >meeting about 10 years ago: > >"I don't know what type of programming language scientists will be using in >the next millenium, but it will be CALLED Fortran" Hm... Algol 60 was influenced by Fortran. C derived from BCPL, which came from CPL, which is Algol 60 based. C with Classes and C++ are OOP implementations of C. One could argue that C++ is just a new flavor of Fortran, and who knows--maybe when 2000 rolls around and we'll all be calling it Fortran00 (or maybe FortranOO :-) >No slight against Python, but we all remember the following historical >sequence: > >Algol vs Fortran (1960's) >PL1 vs Fortran (1970's) >Pascal vs Fortran (1980's) > >and now, it's > >C vs Fortran > >On the left-hand side, it has usually been CS (computer-science) types. On >the RH side, it has usually been scientists/engineers. Maybe. Still I think the distinction between "computer-science types" and "scientist/engineer" types is getting increasingly slight. I also think you're bumping into a whole new generation of scientists, many of whom learned C before they found out what a d orbital was. It's not a matter of learning a programming language to solve a problem in science (and thus being influenced by the language choice of your advisor or the legacy code lying around the lab, like in 60's and 70's). Many new college students already know how to program--and frankly most grade schools, high schools and JC's are pushing C/C++, not Fortran. Add to that the portion of your faculty who graduated in '85 and are hard core C++ fanatics (Pascal wasn't the only thing pushing on Fortran in the 80's :-). Explaining the value of Fortran to new college students these days is a lot like trying to explain why TVs didn't always have remote controls. I tip my hat to Fortran, I tipped my hat to Ali, but it was pretty clear when Ali stepped into the ring for the last time, that it was the last time. It looks like Fortran has run it's course as well. Dunno what the next great thing will be: Objective C, Java, C++. Dunno. But if you like, you *can* still call it Fortran :-) ____Nicholas C. DeMello, Ph.D.________________________________________ Online at MacTech Magazine, the Journal of Macintosh Programming http://www.MacTech.com/ _/ _/ _/ _/_/_/ _/ _/ Chemistry: Nick@chem.UCLA.edu _/_/ _/ _/ _/ _/ _/_/_/ MacTech: Online@MacTech.com _/ _/_/ _/ _/ _/ _/ http://www.chem.ucla.edu/~nick/ _/ _/ _/_/_/ _/ _/ From daizadeh@kappa.ucdavis.edu Fri Jul 11 13:06:44 1997 Received: from kappa.ucdavis.edu for daizadeh@kappa.ucdavis.edu by www.ccl.net (8.8.3/950822.1) id MAA08569; Fri, 11 Jul 1997 12:59:03 -0400 (EDT) Received: (from daizadeh@localhost) by kappa.ucdavis.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA01359 for chemistry@www.ccl.net; Fri, 11 Jul 1997 10:08:06 -0700 Resent-From: "Iraj Daizadeh" Resent-Message-Id: <9707111008.ZM1358@kappa.ucdavis.edu> Resent-Date: Fri, 11 Jul 1997 10:08:06 -0700 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) Resent-To: chemistry@www.ccl.net Received: (from daizadeh@localhost) by kappa.ucdavis.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA14978; Thu, 10 Jul 1997 10:12:28 -0700 Date: Thu, 10 Jul 1997 10:12:28 -0700 From: daizadeh@kappa.ucdavis.edu (Iraj Daizadeh) Message-Id: <199707101712.KAA14978@kappa.ucdavis.edu> To: daizadeh@kappa.ucdavis.edu, CHEMISTRY@www.ccl.net, chemistry-request@www.ccl.net Hello. Below is a summary of the responses I have received concerning visualization of 3-D data, in particular, visualization of a 3-d flow field. I have also included possible solutions to a recent problem sent to the CCL which corresponds to a related aspect of data analysis; viz., visualization of some sort of iso-surface (generalized contouring). I have attempted to make all listings below as anonymous as possible (plagarism). For the most part, all programs shown below were compiled (or precompiled binaries used) on a SGI (SiliconGraphics,Inc.) R10000 running IRIX 6.2 (except for the Fortner products). I should note that there were many others I have tested as well; a list of those follow: Plotmtv - Great, almost as easy as xmgr!!!!!! YetAnoextHuckMolorbprog - Nice for display of band structures, etc. graph3d - robot - scian - tecate - tipsy - uncert - The last six are vacuous since either I do not remember the programs efficacy or there were compilation problems. Any questions, comments or concerns, please do not hesitate to send me an email. Iraj. P.S. I should note that Vu is a beautiful program that has aided us in our projects tremendously (sp). Images created from this program can be found at http://www.cerca.umontreal.ca/vu/Welcome_eng.html. Make sure you check out the gallery at http://www.cerca.umontreal.ca/vu/gallery/Welcome_eng.html. The people behind Vu are very gratious and the program is free for those in acadamia. Iraj Daizadeh Department of Chemistry University of California Davis, CA 95616 email: daizadeh@indigo.ucdavis.edu Phone: 916.754.8695 -------------------------------------------------------------------------------- Below was the problem: Hello. Would anyone know an easy-to-learn program that allows for visualizing data from a file in 3-dimension Euclidean space something that looks like a fluid dynamics simulation? I started to write such a piece of code using Tcl/Tk but speed is of the essence (as always). Thanks in advance. Iraj Daizadeh Department of Chemistry University of California Davis, CA 95616 -------------------------------------------------------------------------------- #1) I use FAST, developed here, and available for free (I think). It does 3D scalar and vector fields on a wide variety of grids, including, of course, uniform cartesian. For some examples of what it can do for molecules, see http://science.nas.nasa.gov/~creon/papers/mgms96/ for availablitty of FAST, look at http://science.nas.nasa.gov/Software/FAST/ #2) Check out software at http://www.fortner.com/ I have never used their stuff, but it looks impressive (and they have been in business for a while). It is not free - but I think their main modules come as a package for less than $1,000. Fortner: http://www.fortner.com/docs/demos_all.html #3) Try pgplot. It's not available in netlib but it's excellent and free. See http://astro.caltech.edu/~tjp/pgplot/ It may not do *exactly* what you need but I think it'll come close, probably a lot closer than other free tools. #4) Sorry about the delay, but hours are not always so extensible as I might wish! Yes! VU can create pictures of 3-d fields using streamlines and/or vectors. Yes!! VU can displayed atoms and links between them using spheres and cylinders colored according to the usual standards. And Yes!!! you can put all of this on screen at the same time! We have created a couple of new images in the VU gallery representing small molecules in which a cutting plane is used to probe and visualize a scalar field. These are not big protein but rather small molecules, but the idea is the same. I invited you to go check again the VU home page at http://www.cerca.umontreal.ca/vu/gallery/ to check these new additions. VU is developped mainly for use in Computational Fluid Dynamics (CFD), but it also usefull for other application domains. It is being use extensively for chemistry applications here at Cerca and nearby universities, and also at the University of Hannover with AllChem (their web address is in VU HomePage). ** VU allows for 2-d and 3-d exploration of scalar fields as well as vector fields. Furthermore, VU can also display geometric entities such as curves and surfaces. ** Scalar fields can be probed/represented using either : - iso-surfaces in 3-d space, - iso-lines on arbitrary cutting planes - iso-lines on surfaces of constant coordinate from a structured grid. - graphs, i.e. continuously shaded images representing the values of a scalar field on cutting planes (or surfaces of constant coordinate from a structured grid). ** Vector fields can be probed/represented using either : - arrows (scalable) - streamlines in various number and location, all of which is specified interactivally. - dynamic particle tracing: non static images in which particle (represented as small spheres) are injected in various location to probe the vector fields. ** VU can extract information from these various fields and present them in a tabular form in a file or directly at the cursor location. ** VU uses `expressions' such as "sqrt(px*px+py*py+pz*pz)" to indicate color mapping, deformation or scaling factor for use in creating images (at least colorfull if not always meaningfull!). ** VU can also use transparency in any image, in order to be able able to `see' what is behind a cutting plane or an iso-surface. ** VU uses OpenGL and Motif (both fairly standard libraries) and works on UNIX workstations: IRIX, AIX, HP-UX, OSF1 and Linux. In a nutshell, VU can creates many and various images of 2-d and 3-d scalar and vector fields from a solution computed over a set of grid nodes. The input file for VU specifies the mesh used and the computed solution fields. You may see and read about some examples in the VU Web pages. However, if the fact that some of the web pages crucial for a full understanding of the capabilities of the program and of its input file might not be in english, you could forward a sample test case of your data to support_vu in order to establish its usuability in your case. Even if the documentation has not been yet completely translated and made avalailable on the Web, VU is nonetheless available in four languages: french, english, german and spanish. #5) IBM visualization data explorer/IRIS explorer will do. A while ago, i downloaded the comparison of these visualization softwares. Now I dont remember the URL. But u can find them in my homepage. http://144.16.73.100/~parthi/home.html and CLICK "visualization". u can see the comparison of four visualization softwares. #6) One possibility for almost all visualization tasks is to write a simple program to transform the data to a VRML file and then use a VRML browser to visualize it. For more information about VRML, look at the VRML repository (http://www.sdsc.edu/vrml/). For an example of code that generates VRML, look at the VRML module on my Python page (http://www.yi.com/home/HinsenKonrad/python.html). #7) I'm glad you enjoyed the site. I usually use Matlab or Mathematica to plot my vectors. Unfortunately, both of these programs are commercial so you must buy them. There may be shareware available on the internet to do the same thing. Happy hunting. #8) I don't know what your constraints are: systems, time, money, expertise ... but if I were in your position, I could knock out a visualization of "data from a file in 3-dimension Euclidean space something that looks like a fluid dynamics simulation" in 30-60 minutes using AVS. Have you any familiarity with it at all? There were other packages (IBM's Data Explorer and SGI's IRIS Explorer) which did much the same thing and were all the rage 3-4 years ago. #9) Vis5D will suit your needs if your data are sampled on a rectangular 3-D grid, and you have values for px, py and pz at each grid point. See Section 3.1 of the Vis5D README file for instructions about getting your data into Vis5D. I recommend map projection 0 (generic) and vertical coordinate system 0 (generic), since your data are not related to Earth coordinat (latitude and longitude). If you use the names 'U', 'V' and 'W' for px, py and pz then Vis5D will recognize these as the three components of a vector field. If you don't, then you can use the 'UVW VARS' widget to tell Vis5D which fields are vector components. In generic coordinates, vector components are in the units given for North, South, East, West, Top and Bottom bounds, per second. If you have a time sequence of data (i.e., a changing vector field), Vis5D will trace motion trajectories for you. You'll need to correctly assign dates and times to time steps to get realistic motions. If you only have one time step, you can still look at motion trajectories by just repeating the same data over a sequence of times. Good luck. #10) The purpose of this message is to give you a quick feeling for how the NCAR graphics package can be used to display graphs of your data from the Cray. The NCAR graphics package consists of libraries of C and Fortran callable subrou- tines for creating graphs and utilities for displaying them. #11) MSI's software developer's kit does exactly what you want. It includes an API set to visualize iso-surfaces, molecular structure, trajectories, normal modes, plots/graphs, etc. It also allows you in a few steps to put an interface together to any computational chemistry code. For general information about this toolkit visit: http://www.msi.com/support/sdk/ for specific information on plotting iso-surfaces visit: http://www.msi.com/support/sdk/users/examples/iso/README.html #12) Dear CCLers, although I'm pretty sure this question has been already posed (and I beg your pardon for posing it again), I have to ask about a 3D visualisation tool. I worked with SciAn, which is pretty good indeed, but the only existing version needs Z buffer and DGL. Looking on the net I found a software called vis5d, pretty good the same but tuned for metereological data and I found too time-expensive to adapt it to visualize orbitals, electronic density and so on. I'm using molden but I would like to find out soemthing more general (I'm trying to use ELF also, and this feature is not implemented in molden). The software I'm looking for should manage x,y,z,function_value in order to give isosurfaces of the function I'm trying to plot. Something not strictly platform-dependant would be very fine. Thank you for all the information you will provide. Iraj Daizadeh Department of Chemistry University of California Davis, CA 95616 email: daizadeh@indigo.ucdavis.edu Phone: 916.754.8695 Fax: 916.752.8995 From bernhold@tarkovsky.npac.syr.edu Fri Jul 11 14:37:08 1997 Received: from postoffice.npac.syr.edu for bernhold@tarkovsky.npac.syr.edu by www.ccl.net (8.8.3/950822.1) id NAA08661; Fri, 11 Jul 1997 13:14:23 -0400 (EDT) Received: from tarkovsky.npac.syr.edu (tarkovsky-007.npac.syr.edu [128.230.7.175]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with ESMTP id NAA00145; Fri, 11 Jul 1997 13:13:25 -0400 (EDT) Received: from localhost (bernhold@localhost) by tarkovsky.npac.syr.edu (8.8.5/8.7.1) with SMTP id NAA27510; Fri, 11 Jul 1997 13:13:25 -0400 (EDT) Message-Id: <199707111713.NAA27510@tarkovsky.npac.syr.edu> X-Authentication-Warning: tarkovsky.npac.syr.edu: bernhold@localhost didn't use HELO protocol To: chemistry@www.ccl.net cc: berriz@chasma.harvard.edu (Gabriel Berriz) Subject: Re: CCL:Object-oriented means for computational chemistry programming In-reply-to: <9707111440.AA24246@chasma.harvard.edu> Date: Fri, 11 Jul 1997 13:13:25 -0400 From: "David E. Bernholdt" It idea of mixed language programming is to use languages most appropriate for the task at hand, not just for speed, but for ease of implementation. Such decisions are usually fairly coarse-grained. For example, you might prefer to use C code to implement operations on a fairly complex data structure, while a computationally-intensive section might better be written in Fortran. If the code is well encapsulated, there should be little problem (conceptually) and no performance degredation from hooking up code written in multiple languages. Of course that's different from making a poor choice of programming language to implement a given component. It is true that interlanguage programming is not standardized (yet), but as a practical matter, on a given platform you can expect that most languages (from the same vendor at least) will follow a similar underlying structure and _will_ be able to interface. It is also true that relatively little documentation of these interfaces is available, but in most cases it is really fairly straightforward. Some things, like mixed Fortran77 and C, are now so common that there is a community of people out there who understand pretty well how to do this and even some packages/templates to help you do it in a platform-independent way. If you seek out such people, you can probably find them without too much trouble. I can't recall a case where I had to know more about the "processor-dependent nitty-gritty of numerical computation" to do mixed-language programming than I needed to do a good job of scientific programming in one language -- the interfaces are rarely so fine-grained as that. > Ultimately, most folks are more concerned with optimizing their time > use than the computer's :-) . In my opinion, this is the reason _to_ use mixed language programming. If I wanted to write a robust input parser for a large chemistry software package, I'm sure I could write it in Fortran, but it would take a lot of work. These days, there are tools to do this quite easily in C (lex, yacc, etc.). For many people, the time required to write the parser in C _and_ the time to sort out the interface to Fortran would be shorter than writing it in scratch from Fortran. And the C-Fortran interfacing skills learned during the exercise could easily be reused for other projects. -- David E. Bernholdt | Email: bernhold@npac.syr.edu Northeast Parallel Architectures Center | Phone: +1 315 443 3857 111 College Place, Syracuse University | Fax: +1 315 443 1973 Syracuse, NY 13244-4100 | URL: http://www.npac.syr.edu