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 <[email protected]> wrote:
> 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
>
--
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
