Menu
▾
▴
cclib-users
|
From: Martin R. <mar...@gm...> - 2011-11-04 21:28:20
|
Dear List,
I'm running a trial Löwdin population analysis (LPA) on SF6, from a
B3LYP/cc-pVTZ calculation. Something is awry, the total number of
electrons gets overestimated by 0.3 (70.3), and there is a "complex
warning" when running the LPA.
LPA is supposed to be rotationally invariant if one use "pure" spherical
harmonics in the basis set, e.g. 5 d functions instead of 6. (which cc-pVTZ
does). Anyone have any clue to this behavior?
Best regards,
Martin
Gaussian Input: ---------
# opt freq b3lyp/cc-pvtz pop=(nboread,full) iop(3/33=1,3/36=-1)
Title Card Required
0 1
F 0.00000000 0.00000000 1.57972200
F 0.00000000 1.57972200 0.00000000
F 0.00000000 0.00000000 -1.57972200
F 0.00000000 -1.57972200 0.00000000
F 1.57972200 0.00000000 0.00000000
F -1.57972200 0.00000000 0.00000000
S 0.00000000 0.00000000 0.00000000
Python script: --------
from numpy import *
from cclib.parser import ccopen
from cclib.method import LPA
parser = ccopen("test.log")
data = parser.parse()
method = LPA(data)
method.calculate()
savetxt("LPA-big.csv",transpose(2*method.aoresults[0][:data.homos[0]+1]))
Script output: --------
...
[Gaussian test.log INFO] Creating attribute coreelectrons[]
[LPA <cclib.parser.data.ccData object at 0x1015ba150> INFO] Creating
attribute aoresults: [array[2]]
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/cclib/method/lpa.py:99:
ComplexWarning: Casting complex values to real discards the imaginary part
self.aoresults[spin][i] = numpy.multiply(temp1, temp2).astype("d")
[LPA <cclib.parser.data.ccData object at 0x1015ba150> INFO] Saving
partitioned results in fragresults: [array[2]]
[LPA <cclib.parser.data.ccData object at 0x1015ba150> INFO] Creating
fragcharges: array[1]
|
|
From: Karol M. L. <kar...@gm...> - 2011-11-05 08:35:16
|
Hi Martin,
Can you provide the output file for that Gaussian job?
Best,
Karol
On Nov 04 2011, Martin Rahm wrote:
> Dear List,
>
> I'm running a trial Löwdin population analysis (LPA) on SF6, from a
> B3LYP/cc-pVTZ calculation. Something is awry, the total number of
> electrons gets overestimated by 0.3 (70.3), and there is a "complex
> warning" when running the LPA.
>
> LPA is supposed to be rotationally invariant if one use "pure" spherical
> harmonics in the basis set, e.g. 5 d functions instead of 6. (which cc-pVTZ
> does). Anyone have any clue to this behavior?
>
> Best regards,
> Martin
>
> Gaussian Input: ---------
> # opt freq b3lyp/cc-pvtz pop=(nboread,full) iop(3/33=1,3/36=-1)
>
> Title Card Required
>
> 0 1
> F 0.00000000 0.00000000 1.57972200
> F 0.00000000 1.57972200 0.00000000
> F 0.00000000 0.00000000 -1.57972200
> F 0.00000000 -1.57972200 0.00000000
> F 1.57972200 0.00000000 0.00000000
> F -1.57972200 0.00000000 0.00000000
> S 0.00000000 0.00000000 0.00000000
>
> Python script: --------
> from numpy import *
> from cclib.parser import ccopen
> from cclib.method import LPA
> parser = ccopen("test.log")
> data = parser.parse()
> method = LPA(data)
> method.calculate()
> savetxt("LPA-big.csv",transpose(2*method.aoresults[0][:data.homos[0]+1]))
>
> Script output: --------
> ...
> [Gaussian test.log INFO] Creating attribute coreelectrons[]
> [LPA <cclib.parser.data.ccData object at 0x1015ba150> INFO] Creating
> attribute aoresults: [array[2]]
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/cclib/method/lpa.py:99:
> ComplexWarning: Casting complex values to real discards the imaginary part
> self.aoresults[spin][i] = numpy.multiply(temp1, temp2).astype("d")
> [LPA <cclib.parser.data.ccData object at 0x1015ba150> INFO] Saving
> partitioned results in fragresults: [array[2]]
> [LPA <cclib.parser.data.ccData object at 0x1015ba150> INFO] Creating
> fragcharges: array[1]
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> cclib-users mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-users
--
written by Karol Langner
Sat Nov 5 09:34:29 CET 2011
|
|
From: Adam T. <ate...@gm...> - 2011-11-15 18:19:17
|
Hi Martin and others,
Sorry for the delayed response....
The complex warning suggests there's a complex value being discarded
that may be important. Does anyone know if we should be taking the
norm instead of simply discarding the imaginary part?
Also, does it matter that this is an Opt Freq calc? Does Gaussian
print the one-electron overlap matrix (aooverlaps) at the final
geometry? (I usually don't combine Opt and Freq calcs, so I don't
know, but the file looks like the final overlap matrix isn't at the
converged geometry.) If not, perhaps the problem is from using the
overlap matrix at the first structure and the orbital coefficients at
the final structure.
Take care,
Adam
On Sat, Nov 5, 2011 at 1:20 PM, Martin Rahm <mar...@gm...> wrote:
> Hi Karol,
> I realized that I had used cartesian coordinates in the original input file.
> When I used a z-matrix instead (and defined S as atom 0) the LPA warning was
> still the same, but the total number of electrons turned out to be 70.22
> (instead of 70.3).
> I should also mention that the LPA-charge of all F ligands are slightly
> different, even though they are symmetrically identical.
> Best,
> Martin
> On Sat, Nov 5, 2011 at 1:34 AM, Karol M. Langner <kar...@gm...>
> wrote:
>>
>> Hi Martin,
>>
>> Can you provide the output file for that Gaussian job?
>>
>> Best,
>> Karol
>>
>> On Nov 04 2011, Martin Rahm wrote:
>> > Dear List,
>> >
>> > I'm running a trial Löwdin population analysis (LPA) on SF6, from a
>> > B3LYP/cc-pVTZ calculation. Something is awry, the total number of
>> > electrons gets overestimated by 0.3 (70.3), and there is a "complex
>> > warning" when running the LPA.
>> >
>> > LPA is supposed to be rotationally invariant if one use "pure" spherical
>> > harmonics in the basis set, e.g. 5 d functions instead of 6. (which
>> > cc-pVTZ
>> > does). Anyone have any clue to this behavior?
>> >
>> > Best regards,
>> > Martin
>> >
>> > Gaussian Input: ---------
>> > # opt freq b3lyp/cc-pvtz pop=(nboread,full) iop(3/33=1,3/36=-1)
>> >
>> > Title Card Required
>> >
>> > 0 1
>> > F 0.00000000 0.00000000 1.57972200
>> > F 0.00000000 1.57972200 0.00000000
>> > F 0.00000000 0.00000000 -1.57972200
>> > F 0.00000000 -1.57972200 0.00000000
>> > F 1.57972200 0.00000000 0.00000000
>> > F -1.57972200 0.00000000 0.00000000
>> > S 0.00000000 0.00000000 0.00000000
>> >
>> > Python script: --------
>> > from numpy import *
>> > from cclib.parser import ccopen
>> > from cclib.method import LPA
>> > parser = ccopen("test.log")
>> > data = parser.parse()
>> > method = LPA(data)
>> > method.calculate()
>> >
>> > savetxt("LPA-big.csv",transpose(2*method.aoresults[0][:data.homos[0]+1]))
>> >
>> > Script output: --------
>> > ...
>> > [Gaussian test.log INFO] Creating attribute coreelectrons[]
>> > [LPA <cclib.parser.data.ccData object at 0x1015ba150> INFO] Creating
>> > attribute aoresults: [array[2]]
>> >
>> > /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/cclib/method/lpa.py:99:
>> > ComplexWarning: Casting complex values to real discards the imaginary
>> > part
>> > self.aoresults[spin][i] = numpy.multiply(temp1, temp2).astype("d")
>> > [LPA <cclib.parser.data.ccData object at 0x1015ba150> INFO] Saving
>> > partitioned results in fragresults: [array[2]]
>> > [LPA <cclib.parser.data.ccData object at 0x1015ba150> INFO] Creating
>> > fragcharges: array[1]
>>
>> >
>> > ------------------------------------------------------------------------------
>> > RSA(R) Conference 2012
>> > Save $700 by Nov 18
>> > Register now
>> > http://p.sf.net/sfu/rsa-sfdev2dev1
>>
>> > _______________________________________________
>> > cclib-users mailing list
>> > ccl...@li...
>> > https://lists.sourceforge.net/lists/listinfo/cclib-users
>>
>>
>> --
>> written by Karol Langner
>> Sat Nov 5 09:34:29 CET 2011
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> cclib-users mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-users
>
>
|
|
From: Karol M. L. <kar...@gm...> - 2012-01-28 00:51:36
|
Hi Martin,
I've come around to this issue. First of all, in this case I don't get
the complex number error your report, and my fragcharges sum up nicely.
That is a good thing, because it means the cause is perhaps external
to cclib.
I'm using Python 2.6 here, but I assume that would not be a problem.
My NumPy version is 1.4.1 and I'm using the latest cclib revision from svn.
What are your version?
- Karol
On Jan 12 2012, Martin Rahm wrote:
> Hello again,
>
> I've come across another case of the "complex number" error. This time in a
> very small diatomic.
>
> Running LPA on a M062X/cc-pwCV5Z wave function of ClF, and gets this error:
>
> [LPA <cclib.parser.data.ccData object at 0x1015ba1d0> INFO] Creating
> attribute aoresults: [array[2]]
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/cclib/method/lpa.py:99:
> ComplexWarning: Casting complex values to real discards the imaginary part
> self.aoresults[spin][i] = numpy.multiply(temp1, temp2).astype("d")
>
> This is quite cumbersome, since there is really no way of breaking symmetry
> of a linear molecule (which solved the problem for larger molecules)!
>
> I've attached my log file, and also my script just in case.
>
> I hope you have a quick fix :)
>
> Best regards,
> Martin
> Archive: /tmp/ClF-M06-cc-pwCV5Z.log.zip
> Length Date Time Name
> --------- ---------- ----- ----
> 8430472 2012-01-11 09:10 ClF-M06-cc-pwCV5Z.log
> --------- -------
> 8430472 1 file
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Mar 27 - Feb 2
> Save $400 by Jan. 27
> Register now!
> http://p.sf.net/sfu/rsa-sfdev2dev2
> _______________________________________________
> cclib-users mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-users
--
written by Karol Langner
Sat Jan 28 01:46:35 CET 2012
|
|
From: Martin R. <mar...@gm...> - 2011-11-15 19:50:17
|
Hi Adam, and everyone,
I just figured out a way around the problem. First, the same thing happens
for single points, and it remains if one runs with "nosymm", or if the
nuclear coordinate input is switched between cartesian/z-mat. However,
these latter changes do seem to affect the total number of electrons and
the orbital populations slightly different.
The solution I found was to perturb the Oh symmetry very slightly (into
C3v), then the electron count becomes 70.000, and all ligands are treated
equally. The same goes for Td systems, which have to be disturbed into D2d.
In other words it seems like the code has problems with "spherically"
symmetric wave functions.
Best,
Martin
On Tue, Nov 15, 2011 at 10:19 AM, Adam Tenderholt <ate...@gm...>wrote:
> Hi Martin and others,
>
> Sorry for the delayed response....
>
> The complex warning suggests there's a complex value being discarded
> that may be important. Does anyone know if we should be taking the
> norm instead of simply discarding the imaginary part?
>
> Also, does it matter that this is an Opt Freq calc? Does Gaussian
> print the one-electron overlap matrix (aooverlaps) at the final
> geometry? (I usually don't combine Opt and Freq calcs, so I don't
> know, but the file looks like the final overlap matrix isn't at the
> converged geometry.) If not, perhaps the problem is from using the
> overlap matrix at the first structure and the orbital coefficients at
> the final structure.
>
> Take care,
>
> Adam
>
> On Sat, Nov 5, 2011 at 1:20 PM, Martin Rahm <mar...@gm...> wrote:
> > Hi Karol,
> > I realized that I had used cartesian coordinates in the original input
> file.
> > When I used a z-matrix instead (and defined S as atom 0) the LPA warning
> was
> > still the same, but the total number of electrons turned out to be 70.22
> > (instead of 70.3).
> > I should also mention that the LPA-charge of all F ligands are slightly
> > different, even though they are symmetrically identical.
> > Best,
> > Martin
> > On Sat, Nov 5, 2011 at 1:34 AM, Karol M. Langner <
> kar...@gm...>
> > wrote:
> >>
> >> Hi Martin,
> >>
> >> Can you provide the output file for that Gaussian job?
> >>
> >> Best,
> >> Karol
> >>
> >> On Nov 04 2011, Martin Rahm wrote:
> >> > Dear List,
> >> >
> >> > I'm running a trial Löwdin population analysis (LPA) on SF6, from a
> >> > B3LYP/cc-pVTZ calculation. Something is awry, the total number of
> >> > electrons gets overestimated by 0.3 (70.3), and there is a "complex
> >> > warning" when running the LPA.
> >> >
> >> > LPA is supposed to be rotationally invariant if one use "pure"
> spherical
> >> > harmonics in the basis set, e.g. 5 d functions instead of 6. (which
> >> > cc-pVTZ
> >> > does). Anyone have any clue to this behavior?
> >> >
> >> > Best regards,
> >> > Martin
> >> >
> >> > Gaussian Input: ---------
> >> > # opt freq b3lyp/cc-pvtz pop=(nboread,full) iop(3/33=1,3/36=-1)
> >> >
> >> > Title Card Required
> >> >
> >> > 0 1
> >> > F 0.00000000 0.00000000 1.57972200
> >> > F 0.00000000 1.57972200 0.00000000
> >> > F 0.00000000 0.00000000 -1.57972200
> >> > F 0.00000000 -1.57972200 0.00000000
> >> > F 1.57972200 0.00000000 0.00000000
> >> > F -1.57972200 0.00000000 0.00000000
> >> > S 0.00000000 0.00000000 0.00000000
> >> >
> >> > Python script: --------
> >> > from numpy import *
> >> > from cclib.parser import ccopen
> >> > from cclib.method import LPA
> >> > parser = ccopen("test.log")
> >> > data = parser.parse()
> >> > method = LPA(data)
> >> > method.calculate()
> >> >
> >> >
> savetxt("LPA-big.csv",transpose(2*method.aoresults[0][:data.homos[0]+1]))
> >> >
> >> > Script output: --------
> >> > ...
> >> > [Gaussian test.log INFO] Creating attribute coreelectrons[]
> >> > [LPA <cclib.parser.data.ccData object at 0x1015ba150> INFO] Creating
> >> > attribute aoresults: [array[2]]
> >> >
> >> >
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/cclib/method/lpa.py:99:
> >> > ComplexWarning: Casting complex values to real discards the imaginary
> >> > part
> >> > self.aoresults[spin][i] = numpy.multiply(temp1, temp2).astype("d")
> >> > [LPA <cclib.parser.data.ccData object at 0x1015ba150> INFO] Saving
> >> > partitioned results in fragresults: [array[2]]
> >> > [LPA <cclib.parser.data.ccData object at 0x1015ba150> INFO] Creating
> >> > fragcharges: array[1]
> >>
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> > RSA(R) Conference 2012
> >> > Save $700 by Nov 18
> >> > Register now
> >> > http://p.sf.net/sfu/rsa-sfdev2dev1
> >>
> >> > _______________________________________________
> >> > cclib-users mailing list
> >> > ccl...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/cclib-users
> >>
> >>
> >> --
> >> written by Karol Langner
> >> Sat Nov 5 09:34:29 CET 2011
> >
> >
> >
> ------------------------------------------------------------------------------
> > RSA(R) Conference 2012
> > Save $700 by Nov 18
> > Register now
> > http://p.sf.net/sfu/rsa-sfdev2dev1
> > _______________________________________________
> > cclib-users mailing list
> > ccl...@li...
> > https://lists.sourceforge.net/lists/listinfo/cclib-users
> >
> >
>
|
|
From: Adam T. <ate...@gm...> - 2011-11-15 20:22:24
|
Hi Martin,
Thanks for the info. It's a bit odd that slight distortions return the
value to 70.00. Out of curiosity, do you still get the complex warning
at the LPA step for these calculations?
Adam
On Tue, Nov 15, 2011 at 11:50 AM, Martin Rahm <mar...@gm...> wrote:
> Hi Adam, and everyone,
> I just figured out a way around the problem. First, the same thing happens
> for single points, and it remains if one runs with "nosymm", or if the
> nuclear coordinate input is switched between cartesian/z-mat. However, these
> latter changes do seem to affect the total number of electrons and the
> orbital populations slightly different.
> The solution I found was to perturb the Oh symmetry very slightly (into
> C3v), then the electron count becomes 70.000, and all ligands are treated
> equally. The same goes for Td systems, which have to be disturbed into D2d.
> In other words it seems like the code has problems with "spherically"
> symmetric wave functions.
> Best,
> Martin
>
>
> On Tue, Nov 15, 2011 at 10:19 AM, Adam Tenderholt <ate...@gm...>
> wrote:
>>
>> Hi Martin and others,
>>
>> Sorry for the delayed response....
>>
>> The complex warning suggests there's a complex value being discarded
>> that may be important. Does anyone know if we should be taking the
>> norm instead of simply discarding the imaginary part?
>>
>> Also, does it matter that this is an Opt Freq calc? Does Gaussian
>> print the one-electron overlap matrix (aooverlaps) at the final
>> geometry? (I usually don't combine Opt and Freq calcs, so I don't
>> know, but the file looks like the final overlap matrix isn't at the
>> converged geometry.) If not, perhaps the problem is from using the
>> overlap matrix at the first structure and the orbital coefficients at
>> the final structure.
>>
>> Take care,
>>
>> Adam
>>
>> On Sat, Nov 5, 2011 at 1:20 PM, Martin Rahm <mar...@gm...> wrote:
>> > Hi Karol,
>> > I realized that I had used cartesian coordinates in the original input
>> > file.
>> > When I used a z-matrix instead (and defined S as atom 0) the LPA warning
>> > was
>> > still the same, but the total number of electrons turned out to be 70.22
>> > (instead of 70.3).
>> > I should also mention that the LPA-charge of all F ligands are slightly
>> > different, even though they are symmetrically identical.
>> > Best,
>> > Martin
>> > On Sat, Nov 5, 2011 at 1:34 AM, Karol M. Langner
>> > <kar...@gm...>
>> > wrote:
>> >>
>> >> Hi Martin,
>> >>
>> >> Can you provide the output file for that Gaussian job?
>> >>
>> >> Best,
>> >> Karol
>> >>
>> >> On Nov 04 2011, Martin Rahm wrote:
>> >> > Dear List,
>> >> >
>> >> > I'm running a trial Löwdin population analysis (LPA) on SF6, from a
>> >> > B3LYP/cc-pVTZ calculation. Something is awry, the total number of
>> >> > electrons gets overestimated by 0.3 (70.3), and there is a "complex
>> >> > warning" when running the LPA.
>> >> >
>> >> > LPA is supposed to be rotationally invariant if one use "pure"
>> >> > spherical
>> >> > harmonics in the basis set, e.g. 5 d functions instead of 6. (which
>> >> > cc-pVTZ
>> >> > does). Anyone have any clue to this behavior?
>> >> >
>> >> > Best regards,
>> >> > Martin
>> >> >
>> >> > Gaussian Input: ---------
>> >> > # opt freq b3lyp/cc-pvtz pop=(nboread,full) iop(3/33=1,3/36=-1)
>> >> >
>> >> > Title Card Required
>> >> >
>> >> > 0 1
>> >> > F 0.00000000 0.00000000 1.57972200
>> >> > F 0.00000000 1.57972200 0.00000000
>> >> > F 0.00000000 0.00000000 -1.57972200
>> >> > F 0.00000000 -1.57972200 0.00000000
>> >> > F 1.57972200 0.00000000 0.00000000
>> >> > F -1.57972200 0.00000000 0.00000000
>> >> > S 0.00000000 0.00000000 0.00000000
>> >> >
>> >> > Python script: --------
>> >> > from numpy import *
>> >> > from cclib.parser import ccopen
>> >> > from cclib.method import LPA
>> >> > parser = ccopen("test.log")
>> >> > data = parser.parse()
>> >> > method = LPA(data)
>> >> > method.calculate()
>> >> >
>> >> >
>> >> > savetxt("LPA-big.csv",transpose(2*method.aoresults[0][:data.homos[0]+1]))
>> >> >
>> >> > Script output: --------
>> >> > ...
>> >> > [Gaussian test.log INFO] Creating attribute coreelectrons[]
>> >> > [LPA <cclib.parser.data.ccData object at 0x1015ba150> INFO] Creating
>> >> > attribute aoresults: [array[2]]
>> >> >
>> >> >
>> >> > /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/cclib/method/lpa.py:99:
>> >> > ComplexWarning: Casting complex values to real discards the imaginary
>> >> > part
>> >> > self.aoresults[spin][i] = numpy.multiply(temp1, temp2).astype("d")
>> >> > [LPA <cclib.parser.data.ccData object at 0x1015ba150> INFO] Saving
>> >> > partitioned results in fragresults: [array[2]]
>> >> > [LPA <cclib.parser.data.ccData object at 0x1015ba150> INFO] Creating
>> >> > fragcharges: array[1]
>> >>
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------------------
>> >> > RSA(R) Conference 2012
>> >> > Save $700 by Nov 18
>> >> > Register now
>> >> > http://p.sf.net/sfu/rsa-sfdev2dev1
>> >>
>> >> > _______________________________________________
>> >> > cclib-users mailing list
>> >> > ccl...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/cclib-users
>> >>
>> >>
>> >> --
>> >> written by Karol Langner
>> >> Sat Nov 5 09:34:29 CET 2011
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > RSA(R) Conference 2012
>> > Save $700 by Nov 18
>> > Register now
>> > http://p.sf.net/sfu/rsa-sfdev2dev1
>> > _______________________________________________
>> > cclib-users mailing list
>> > ccl...@li...
>> > https://lists.sourceforge.net/lists/listinfo/cclib-users
>> >
>> >
>
>
|
|
From: Martin R. <mar...@gm...> - 2011-11-15 20:43:39
|
Hi Adam,
No, as long as the symmetry is not Oh or Td, there is no warning.
Best,
Martin
On Tue, Nov 15, 2011 at 12:22 PM, Adam Tenderholt <ate...@gm...>wrote:
> Hi Martin,
>
> Thanks for the info. It's a bit odd that slight distortions return the
> value to 70.00. Out of curiosity, do you still get the complex warning
> at the LPA step for these calculations?
>
> Adam
>
>
> On Tue, Nov 15, 2011 at 11:50 AM, Martin Rahm <mar...@gm...>
> wrote:
> > Hi Adam, and everyone,
> > I just figured out a way around the problem. First, the same thing
> happens
> > for single points, and it remains if one runs with "nosymm", or if the
> > nuclear coordinate input is switched between cartesian/z-mat. However,
> these
> > latter changes do seem to affect the total number of electrons and the
> > orbital populations slightly different.
> > The solution I found was to perturb the Oh symmetry very slightly (into
> > C3v), then the electron count becomes 70.000, and all ligands are treated
> > equally. The same goes for Td systems, which have to be disturbed into
> D2d.
> > In other words it seems like the code has problems with "spherically"
> > symmetric wave functions.
> > Best,
> > Martin
> >
> >
> > On Tue, Nov 15, 2011 at 10:19 AM, Adam Tenderholt <ate...@gm...
> >
> > wrote:
> >>
> >> Hi Martin and others,
> >>
> >> Sorry for the delayed response....
> >>
> >> The complex warning suggests there's a complex value being discarded
> >> that may be important. Does anyone know if we should be taking the
> >> norm instead of simply discarding the imaginary part?
> >>
> >> Also, does it matter that this is an Opt Freq calc? Does Gaussian
> >> print the one-electron overlap matrix (aooverlaps) at the final
> >> geometry? (I usually don't combine Opt and Freq calcs, so I don't
> >> know, but the file looks like the final overlap matrix isn't at the
> >> converged geometry.) If not, perhaps the problem is from using the
> >> overlap matrix at the first structure and the orbital coefficients at
> >> the final structure.
> >>
> >> Take care,
> >>
> >> Adam
> >>
> >> On Sat, Nov 5, 2011 at 1:20 PM, Martin Rahm <mar...@gm...>
> wrote:
> >> > Hi Karol,
> >> > I realized that I had used cartesian coordinates in the original input
> >> > file.
> >> > When I used a z-matrix instead (and defined S as atom 0) the LPA
> warning
> >> > was
> >> > still the same, but the total number of electrons turned out to be
> 70.22
> >> > (instead of 70.3).
> >> > I should also mention that the LPA-charge of all F ligands are
> slightly
> >> > different, even though they are symmetrically identical.
> >> > Best,
> >> > Martin
> >> > On Sat, Nov 5, 2011 at 1:34 AM, Karol M. Langner
> >> > <kar...@gm...>
> >> > wrote:
> >> >>
> >> >> Hi Martin,
> >> >>
> >> >> Can you provide the output file for that Gaussian job?
> >> >>
> >> >> Best,
> >> >> Karol
> >> >>
> >> >> On Nov 04 2011, Martin Rahm wrote:
> >> >> > Dear List,
> >> >> >
> >> >> > I'm running a trial Löwdin population analysis (LPA) on SF6, from a
> >> >> > B3LYP/cc-pVTZ calculation. Something is awry, the total number of
> >> >> > electrons gets overestimated by 0.3 (70.3), and there is a "complex
> >> >> > warning" when running the LPA.
> >> >> >
> >> >> > LPA is supposed to be rotationally invariant if one use "pure"
> >> >> > spherical
> >> >> > harmonics in the basis set, e.g. 5 d functions instead of 6. (which
> >> >> > cc-pVTZ
> >> >> > does). Anyone have any clue to this behavior?
> >> >> >
> >> >> > Best regards,
> >> >> > Martin
> >> >> >
> >> >> > Gaussian Input: ---------
> >> >> > # opt freq b3lyp/cc-pvtz pop=(nboread,full) iop(3/33=1,3/36=-1)
> >> >> >
> >> >> > Title Card Required
> >> >> >
> >> >> > 0 1
> >> >> > F 0.00000000 0.00000000 1.57972200
> >> >> > F 0.00000000 1.57972200 0.00000000
> >> >> > F 0.00000000 0.00000000 -1.57972200
> >> >> > F 0.00000000 -1.57972200 0.00000000
> >> >> > F 1.57972200 0.00000000 0.00000000
> >> >> > F -1.57972200 0.00000000 0.00000000
> >> >> > S 0.00000000 0.00000000 0.00000000
> >> >> >
> >> >> > Python script: --------
> >> >> > from numpy import *
> >> >> > from cclib.parser import ccopen
> >> >> > from cclib.method import LPA
> >> >> > parser = ccopen("test.log")
> >> >> > data = parser.parse()
> >> >> > method = LPA(data)
> >> >> > method.calculate()
> >> >> >
> >> >> >
> >> >> >
> savetxt("LPA-big.csv",transpose(2*method.aoresults[0][:data.homos[0]+1]))
> >> >> >
> >> >> > Script output: --------
> >> >> > ...
> >> >> > [Gaussian test.log INFO] Creating attribute coreelectrons[]
> >> >> > [LPA <cclib.parser.data.ccData object at 0x1015ba150> INFO]
> Creating
> >> >> > attribute aoresults: [array[2]]
> >> >> >
> >> >> >
> >> >> >
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/cclib/method/lpa.py:99:
> >> >> > ComplexWarning: Casting complex values to real discards the
> imaginary
> >> >> > part
> >> >> > self.aoresults[spin][i] = numpy.multiply(temp1,
> temp2).astype("d")
> >> >> > [LPA <cclib.parser.data.ccData object at 0x1015ba150> INFO] Saving
> >> >> > partitioned results in fragresults: [array[2]]
> >> >> > [LPA <cclib.parser.data.ccData object at 0x1015ba150> INFO]
> Creating
> >> >> > fragcharges: array[1]
> >> >>
> >> >> >
> >> >> >
> >> >> >
> ------------------------------------------------------------------------------
> >> >> > RSA(R) Conference 2012
> >> >> > Save $700 by Nov 18
> >> >> > Register now
> >> >> > http://p.sf.net/sfu/rsa-sfdev2dev1
> >> >>
> >> >> > _______________________________________________
> >> >> > cclib-users mailing list
> >> >> > ccl...@li...
> >> >> > https://lists.sourceforge.net/lists/listinfo/cclib-users
> >> >>
> >> >>
> >> >> --
> >> >> written by Karol Langner
> >> >> Sat Nov 5 09:34:29 CET 2011
> >> >
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> > RSA(R) Conference 2012
> >> > Save $700 by Nov 18
> >> > Register now
> >> > http://p.sf.net/sfu/rsa-sfdev2dev1
> >> > _______________________________________________
> >> > cclib-users mailing list
> >> > ccl...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/cclib-users
> >> >
> >> >
> >
> >
>
|
|
From: Martin R. <mar...@gm...> - 2012-01-28 01:12:48
|
Hi Karol,
Interesting. I'm using Python 2.7.1, so different but newer than yours,
with GCC 4.2.1, if that matters. cclib is 1.01 (the latest), and finally,
Numpy 1.5.1, which also is newer than yours.
It's all on a OS X 10.6.8 machine.
Clearly there are some external differences, however, going back to older
versions are cumbersome. Does this mean one always have to use older
packages to be sure, or is there a possibility to make cclib work with the
new ones?
Thanks again for your hard work & with best regards,
Martin
On Fri, Jan 27, 2012 at 4:51 PM, Karol M. Langner
<kar...@gm...>wrote:
> Hi Martin,
>
> I've come around to this issue. First of all, in this case I don't get
> the complex number error your report, and my fragcharges sum up nicely.
> That is a good thing, because it means the cause is perhaps external
> to cclib.
>
> I'm using Python 2.6 here, but I assume that would not be a problem.
> My NumPy version is 1.4.1 and I'm using the latest cclib revision from svn.
> What are your version?
>
> - Karol
>
> On Jan 12 2012, Martin Rahm wrote:
> > Hello again,
> >
> > I've come across another case of the "complex number" error. This time
> in a
> > very small diatomic.
> >
> > Running LPA on a M062X/cc-pwCV5Z wave function of ClF, and gets this
> error:
> >
> > [LPA <cclib.parser.data.ccData object at 0x1015ba1d0> INFO] Creating
> > attribute aoresults: [array[2]]
> >
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/cclib/method/lpa.py:99:
> > ComplexWarning: Casting complex values to real discards the imaginary
> part
> > self.aoresults[spin][i] = numpy.multiply(temp1, temp2).astype("d")
> >
> > This is quite cumbersome, since there is really no way of breaking
> symmetry
> > of a linear molecule (which solved the problem for larger molecules)!
> >
> > I've attached my log file, and also my script just in case.
> >
> > I hope you have a quick fix :)
> >
> > Best regards,
> > Martin
>
> > Archive: /tmp/ClF-M06-cc-pwCV5Z.log.zip
> > Length Date Time Name
> > --------- ---------- ----- ----
> > 8430472 2012-01-11 09:10 ClF-M06-cc-pwCV5Z.log
> > --------- -------
> > 8430472 1 file
>
>
> >
> ------------------------------------------------------------------------------
> > RSA(R) Conference 2012
> > Mar 27 - Feb 2
> > Save $400 by Jan. 27
> > Register now!
> > http://p.sf.net/sfu/rsa-sfdev2dev2
>
> > _______________________________________________
> > cclib-users mailing list
> > ccl...@li...
> > https://lists.sourceforge.net/lists/listinfo/cclib-users
>
>
> --
> written by Karol Langner
> Sat Jan 28 01:46:35 CET 2012
>
|
|
From: Karol M. L. <kar...@gm...> - 2012-01-28 02:41:38
|
Hi,
The differences are just due to me using an ultra-stable isntallation
on this particular computer. I will test with newer version on
another machine (probably tommorrow).
- Karol
On Jan 27 2012, Martin Rahm wrote:
> Hi Karol,
>
> Interesting. I'm using Python 2.7.1, so different but newer than yours,
> with GCC 4.2.1, if that matters. cclib is 1.01 (the latest), and finally,
> Numpy 1.5.1, which also is newer than yours.
>
> It's all on a OS X 10.6.8 machine.
>
> Clearly there are some external differences, however, going back to older
> versions are cumbersome. Does this mean one always have to use older
> packages to be sure, or is there a possibility to make cclib work with the
> new ones?
>
> Thanks again for your hard work & with best regards,
> Martin
>
> On Fri, Jan 27, 2012 at 4:51 PM, Karol M. Langner
> <kar...@gm...>wrote:
>
> > Hi Martin,
> >
> > I've come around to this issue. First of all, in this case I don't get
> > the complex number error your report, and my fragcharges sum up nicely.
> > That is a good thing, because it means the cause is perhaps external
> > to cclib.
> >
> > I'm using Python 2.6 here, but I assume that would not be a problem.
> > My NumPy version is 1.4.1 and I'm using the latest cclib revision from svn.
> > What are your version?
> >
> > - Karol
> >
> > On Jan 12 2012, Martin Rahm wrote:
> > > Hello again,
> > >
> > > I've come across another case of the "complex number" error. This time
> > in a
> > > very small diatomic.
> > >
> > > Running LPA on a M062X/cc-pwCV5Z wave function of ClF, and gets this
> > error:
> > >
> > > [LPA <cclib.parser.data.ccData object at 0x1015ba1d0> INFO] Creating
> > > attribute aoresults: [array[2]]
> > >
> > /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/cclib/method/lpa.py:99:
> > > ComplexWarning: Casting complex values to real discards the imaginary
> > part
> > > self.aoresults[spin][i] = numpy.multiply(temp1, temp2).astype("d")
> > >
> > > This is quite cumbersome, since there is really no way of breaking
> > symmetry
> > > of a linear molecule (which solved the problem for larger molecules)!
> > >
> > > I've attached my log file, and also my script just in case.
> > >
> > > I hope you have a quick fix :)
> > >
> > > Best regards,
> > > Martin
> >
> > > Archive: /tmp/ClF-M06-cc-pwCV5Z.log.zip
> > > Length Date Time Name
> > > --------- ---------- ----- ----
> > > 8430472 2012-01-11 09:10 ClF-M06-cc-pwCV5Z.log
> > > --------- -------
> > > 8430472 1 file
> >
> >
> > >
> > ------------------------------------------------------------------------------
> > > RSA(R) Conference 2012
> > > Mar 27 - Feb 2
> > > Save $400 by Jan. 27
> > > Register now!
> > > http://p.sf.net/sfu/rsa-sfdev2dev2
> >
> > > _______________________________________________
> > > cclib-users mailing list
> > > ccl...@li...
> > > https://lists.sourceforge.net/lists/listinfo/cclib-users
> >
> >
> > --
> > written by Karol Langner
> > Sat Jan 28 01:46:35 CET 2012
> >
--
written by Karol Langner
Sat Jan 28 03:40:06 CET 2012
|
|
From: Adam T. <ate...@gm...> - 2012-01-16 18:43:53
|
Hi Martin,
Any idea what happens if you use Int=UltraFine? Does this error still
appear for the diatomic with smaller basis sets? What about with for
cc-pV5Z?
Adam
On Thu, Jan 12, 2012 at 3:56 PM, Martin Rahm <mar...@gm...> wrote:
> Hello again,
>
> I've come across another case of the "complex number" error. This time in a
> very small diatomic.
>
> Running LPA on a M062X/cc-pwCV5Z wave function of ClF, and gets this error:
>
> [LPA <cclib.parser.data.ccData object at 0x1015ba1d0> INFO] Creating
> attribute aoresults: [array[2]]
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/cclib/method/lpa.py:99:
> ComplexWarning: Casting complex values to real discards the imaginary part
> self.aoresults[spin][i] = numpy.multiply(temp1, temp2).astype("d")
>
> This is quite cumbersome, since there is really no way of breaking symmetry
> of a linear molecule (which solved the problem for larger molecules)!
>
> I've attached my log file, and also my script just in case.
>
> I hope you have a quick fix :)
>
> Best regards,
> Martin
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Mar 27 - Feb 2
> Save $400 by Jan. 27
> Register now!
> http://p.sf.net/sfu/rsa-sfdev2dev2
> _______________________________________________
> cclib-users mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-users
>
|
|
From: Martin R. <mar...@gm...> - 2012-01-16 21:01:03
|
Hi Adam,
Unfortunately Int=ultrafine doesn't do anything. Neither does smaller basis
sets (tried cc-pVTZ and cc-pV5Z). Since the exact same error occurs for Oh
systems, but goes away upon distortion to C3v, it seems like something else
is wrong.
Best,
Martin
On Mon, Jan 16, 2012 at 10:43 AM, Adam Tenderholt <ate...@gm...>wrote:
> Hi Martin,
>
> Any idea what happens if you use Int=UltraFine? Does this error still
> appear for the diatomic with smaller basis sets? What about with for
> cc-pV5Z?
>
> Adam
>
>
> On Thu, Jan 12, 2012 at 3:56 PM, Martin Rahm <mar...@gm...>
> wrote:
> > Hello again,
> >
> > I've come across another case of the "complex number" error. This time
> in a
> > very small diatomic.
> >
> > Running LPA on a M062X/cc-pwCV5Z wave function of ClF, and gets this
> error:
> >
> > [LPA <cclib.parser.data.ccData object at 0x1015ba1d0> INFO] Creating
> > attribute aoresults: [array[2]]
> >
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/cclib/method/lpa.py:99:
> > ComplexWarning: Casting complex values to real discards the imaginary
> part
> > self.aoresults[spin][i] = numpy.multiply(temp1, temp2).astype("d")
> >
> > This is quite cumbersome, since there is really no way of breaking
> symmetry
> > of a linear molecule (which solved the problem for larger molecules)!
> >
> > I've attached my log file, and also my script just in case.
> >
> > I hope you have a quick fix :)
> >
> > Best regards,
> > Martin
> >
> >
> ------------------------------------------------------------------------------
> > RSA(R) Conference 2012
> > Mar 27 - Feb 2
> > Save $400 by Jan. 27
> > Register now!
> > http://p.sf.net/sfu/rsa-sfdev2dev2
> > _______________________________________________
> > cclib-users mailing list
> > ccl...@li...
> > https://lists.sourceforge.net/lists/listinfo/cclib-users
> >
>
|
|
From: Adam T. <ate...@gm...> - 2012-01-21 17:55:45
|
Hi Martin,
Thanks for the info and logfile. A fix isn't immediately apparent to
me, so I will (unless Noel or Karol get to it first) have to spend
some time figuring out what is going on. I probably can't get to it
for a few weeks though.
Adam
On Mon, Jan 16, 2012 at 1:00 PM, Martin Rahm <mar...@gm...> wrote:
> Hi Adam,
>
> Unfortunately Int=ultrafine doesn't do anything. Neither does smaller basis
> sets (tried cc-pVTZ and cc-pV5Z). Since the exact same error occurs for Oh
> systems, but goes away upon distortion to C3v, it seems like something else
> is wrong.
>
> Best,
> Martin
>
>
> On Mon, Jan 16, 2012 at 10:43 AM, Adam Tenderholt <ate...@gm...>
> wrote:
>>
>> Hi Martin,
>>
>> Any idea what happens if you use Int=UltraFine? Does this error still
>> appear for the diatomic with smaller basis sets? What about with for
>> cc-pV5Z?
>>
>> Adam
>>
>>
>> On Thu, Jan 12, 2012 at 3:56 PM, Martin Rahm <mar...@gm...>
>> wrote:
>> > Hello again,
>> >
>> > I've come across another case of the "complex number" error. This time
>> > in a
>> > very small diatomic.
>> >
>> > Running LPA on a M062X/cc-pwCV5Z wave function of ClF, and gets this
>> > error:
>> >
>> > [LPA <cclib.parser.data.ccData object at 0x1015ba1d0> INFO] Creating
>> > attribute aoresults: [array[2]]
>> >
>> > /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/cclib/method/lpa.py:99:
>> > ComplexWarning: Casting complex values to real discards the imaginary
>> > part
>> > self.aoresults[spin][i] = numpy.multiply(temp1, temp2).astype("d")
>> >
>> > This is quite cumbersome, since there is really no way of breaking
>> > symmetry
>> > of a linear molecule (which solved the problem for larger molecules)!
>> >
>> > I've attached my log file, and also my script just in case.
>> >
>> > I hope you have a quick fix :)
>> >
>> > Best regards,
>> > Martin
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > RSA(R) Conference 2012
>> > Mar 27 - Feb 2
>> > Save $400 by Jan. 27
>> > Register now!
>> > http://p.sf.net/sfu/rsa-sfdev2dev2
>> > _______________________________________________
>> > cclib-users mailing list
>> > ccl...@li...
>> > https://lists.sourceforge.net/lists/listinfo/cclib-users
>> >
>
>
|
Thanks for helping keep SourceForge clean.
X