Dear Bob,

In order to try to understand what's going on when it
comes to render the MOs, I've called jmol with the option
"-logger.info=true".

I've used three different files

    - "columbus.molden": s, p, d basis functions
    - "b1t_spdfg.molden": s, p, d, f, g basis functions
    - "b2q_spdfgh.molden": s, p, d, f, g, h basis functions

They are available in the viz2.tar archive at

     http://www.filedropper.com/viz2

* For the file "columbus.molden", here are the relevant
information print by jmol.

    The Resolver thinks Molden
    [MOLDEN FORMAT]
    [ATOMS] AU
    [5D]
    Orbital type set to [5D]
    [7F]
    Orbital type set to [5D][7F]
    [GTO]
    84 slater shells read
    210 gaussian primitives read
    196 MO coefficients expected for orbital type [5D][7F]
    [MO]
    184 molecular orbitals read in model 1
    Time for openFile(columbus.molden): 115 ms
    reading 10 atoms

The numbers of shells and primitives read are correct. But
the number of MO coefficients expected for orbital type
[5D][7F] is not; this should be 184. There are indeed 46 S,
26 P and 12 D "shells", which corresponds for [5D][7F] orbital
type to 46*[1S]+26*[3P]+12x[5D] = 184 basis functions. The
number printed actually corresponds to [6D] orbital type.
I've rendered some random orbitals and the results were similar
to those obtained with gmolden-5.2.2.

* In "b1t_spdfg.molden", there are 69 S, 50 P, 30 D, 15 F and
2 G shells. For this file, jmol reports:

    [MOLDEN FORMAT]
    [GTO]
    166 slater shells read
    1189 gaussian primitives read
    579 MO coefficients expected for orbital type
    [TITLE]
    [ATOMS] AU
    [5D7F]
    Orbital type set to [5D7F]
    [9G]
    Unsupported orbital type ignored: [9G]
    Orbital type set to [5D7F][9G]
    [MO]
    492 molecular orbitals read in model 1
    [END OF MOLDEN OUTPUT FROM DALTON2013]
    Time for openFile(b1t_spdfg.molden): 140 ms

The numbers of shells and primitives are correct, not the
number of expected MO coefficients. For [5D7F][9G] orbital
type, we should have 492 coefficients. The reported number
of MO coefficients is for [6D10F][15G] orbital type. When
plotting MOs from this file, the following message

   Unsupported basis type for atomno=1: 9G

is correctly printed out, and the calculations went fine: I
mean the plotted MOs look ok.



* In "b2q_spdfgh.molden", there are 70 S, 51 P, 31 D, 16 F
and3 G and 2 H shells. I also inserted a line with [11H].
For this file, jmol reports:

    [MOLDEN FORMAT]
    [GTO]
    173 slater shells read
    1314 gaussian primitives read
    656 MO coefficients expected for orbital type
    [TITLE]
    [ATOMS] AU
    [5D7F]
    Orbital type set to [5D7F]
    [9G]
    Unsupported orbital type ignored: [9G]
    Orbital type set to [5D7F][9G]
    [11H]
    Unsupported orbital type ignored: [11H]
    Orbital type set to [5D7F][9G][11H]
    [MO]
    539 molecular orbitals read in model 1
    [END OF MOLDEN OUTPUT FROM DALTON2013]
    Time for openFile(b2q_spdfgh.molden): 130 ms

The reported number of MO coefficients should be 539 for
[5D7F][9G][11H] orbital type. When trying to plot a MO,
there is an out-of-bound exception and the calculations
terminate.

    Unsupported basis type for atomno=1: 9G
    java.lang.ArrayIndexOutOfBoundsException: 10
    Could not create isosurface

Please note that there is no mention of the unsupported
11H basis type, which actually are located on atomno=1.


So I guess, that the number of expected MOs coefficients
is automatically calculated for Cartesian basis functions
when reading the basis set, and that it is not updated or
printed after having determined the definitive orbital type.
It also seems that the workaround used for handling the
unsupported G basis functions is not operative for H and
possibly I basis functions. I cannot find where the
unsupported functions types are labeled as such. Could you
please point me to the corresponding portion of the code?

Thanks a lot for having gone through this lengthy mail :-)

Best,
Max


P.S. While going through the sources, I noticed that in the
method J.adapter.readers.quantum.fixOrbitalType(), nothing
is done for I basis functions. From my understanding of
J.adapter.readers-quantum.BasisFunctionReader.fixSlaterTypes(),
and of the data at the end of the file "J/quantum/QS.js",
when [5D] is present, you make jmol use D, F, G and H spherical
functions; if [10F] is present, cartesian F, G and H functions
are used; and finally if [15G] is present, cartesian G and H
functions are used. Nothing seems to be done for I functions.

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Reply via email to