Feature Requests item #3017994, was opened at 2010-06-18 06:33 Message generated for change (Settings changed) 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: Closed 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 ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Jmol-developers mailing list Jmol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jmol-developers
