Andrew Turner wrote: >Hi > >Bob, thanks for the pointers they are really useful. > >I work at the University of Edinburgh trying to get experimental >research chemists to use computational chemistry tools. Not just as >collaboration, but teaching them to use then so it becomes second nature >in their research (like getting an NMR spectrum or running MS analysis). >Part of this consists of finding tools that are easy for them to use (on >whatever platform) for building input, submitting calculations and >analysing output. > >My ideas for contributions reflect my user base and are mainly on the >application side I guess. Things I would like to add: > >* A save molecule dialog that can write the system in a variety of >formats. Some coordinate types but also input for common codes that we >use (Gaussian, MOLPRO, Castep, CPMD). There may be a role for Babel >here. It might also need different dialogs to deal with different codes. > > Very nice idea. It would be based on the current WRITE command, which allows saving of atoms in XYZ, MOL, or PDB formats. It has the nice feature that it can extract out just those atoms selected.
My programming strategy has been to make every action of a dialog reducible to a script command. That way there is basically nothing that can't be done by scripting. So if we, say, develop a new format for output, what we would also do is create a WRITE command option for it and run it through that command. It takes a bit of coordination to get that all to work, but I think it's worth it to have everything going through the script processor (Eval/Compiler). This also makes possible automated batch processing, because scripts can be run from the Jmol application command line in batch mode. >* A dialog for controlling the plotting of surfaces from cube files. >Pretty simple initially but moving on to handling mapping and slices. > > That could be very nice. It would generate ISOSURFACE commands consistent with the user's settings. It should not depend on the data being from a CUBE file -- Jmol basically constructs cube-like "volumetric" data from all sorts of sources now. These include molecular orbital coefficient/basis data in the input file, partial charge data either from the input file or supplied separately, molecular surface calculation, and even user-supplied f(x,y) data. One of the very nice capabilities of Jmol is to then take that surface and create a JVXL file -- a very compact encapsulation of one or more specific surfaces selected by the user based on the much larger CUBE data set. So that would be nice to have as part of that dialog. >* An interface to Globus Toolkit for submitting jobs using UK e-Science >certificates. We are developing a Gaussian submission portlet and would >like to use the Jmol applet within it for viewing input and output, it >would be nice if we could integrate the submission into the Jmol >application. > > Could this be web-based? So that it is the applet the user is using? Or do you see it as being the application? This sounds much like WebMO. Have you taken a look at that? It's very popular around here. >I have had a quick look through the feature enhancements on the wiki and >cannot see these things. But please correct me if people are already >working on them. > > > The dialog idea is terrific. So that's probably the application we are talking about there. Because the applet more generally just uses HTML/JS buttons and such. That way the user interface is entirely flexible and customizable. The truth is, the Jmol application has not had the sort of scrutiny or general use as the applet. BUT it is precisely this sort of development that will make the application more useful. So I certainly support everything you have suggested there. Basically, my routine is to do all development on the application, being careful to consider what aspects are application-only (in org.openscience.jmol.app) and what is common to both applet and application (in org.jmol). (There's also some code that is applet-only; it goes into org.jmol.applet, and it is delivered with Jmol.jar even though not accessible through it.) Jmol is also integrated into all sorts of other programs, so we provide the JmolViewer interface as a simple way of getting core information out of or into Viewer. Viewer itself is also public, so one does not HAVE to use JmolViewer, but I'm sworn to not adjust the signatures of those methods in JmolViewer, while the Viewer signatures are fair game for me to adjust as needed for the internal operation of the Viewer. Let me know when you want to get started, and I will create a branch for you and enable your access as a developer if you don't have it already. Sounds wonderful. Bob >Regards > >Andy > > > >Bob Hanson wrote: > > >>Andy, welcome aboard! Tell us about yourself. >> >>I'm probably the only one right now who really knows everything that is >>in the code and how it works. So ask me anything. One thing you can look >>at is the viewer.gif file in >>http://jmol.svn.sourceforge.net/viewvc/jmol/trunk/Jmol/src/org/jmol/_documents/ >> >>It's a bit out of date, but it shows the basics of how the different >>classes are related. Primarily, Viewer is the key player here, and all >>the "managers" work with it. >> >>In answer to your specific question, the script goes into a queue and is >>processed within the ScriptManager class. When its turn comes up, it is >>sent to Viewer.evalStringWaitStatus, where it is then sent to Eval for >>processing. Eval passes the script to Compiler for compiling and some >>syntax error checking, after which it takes the form of a set of >>commands, each of which consists of a Token[] array. There are some >>replacements that go on late in the game, and the result is a Token >>array called "statement". This is the currently processing command in >>token form. The main loop in Eval is the method instructionDispatchLoop. >> >>If you are interested in contributing, that's great. We can set up a >>branch for you, and you can play all you want, letting us know if you >>are having success or problems. If something looks good, we'll merge it >>into 11.5, which is the trunk for current development. I recommend not >>doing major code refactoring or modifications without first checking >>with this list to see if it would make merging too difficult. >> >>What sort of ideas are you thinking of in terms of contributions? >> >>Bob >> >> >>Andrew Turner wrote: >> >> >> >>>Hi, >>> >>>I am new to developing Jmol and have a few ideas as to what I could >>>contribute. I have been to the Jmol wiki and checked out the Jmol source >>>into eclipse. >>> >>>My question is this, is there anywhere that provides a overview of how >>>the Jmol package fits together. I have had a look through the source for >>>a few hours and feel I am no closer to understanding which bits do what. >>> >>>For example, if I type 'write COORD "file.xyz"' in the scripting dialog >>>of the application, where does the final file writing actually get done. >>>I can trace the command to Viewer.evalStringQuiet but start to get lost >>>pretty soon after that. >>> >>>If anyone has anything useful I would be glad to see it. >>> >>>Regards >>> >>>Andy >>> >>> >>> >>> >> >> > > > -- Robert M. Hanson Professor of Chemistry St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
