I am relatively new to Dalton, so I excuse myself if I am missing something obvious. I am trying to set up a calculation in order to investigate the effect of various symmetries in the gparameters of a Mo+5 (d1) configuration. Ultimately, I want to embed this in a small SiC cluster to investigate pointdefects in this material, but as a first step I am using point charges around the central atom in the symmetry that I am interested in. In order to enforce tetrahedral symmetry and preserve the degeneracies I am using an MCSCF calculation with SUPSYM on. However, in the calculation of the gparameter it seems like the program does not go forward because one of the degenerate orbitals is fully occupied, whereas the second is not. Occupation analysis however does show two orbitals with occupancy 0.5. Both input and output files are attached. Thank you very much in advance for your help,
Carmem Maia
Problems obtaining gtensor in MCSCF calculation

 Posts: 1
 Joined: 21 Mar 2018, 10:40
 First name(s): Carmem
 Last name(s): Maia Gilardoni
 Affiliation: University of Groningen
 Country: Netherlands
Problems obtaining gtensor in MCSCF calculation
 Attachments

 MoPointChargeTetG.out
 (51.9 KiB) Downloaded 144 times

 MoPointChargeTetG.inp
 (1.25 KiB) Downloaded 137 times

 Posts: 576
 Joined: 15 Oct 2013, 05:37
 First name(s): Peter
 Middle name(s): Robert
 Last name(s): Taylor
 Affiliation: Tianjin University
 Country: China
Re: Problems obtaining gtensor in MCSCF calculation
First, if you would like to have exact tetrahedral symmetry, a better specification is to use D_{2} symmetry. In this case you would specify
Generators=2 XY XZ
to impose twofold rotational symmetry around (respectively) the z and the y axis. Twofold rotation around the x axis is then generated automatically from the product of these two generators (do not try to specify all three axes in input!)
Then you only need one point charge specified explicitly because the other three will be created for you, and as long as you specify that one charge as being at
a.aaaa a.aaaa a.aaaa
that is, that it has identical x, y, and z coordinates to whatever precision you input, your system will have T_{d} symmetry.
Now, I do not say this will solve your problem. Because although you say
"...the program does not go forward because one of the degenerate orbitals is fully occupied, whereas the second is not. Occupation analysis however does show two orbitals with occupancy 0.5"
I am not at all sure this means what you might think/hope. The natural orbital occupation numbers printed at convergence do not have this property. The population analysis does, but this may be a consequence of performing the analysis in supersymmetry. I am pretty confident when the response calculation starts it is using the occupation from the NOs, and this is then broken (higher) symmetry because those occupation numbers are 1 and 0, not 0.5 and 0.5.
One way of treating these sorts of degenerate symmetries is to average over several roots of the MCSCF problem, but Dalton does not have this facility (Incidentally, you are running a quite old version of the program, you will find it difficult to get support/advice long term with an old version, although I do not say that using an old version is causing the problem here.)
Short of removing the supsym directives and running in D_{2} and looking at what you get, I am at a loss to know what you can do, I'm afraid.
Best regards
Pete
Generators=2 XY XZ
to impose twofold rotational symmetry around (respectively) the z and the y axis. Twofold rotation around the x axis is then generated automatically from the product of these two generators (do not try to specify all three axes in input!)
Then you only need one point charge specified explicitly because the other three will be created for you, and as long as you specify that one charge as being at
a.aaaa a.aaaa a.aaaa
that is, that it has identical x, y, and z coordinates to whatever precision you input, your system will have T_{d} symmetry.
Now, I do not say this will solve your problem. Because although you say
"...the program does not go forward because one of the degenerate orbitals is fully occupied, whereas the second is not. Occupation analysis however does show two orbitals with occupancy 0.5"
I am not at all sure this means what you might think/hope. The natural orbital occupation numbers printed at convergence do not have this property. The population analysis does, but this may be a consequence of performing the analysis in supersymmetry. I am pretty confident when the response calculation starts it is using the occupation from the NOs, and this is then broken (higher) symmetry because those occupation numbers are 1 and 0, not 0.5 and 0.5.
One way of treating these sorts of degenerate symmetries is to average over several roots of the MCSCF problem, but Dalton does not have this facility (Incidentally, you are running a quite old version of the program, you will find it difficult to get support/advice long term with an old version, although I do not say that using an old version is causing the problem here.)
Short of removing the supsym directives and running in D_{2} and looking at what you get, I am at a loss to know what you can do, I'm afraid.
Best regards
Pete
Who is online
Users browsing this forum: Bing [Bot] and 12 guests