Oh - and if all you want is the visualization of a G orbital, you can always
use something like
ISOSURFACE phase atomicOrbital 5 4 3
:)
On Sat, Jun 19, 2010 at 11:01 AM, SourceForge.net
<[email protected]>wrote:
> Feature Requests item #3017994, was opened at 2010-06-18 06:33
> Message generated for change (Comment added) made by hansonr
> You can respond by visiting:
>
> https://sourceforge.net/tracker/?func=detail&atid=379136&aid=3017994&group_id=23629
>
> Please note that this message will contain a full copy of the comment
> thread,
> including the initial issue submission, for this request,
> not just the latest update.
> Category: Interface Improvements
> Group: None
> Status: Open
> Priority: 5
> Private: No
> Submitted By: Rene Kanters (rkanters)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: higher than d orbitals in MOs
>
> Initial Comment:
> I was wondering whether it would be possible to have Jmol display MOs from
> quantum programs that are higher than the d orbitals.
> I understand that currently Jmol ignores those oribitals so as long as an
> orbital one looks at doesn't have much f (g, h, i) contributions it should
> not affect the visual part much, but I wonder whether that is something that
> could be added without too much trouble...
>
> ----------------------------------------------------------------------
>
> >Comment By: Bob Hanson (hansonr)
> Date: 2010-06-19 11:01
>
> Message:
> Sure - and I'm not suggesting what I implemented is the best solution,
> either. The basic idea is this (just modified yesterday). Originally the
> readers read the basis functions, saving either slater parameters or
> gaussian shells, depending upon the type of calculation. Then, in addition
> to that, the readers read the MO coefficients. You had managed to get the
> QChem reader to re-order its MO coefficients and basis shells, but that
> turned out to be way too complicated in terms of generalizing, so I decided
> instead to opt for just reading the file data as is, but also providing a
> set of int[] arrays that particularly for D and F shells indicates the
> mapping of MO coefficients to Jmol-expected (Gaussian) order.
>
> While each reader in principle could just provide this array, I saw that
> as being error-prone from a maintenance point of view.
>
>
> So instead I have the readers simply producing the list of D and F labels
> as found in the file and then also provide lists (DC_LIST, DS_LIST,
> FC_LIST, FS_LIST) that also list these in Jmol/Gaussian order. (Realize
> that when reading NBO output within Gaussian files, even there the orbitals
> need re-ordering.) That way I don't have to remember how the mapping works;
> I just have to make sure that any reader is making that list. Then
> BasisFunctionReader has a method getDFMap that creates the needed
> dfCoefMaps[][] array elements.
>
> For readers such as PSI, which don't provide any label information in
> their MO coefficient lists, I guess we would just have to find out what
> that ordering is and create the dfCoefMaps[][] arrays ourselves. But others
> are simpler -- just get the list of D and F orbitals found in the file and
> pass them on.
>
> The added complication that some files, such as Gaussian with NBO
> included, have two DIFFERENT orders. This was causing the problem with
> those Gaussian files you sent. I caught on to that yesterday, and now the
> way it works is that the dfCoefMaps[][] array is stored in the individual
> MO Hashtable, not the overall one for the model. This seems to work well.
>
> In addition, I had a mistake in how Jmol found the orbital label, and that
> was causing the first/last atom Sn problem that you observed.
>
> I'm pretty sure that is going to work now. All the NBO bond orbitals I
> looked at looked fine.
>
> Like you say, except for the very high virtual orbitals, I don't think
> having the G orbitals in there could make much of a difference in
> visualization -- at least that's what I'm told. The coefficients are just
> too small.
>
> Bob
>
>
> ----------------------------------------------------------------------
>
> Comment By: Rene Kanters (rkanters)
> Date: 2010-06-18 16:13
>
> Message:
> I just checked out the new version and am a bit surprised now that there
> are a bunch of NBOs that do not show anything, e.g., from tm_sna.tgz
> (filter "NBO" loaded) in the last model if you do MO 82 you won't see
> anything, all the way up to 99. At 100 it starts showing orbitals again. Is
> this because of the large g contributions? If so, maybe at least the mo
> label should show up with some kind of visual warning?
>
> ----------------------------------------------------------------------
>
> Comment By: Rene Kanters (rkanters)
> Date: 2010-06-18 16:00
>
> Message:
> I'll check it out.
> By the way, I wasn't disagreeing with you on your approach of not having
> each reader do the orbital reshuffling (which I may have started when I
> believe the qchem reader was the first one to have the orbital ordering
> different than gaussian). I was just having a hard time following all the
> intricacies of what you set up :-).
>
> ----------------------------------------------------------------------
>
> Comment By: Bob Hanson (hansonr)
> Date: 2010-06-18 14:20
>
> Message:
> ok, that's taken care of. There was an additional bug in the NBO reader
> that was not checking for orbital type when the atom number was < 10. While
> this is tricky, I still contend it's way easier than having each reader
> re-organize it's MO coefficients on the fly. Especially for large numbers
> of orbitals like this. Just have to be careful! Please check it out, Rene.
>
> ----------------------------------------------------------------------
>
> Comment By: Bob Hanson (hansonr)
> Date: 2010-06-18 12:35
>
> Message:
> ah, SO tricky... OK, so if you have two different sequences in the reader
> -- in this case Gaussian and NBO, then the sequence has to be tied to the
> orbital, not the collection of orbitals. Ah, so tricky!....
>
> ----------------------------------------------------------------------
>
> Comment By: Rene Kanters (rkanters)
> Date: 2010-06-18 11:13
>
> Message:
> I think I just lost my long message I was typing here.. Sigh... So here I
> go again.
> I just ran two calculations for Sn(CH3)4 (tm_sna.log with Sn as the first
> atom and tm_snb.log with Sn as the last atom) with NBO analysis.
> tm_sna.log has for NBO 82 a Rydberg state with 1.1239 AO contribution to
> the NBO. tm_snb.log has the same one as NBO 130 both for the last model in
> the structure). Loading these with filter "NBO" and doing a 'model last'
> then allows for
> tm_sna.log: MO 82 : see the Ry*(53)Sn, which looks like just an s orbital
> on a carbon, because no g-orbital contribution shown. That is misleading
> :-)
> tm_snb.log: MO 130 : shows no orbital whatsoever! Not even a label (I
> think that this is a bug?) MO 129 shows nicely the f-orbital, though.
>
>
> ----------------------------------------------------------------------
>
> Comment By: Bob Hanson (hansonr)
> Date: 2010-06-18 11:05
>
> Message:
> I think you just have to run the calculation with and without G orbitals to
> see what difference it makes. It's not a huge amount of code, but I don't
> know what the functions are, so it would definitely take some effort -- If
> you want to implement it, you certainly are welcome to. Good student
> project!
>
> ----------------------------------------------------------------------
>
> Comment By: Rene Kanters (rkanters)
> Date: 2010-06-18 08:11
>
> Message:
> Sorry about the mistake. I knew it does f's :-).
>
> Without being able to visualize the orbitals with and without the g (and
> higher) AO contributions it is hard to say whether the effect is large or
> not. You may be right indeed that it will not, but it would be nice to be
> able to see g orbitals even if they only contribute to virtual orbitals
> (like the Sn example I provided for the spherical/cartesian tests.
>
> I was wondering whether it may be (for you :-) and easy extension to what
> is already available. If it is then forget that I asked, if you would like
> to consider I think it would be a nice feature (that is why I posted it
> with feature requests).
>
> I'll talk to one of the students here who does some Sn calculations that
> involve g orbitals in the basis set to set up a calculation to get a g03
> ouput file for that.
>
>
> ----------------------------------------------------------------------
>
> Comment By: Bob Hanson (hansonr)
> Date: 2010-06-18 06:42
>
> Message:
> Jmol handles up through F orbitals. Hard to believe there's a significant
> visual contribution from G,H,I. Examples?
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
>
> https://sourceforge.net/tracker/?func=detail&atid=379136&aid=3017994&group_id=23629
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> 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
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
