> Hi Miguel, > > I think the check-in worked (at least I got several messages from > sourceforge about the commits). I am currently doing all this from > within BBEdit, which is pretty neat.
Very good. It is important that you be comfortable with your tools. Glad that you figured out how to get CVS working from within bbedit. > In any case, until I hear differently, I will assume that the > GaussianReader and NWChemReader are OK. If there are still some issues > regarding these that you posed and I did not address, let me know. OK > I think we still have the question about associating additional > information to a particular model or set of models (where I now mean > with model a set of atoms with the same atom.modelNumber. Correct. > At the moment > I am not aware of how one could do that, or even whether the provision > for that exists. There is no mechanism currently in place. > When thinking down the line for a more complete CML > specification support, I think it may be necessary to have a flexible > amount of extra information be attached to each model, or set of models > (e.g., all 12 vibration models that came in with the interpretation of > frequency data). I wonder whether this could be done with something > like a Hashtable with each model. Yes. The way for us to handle this to let each model have a PropertyList. This will let us associate arbitrary text 'keys' with text 'values' That is what we should start thinking about down the road. First, lets start off with something simple. We'll think of it as a prototype. This will help you learn a little more about the mechanics of programming in Jmol without getting overwhelmed. As a first step, lets simply associate a text description with each model. We can then present this to the user in a menu/combo box. Later we can extend it. > In order to have the hierarchy that CML may need, which also could be > useful for the combining multiple models within a particular set, I > was wondering whether one could use the javax.swing.tree package and > have the Model class extend the DefaultMutableTreeNode. For instance > something like this: > + molecule 1 > + optimization > + step 0 > * meta information > + xyz model > + zmat model > + gradients model > + vibration > + vibration 1 > * meta information > + vibration model > + vibration 2 > * meta information > + vibration model > + step 2 > * meta information > + xyz model > + zmat model > + step 1 > * meta information > + xyz model > + zmat model > + molecule 2 > etc Yes. And the swing tree model support will be good for us when working in the Jmol application. > Using that kind of hierarchy, with the appropriate coding in the viewer > part could allow a user to more easily pick, for instance, the 3th > vibration in the final optimization step for molecule 3. > The question then becomes on how to decide in the output file that a > new molecule is encountered, but I guess that it could be to map the > whole file as a single molecule and make each task's output as a > separate node, with subnodes for each of the structures associated, > resulting in a hierarchy that really is only 2 levels (below the top). > > + inputfile > + optimization > several steps like above > + vibration > several virbational modes like above > + optimization > etc This is good stuff for you to think about. > This approach would do away with Atom.modelNumber, since the > association of the atoms with a particular model is explicit from the > fact that they are in the same model object. Hmmm ... I'm not so sure. The model number will continue to exist ... other people working with different file types need to have support for model numbers. And it is an easy/efficient thing for the core viewer code to use. In addition, the model number is often required for scripting. But, what we are going to do is provide some UI which will allow users to pick models from the text descriptions ... but the text description will still map to a model number for the underlying engine. Miguel ----- Open Source Molecular Visualization www.jmol.org [EMAIL PROTECTED] ----- ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
