Menu
▾
▴
Re: [Jmol-developers] Still having a little trouble figuring out the MO loading...
|
From: Robert H. <ha...@st...> - 2009-06-21 18:45:50
|
OK, a few final touches are in now.
On Sun, Jun 21, 2009 at 1:12 PM, Robert Hanson <ha...@st...> wrote:
> 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
>
--
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
|