From: Robert H. <ha...@st...> - 2009-06-21 18:12:31
|
OK, check out what I just checked in. Should do the trick, at least for now. You still can't load just one model, though. On Sun, Jun 21, 2009 at 12:41 PM, Robert Hanson <ha...@st...> wrote: > Jonathan, it's easier than you think. No programming necessary.... > > On Fri, Jun 19, 2009 at 8:12 AM, Jonathan Gutow <gu...@uw...> wrote: > >> Bob and René, >> The issue is that orbitals are stored in the orbitals vector which >> is associated with the AtomSetCollection rather than with each >> AtomSet. Thus when there is a different set of MOs associated with >> different AtomSets they are simply appended in order to the orbitals >> for the AtomSetCollection. This means that for any given AtomSet >> Jmol gives you the list of all orbitals. Glancing through the code >> for readers other than GAMESS, I think the problem is the same. >> However, I don't have any example data sets from other programs that >> have orbitals associated with more than one of the models. >> My preference would be to have an orbitals vector associated with >> each AtomSet. >> > > Jonathan, that's not quite correct. If there are multiple files, then the > MOs are handled appropriately, being stored with a specific model (the > "atomSet"), not the modelCollection (the "atomSetCollection"). There is no > "file collection" idea in Jmol. > > For example, if you do this: > > load files "c6h6.smol" "ethane.smol" > > then c6h6.smol will have its MOs, and ethane.smol will have its MOs. > > frame 1.1; mo 3 > frame 2.1; mo 10 > > etc. > > Now, where your problem is coming in is that you are loading multiple > models within a file and then having a problem associating MOs with a > specific model within that set. This should not be a big deal. Note that the > assignment is made to a specific model (an "atomSet") not the full > collection (the "atomSetCollection"): > > atomSetCollection.setAtomSetAuxiliaryInfo("moData", moData); > > Had this been > > atomSetCollection.setAtomSetCollectionAuxiliaryInfo("moData", moData); > > only then the MOs would have been assigned to the entire set of models. > > But I think you are right that there is a bug there. We are not nulling out > the MOs when a new model is encountered. > > > >> >> I have put a number of new example files in the gamess directory in >> the Jmol-datafiles directory in SVN. A small example file that shows >> the problem is HCl_geom_DZV+Diff+CCSD(T).log. Actually, this problem >> shows up in all standard GAMESS geometry optimization runs as by >> default the initial guess orbitals and the optimized orbitals for the >> final geometry are included in the .log file. In this file the >> initial guess orbitals associated with the first geometry are 1 - 56 >> as loaded by Jmol. The optimized orbitals that go with the final >> geometry are numbered 57 +, the way Jmol presently loads them. In >> this particular file the initial guess orbitals are listed after the >> heading "EIGENVECTORS" and the final geometry MOs are after the >> heading "MOLECULAR ORBITALS". >> > > All you need to do is add a filter: > > load "hcl.log" filter "molecular orbitals" > > gets you only those final MOs. They will be associated with the last model: > > model last;mo 8 > > for example. > > I do see that there are a few bugs there. For example, the following should > work but doesn't: > > load "hcl.log" 11 filter "molecular orbitals" > > > That should just load your optimized model and its molecular orbitals. And > I agree that in general the MOs should not be all in the same pile. > > Let me take a look there... > > > Bob > > > > >> Let me know what you think and thanks for the suggestions and help. >> >> Jonathan >> On Jun 18, 2009, at 4:19 PM, Robert Hanson wrote: >> >> > Jonathan, can you send me the GAMESS file and explain exactly what >> > it should be doing? >> > >> > Bob >> > >> >> Dr. Jonathan H. Gutow >> Chemistry Department gu...@uw... >> UW-Oshkosh Office:920-424-1326 >> 800 Algoma Boulevard FAX:920-424-2042 >> Oshkosh, WI 54901 >> http://www.uwosh.edu/faculty_staff/gutow/ >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Crystal Reports - New Free Runtime and 30 Day Trial >> Check out the new simplified licensing option that enables unlimited >> royalty-free distribution of the report engine for externally facing >> server and web deployment. >> http://p.sf.net/sfu/businessobjects >> _______________________________________________ >> Jmol-developers mailing list >> Jmo...@li... >> https://lists.sourceforge.net/lists/listinfo/jmol-developers >> > > > > -- > Robert M. Hanson > Professor of Chemistry > St. Olaf College > 1520 St. Olaf Ave. > Northfield, MN 55057 > http://www.stolaf.edu/people/hansonr > phone: 507-786-3107 > > > 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 > -- Robert M. Hanson Professor of Chemistry St. Olaf College 1520 St. Olaf Ave. Northfield, MN 55057 http://www.stolaf.edu/people/hansonr phone: 507-786-3107 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 |