Jonathan, it's easier than you think. No programming necessary....
On Fri, Jun 19, 2009 at 8:12 AM, Jonathan Gutow <[email protected]> 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 [email protected]
> 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
> [email protected]
> 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
------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
