pyquante-devel — Discussions of interest to developers of the PyQuante program

[Pyquante-devel] Recent build errors

[Rick M. <rpm...@gm...>]

Wanted to respond to Yuri's recent build query. I haven't built v1.6.5 in a
long time. I'll try to do so, but it will be a few days until I get to
that, since I'm traveling.

In the meantime, perhaps the newer versions at
https://github.com/rpmuller/pyquante2 will be useful.

-- 
Rick Muller
rpm...@gm...

[Pyquante-devel] Compilation fails: no member named 'd_type' in 'PyMethodDescrObject'

[Yuri <yu...@ra...>]

Build of the version 1.6.5 fails:

Src/PyQuante/contracted_gto.c:2063:46: error: no member named 'd_type' 
in 'PyMethodDescrObject'
         return PyDescr_NewClassMethod(descr->d_type, descr->d_method);
                                       ~~~~~  ^
Src/PyQuante/contracted_gto.c:2190:18: error: no member named 'exc_type' 
in 'struct _ts'
     if ((tstate->exc_type != NULL) & (tstate->exc_type != Py_None)) {
          ~~~~~~  ^
Src/PyQuante/contracted_gto.c:2190:47: error: no member named 'exc_type' 
in 'struct _ts'
     if ((tstate->exc_type != NULL) & (tstate->exc_type != Py_None)) {
                                       ~~~~~~  ^
Src/PyQuante/contracted_gto.c:2191:28: error: no member named 'exc_type' 
in 'struct _ts'
         tmp_type = tstate->exc_type;
                    ~~~~~~  ^
Src/PyQuante/contracted_gto.c:2192:29: error: no member named 
'exc_value' in 'struct _ts'; did you mean 'curexc_value'?
         tmp_value = tstate->exc_value;
                             ^~~~~~~~~
                             curexc_value
/usr/local/include/python3.9/cpython/pystate.h:78:15: note: 
'curexc_value' declared here
     PyObject *curexc_value;
               ^
Src/PyQuante/contracted_gto.c:2193:26: error: no member named 
'exc_traceback' in 'struct _ts'; did you mean 'curexc_traceback'?
         tmp_tb = tstate->exc_traceback;
                          ^~~~~~~~~~~~~
                          curexc_traceback
/usr/local/include/python3.9/cpython/pystate.h:79:15: note: 
'curexc_traceback' declared here
     PyObject *curexc_traceback;
               ^
Src/PyQuante/contracted_gto.c:2196:17: error: no member named 'exc_type' 
in 'struct _ts'
         tstate->exc_type = 0;
         ~~~~~~  ^
Src/PyQuante/contracted_gto.c:2197:17: error: no member named 
'exc_value' in 'struct _ts'; did you mean 'curexc_value'?
         tstate->exc_value = 0;
                 ^~~~~~~~~
                 curexc_value
/usr/local/include/python3.9/cpython/pystate.h:78:15: note: 
'curexc_value' declared here
     PyObject *curexc_value;
               ^
Src/PyQuante/contracted_gto.c:2198:17: error: no member named 
'exc_traceback' in 'struct _ts'; did you mean 'curexc_traceback'?
         tstate->exc_traceback = 0;
                 ^~~~~~~~~~~~~
                 curexc_traceback
/usr/local/include/python3.9/cpython/pystate.h:79:15: note: 
'curexc_traceback' declared here
     PyObject *curexc_traceback;


clang-14

Python-3.9

OS: FreeBSD 13.1



Thanks,

Yuri

[Pyquante-devel] PyQuante2 Development

[Muller, R. <rm...@sa...>]

I wanted to let people know that I've begun working on pyquante2. Over the years, the PyQuante code has become increasingly difficult, and decreasingly fun to work with. I'm trying to clean, organize, simplify, and speed the code as I rewrite it. I'd like the code to be much easier to work with, to let us do much more ambitious things. I want the code to be beautiful, as much as we can make it.

All the code is available at https://github.com/rpmuller/pyquante2 . There is also a IPython notebook detailing the new code in use at http://nbviewer.ipython.org/5745404 .

I'm not asking for help at this point. I am asking for advice. I'm keeping all of my notes on the github site, either in the read me file (https://github.com/rpmuller/pyquante2/blob/master/README.md) or in the todo list (https://github.com/rpmuller/pyquante2/blob/master/TODO.md). I'm also trying to keep frequent update on what I've changed in the code base at http://rpmuller.github.io .

I'd love suggestions about things we can do to make the code truly great. What things do you hate right now? What things do you crave?

Over the years I've received many suggestions of ways to improve PyQuante that I haven't been able to implement, either because I haven't had the time (PyQuante isn't part of my normal day-to-day job), or because the code base was too hard to work with. I'd like to apologize for letting these things slip by, and to thank those of you who are still with the project despite these lapses.

Please let me know your opinion on these developments. Thanks for your patience.

Rick
rpm...@gm...<mailto:rpm...@gm...>
rm...@sa...<mailto:rm...@sa...>
@rpmuller twitter, #pyquante hashtag
http://rpmuller.github.io

[Pyquante-devel] Help needed

[Ghous N. <gbn...@mt...>]

Hi,

I would like to post the problems that i have encountered while trying to run pyquante.

Thanks,

Dr Ghous

[Pyquante-devel] Any Cython experts want to help me with hgp?

[Muller, R. <rm...@sa...>]

I prefer to use C to write Python wrappers and extension libraries, but I realize I'm almost alone in this, and that many people today prefer Cython. I've been playing around with converting the hgp.py routine into faster code using Cython. The problem is that it isn't nearly as fast as the C code. I was wondering whether anyone could help.

I'm currently running a number of different integrals through the vrr routines. The python version of hgp runs in about 0.9 sec, and the C version of the routine runs in 0.0074 sec. I can't get the cython version of vrr any faster than 0.42 seconds, which is a nice bit faster than the python, but much slower than the C.

I figure I'm doing something dumb. Is anyone on the PyQuante devel list willing to look at what I've done and give me some pointers?

Thanks in advance,

Rick

[Pyquante-devel] Settings can now be set at runtime

[Muller, R. <rm...@sa...>]

One of the things that has long bothered me about pyquante is that the source had to be changed to change the default behavior. For example, if you wanted to change the 2e integral method, you essentially had to redo the whole setup.py/build/install procedure.

Starting with the version currently in svn (version 199), this is no longer the case. I've been pulling most of the default settings into a file called settings.py. This can be overridden at runtime. For example, the test run for H2:

>>> from PyQuante import SCF
>>> from PyQuante.TestMolecules import h2
>>> solver = SCF(h2,method='HF')
>>> solver.iterate()
>>> print solver.energy

can be changed to use some other 2e integral package via:

>>> from PyQuante import SCF
>>> from PyQuante.TestMolecules import h2

>>> import PyQuante.settings
>>> from PyQuante import hgp
>>> PyQuante.settings.contr_coulomb = hgp.contr_coulomb

>>> solver = SCF(h2,method='HF')
>>> solver.iterate()
>>> print solver.energy

Other settings can be similarly changed. Probably due for a 1.7 point release now.

[Pyquante-devel] Fixed a bug in cghp.c today

[Muller, R. <rm...@sa...>]

Fixed an old bug in chgp.c today that Jussi had pointed out some time ago. Essentially some f-basis set functions would be integrated incorrectly, due to the presence of a hard-wired maximum angular momentum variable MAXAM in the file that controlled the size of a temporary buffer array. This bug did not affect the python version hgp.py.

Re: [Pyquante-devel] test error

[Diego M. <die...@gm...>]

Hi Gabriele,

Many Thanks run fine!!! :-)

Int times:
CHGP Ints:     2.39006280899
CRys Ints:    1.43985819817
CINTS Ints:    4.39044094086
HGP Ints:      112.938334942
Rys Ints:   110.330872059
Py Ints:   137.262019873

in the Intel(R) Core(TM)2 Quad  CPU   Q9300  @ 2.50GHz, 4GB DDR2 RAM.

Many thanks.

Diego V. Moreno





2011/5/26 Gabriele Lanaro <gab...@gm...>

> Hi! I've changed the way CGBF objects access their attributes for
> optimization/cleaning reasons, so you (also I) should update the code in the
> test integral.py at line 41:
>
> 41,45c41,45
> <     Jij = coul_func(a.exps(),a.coefs(),a.pnorms(),a.origin(),a.powers(),
> <                     b.exps(),b.coefs(),b.pnorms(),b.origin(),b.powers(),
> <                     c.exps(),c.coefs(),c.pnorms(),c.origin(),c.powers(),
> <                     d.exps(),d.coefs(),d.pnorms(),d.origin(),d.powers())
> <     return a.norm()*b.norm()*c.norm()*d.norm()*Jij
> ---
> >     Jij = coul_func(a.pexps,a.pcoefs,a.pnorms,a.origin,a.powers,
> >                     b.pexps,b.pcoefs,b.pnorms,b.origin,b.powers,
> >                     c.pexps,c.pcoefs,c.pnorms,c.origin,c.powers,
> >                     d.pexps,d.pcoefs,d.pnorms,d.origin,d.powers)
> >     return a.norm*b.norm*c.norm*d.norm*Jij
>
> Basically you should rename some of this functions. Let me know if you have
> any problem
> 2011/5/26 Diego Moreno <die...@gm...>
>
>> Hi, I new user in PyQuante,
>>
>> I have a problem, in PyQuante test...
>> ./integrals.py
>> openbabel not found in path, switching to PyQuante backend
>> libint extension not found, switching to normal ERI computation
>> Int times:
>> Traceback (most recent call last):
>>   File "./integrals.py", line 96, in <module>
>>     if __name__ == '__main__': test()
>>   File "./integrals.py", line 65, in test
>>     int0 = get2ints(bfs,chgpcc)
>>   File "./integrals.py", line 36, in get2ints
>>     coul_func)
>>   File "./integrals.py", line 41, in coulomb
>>     Jij = coul_func(a.exps(),a.coefs(),a.pnorms(),a.origin(),a.powers(),
>> AttributeError: 'CGBF' object has no attribute 'exps'
>>
>> Other test run fine, my system is Linux Debian, testing (AMD64), it is a
>> problem with 64 bits?
>>
>> Thanks,
>>
>> Diego V. Moreno
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> vRanger cuts backup time in half-while increasing security.
>> With the market-leading solution for virtual backup and recovery,
>> you get blazing-fast, flexible, and affordable data protection.
>> Download your free trial now.
>> http://p.sf.net/sfu/quest-d2dcopy1
>> _______________________________________________
>> Pyquante-devel mailing list
>> Pyq...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyquante-devel
>>
>>
>

Re: [Pyquante-devel] test error

[Gabriele L. <gab...@gm...>]

Hi! I've changed the way CGBF objects access their attributes for
optimization/cleaning reasons, so you (also I) should update the code in the
test integral.py at line 41:

41,45c41,45
<     Jij = coul_func(a.exps(),a.coefs(),a.pnorms(),a.origin(),a.powers(),
<                     b.exps(),b.coefs(),b.pnorms(),b.origin(),b.powers(),
<                     c.exps(),c.coefs(),c.pnorms(),c.origin(),c.powers(),
<                     d.exps(),d.coefs(),d.pnorms(),d.origin(),d.powers())
<     return a.norm()*b.norm()*c.norm()*d.norm()*Jij
---
>     Jij = coul_func(a.pexps,a.pcoefs,a.pnorms,a.origin,a.powers,
>                     b.pexps,b.pcoefs,b.pnorms,b.origin,b.powers,
>                     c.pexps,c.pcoefs,c.pnorms,c.origin,c.powers,
>                     d.pexps,d.pcoefs,d.pnorms,d.origin,d.powers)
>     return a.norm*b.norm*c.norm*d.norm*Jij

Basically you should rename some of this functions. Let me know if you have
any problem
2011/5/26 Diego Moreno <die...@gm...>

> Hi, I new user in PyQuante,
>
> I have a problem, in PyQuante test...
> ./integrals.py
> openbabel not found in path, switching to PyQuante backend
> libint extension not found, switching to normal ERI computation
> Int times:
> Traceback (most recent call last):
>   File "./integrals.py", line 96, in <module>
>     if __name__ == '__main__': test()
>   File "./integrals.py", line 65, in test
>     int0 = get2ints(bfs,chgpcc)
>   File "./integrals.py", line 36, in get2ints
>     coul_func)
>   File "./integrals.py", line 41, in coulomb
>     Jij = coul_func(a.exps(),a.coefs(),a.pnorms(),a.origin(),a.powers(),
> AttributeError: 'CGBF' object has no attribute 'exps'
>
> Other test run fine, my system is Linux Debian, testing (AMD64), it is a
> problem with 64 bits?
>
> Thanks,
>
> Diego V. Moreno
>
>
>
>
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Pyquante-devel mailing list
> Pyq...@li...
> https://lists.sourceforge.net/lists/listinfo/pyquante-devel
>
>

[Pyquante-devel] test error

[Diego M. <die...@gm...>]

Hi, I new user in PyQuante,

I have a problem, in PyQuante test...
./integrals.py
openbabel not found in path, switching to PyQuante backend
libint extension not found, switching to normal ERI computation
Int times:
Traceback (most recent call last):
  File "./integrals.py", line 96, in <module>
    if __name__ == '__main__': test()
  File "./integrals.py", line 65, in test
    int0 = get2ints(bfs,chgpcc)
  File "./integrals.py", line 36, in get2ints
    coul_func)
  File "./integrals.py", line 41, in coulomb
    Jij = coul_func(a.exps(),a.coefs(),a.pnorms(),a.origin(),a.powers(),
AttributeError: 'CGBF' object has no attribute 'exps'

Other test run fine, my system is Linux Debian, testing (AMD64), it is a
problem with 64 bits?

Thanks,

Diego V. Moreno

Re: [Pyquante-devel] Bug found in the test suite on MacOS

[Jussi L. <jus...@ik...>]

On Wed, 18 May 2011 17:01:47 +0000
"Muller, Richard" <rm...@sa...> wrote:
> I think this is now solved. The issue is that the DIIS matrix was
> becoming nearly singular, which was causing undefined behavior on
> different platforms. I replaced the normal Ax=b solve with one based
> on a pseudoinvers (the code is called stable_solve() and is now in
> LA2.py), which has removed many of the things that I didn't like
> about the DIIS stability.

Maybe using C2-DIIS would be a better option? It should work a lot
better with nearly-singular matrices. See

H. Sellers, "The C2-DIIS convergence acceleration algorithm",
Int. J. Quant. Chem. 45 (1993), pp. 31 - 41.
-- 
Jussi Lehtola
jus...@ik...

Re: [Pyquante-devel] Bug found in the test suite on MacOS

[Muller, R. <rm...@sa...>]

I think this is now solved. The issue is that the DIIS matrix was becoming nearly singular, which was causing undefined behavior on different platforms. I replaced the normal Ax=b solve with one based on a pseudoinvers (the code is called stable_solve() and is now in LA2.py), which has removed many of the things that I didn't like about the DIIS stability.

As always, let me know if you have any errors.

From: "Richard P. Muller" <rm...@sa...<mailto:rm...@sa...>>
Date: Fri, 8 Apr 2011 22:09:21 +0000
To: "pyq...@li...<mailto:pyq...@li...>" <pyq...@li...<mailto:pyq...@li...>>
Subject: [Pyquante-devel] Bug found in the test suite on MacOS

I'm getting a failure in the test suite on my mac laptop. Doesn’t fail on my linux box. Still trying to track this down.

The test321G test in the UnitSuite fails:

======================================================================
FAIL: test321G (__main__.UnitTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Tests/UnitSweet.py", line 121, in test321G
    self.assertAlmostEqual(solv.energy,-1.122956,4)
AssertionError: -1.1211621931894917 != -1.122956 within 4 places

----------------------------------------------------------------------

I pulled out the test and ran it on my mac and linux boxes. The geometries and basis sets are identical. However, the iterations are different in a bizarre way. The (working) linux iterations have energies that look like:
-1.07240839848
-1.12183592844
-1.12295601995
-1.12295601796
Whereas the mac has energies
-1.07240839848
-1.12183592844
-1.12295601995
-1.12119876382
-1.12116211967
-1.12116219319
Which means the integrals work (since the first few energies are the same). Most likely place is some instability in the Ax=b solve in the DIIS routine, but I haven't found that yet. Will let everyone know if/when this is fixed.

------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev_______________________________________________ Pyquante-devel mailing list Pyq...@li...<mailto:Pyq...@li...> https://lists.sourceforge.net/lists/listinfo/pyquante-devel

Re: [Pyquante-devel] Minor fix for MSVC

[Muller, R. <rm...@sa...>]

I ran the test suite on Mac and Linux and I didn't have any errors.

On 5/12/11 3:01 AM, "Noel O'Boyle" <bao...@gm...> wrote:

>Hi all,
>
>It's been a while, but someone contacted me regarding MSVC support.
>I've made a minor change to swap.c that I'd like someone to review:
>
>http://pyquante.svn.sourceforge.net/viewvc/pyquante/trunk/Src/lib/utils/sw
>ap.c?r1=188&r2=187&pathrev=188
>
>I could wrap the new code in an #ifdef, but it's simpler not to do
>that if possible.
>
>The code still doesn't link properly under MSVC. It looks like it's
>complaining about that lgamma code I added some years ago. Hopefully
>I'll figure this out.
>
>- Noel
>
>--------------------------------------------------------------------------
>----
>Achieve unprecedented app performance and reliability
>What every C/C++ and Fortran developer should know.
>Learn how Intel has extended the reach of its next-generation tools
>to help boost performance applications - inlcuding clusters.
>http://p.sf.net/sfu/intel-dev2devmay
>_______________________________________________
>Pyquante-devel mailing list
>Pyq...@li...
>https://lists.sourceforge.net/lists/listinfo/pyquante-devel
>

[Pyquante-devel] Minor fix for MSVC

[Noel O'B. <bao...@gm...>]

Hi all,

It's been a while, but someone contacted me regarding MSVC support.
I've made a minor change to swap.c that I'd like someone to review:

http://pyquante.svn.sourceforge.net/viewvc/pyquante/trunk/Src/lib/utils/swap.c?r1=188&r2=187&pathrev=188

I could wrap the new code in an #ifdef, but it's simpler not to do
that if possible.

The code still doesn't link properly under MSVC. It looks like it's
complaining about that lgamma code I added some years ago. Hopefully
I'll figure this out.

- Noel

Re: [Pyquante-devel] Bug found in the test suite on MacOS

[Muller, R. <rm...@sa...>]

Little more information, maybe irrelevant:

On Linux, I'm running Python 2.6.1 with Numpy 1.4.1
On Mac, I'm running Python 2.7.1 with Numpy 1.5.1

From: "Richard P. Muller" <rm...@sa...<mailto:rm...@sa...>>
Date: Fri, 8 Apr 2011 22:09:21 +0000
To: "pyq...@li...<mailto:pyq...@li...>" <pyq...@li...<mailto:pyq...@li...>>
Subject: [Pyquante-devel] Bug found in the test suite on MacOS

I'm getting a failure in the test suite on my mac laptop. Doesn’t fail on my linux box. Still trying to track this down.

The test321G test in the UnitSuite fails:

======================================================================
FAIL: test321G (__main__.UnitTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Tests/UnitSweet.py", line 121, in test321G
    self.assertAlmostEqual(solv.energy,-1.122956,4)
AssertionError: -1.1211621931894917 != -1.122956 within 4 places

----------------------------------------------------------------------

I pulled out the test and ran it on my mac and linux boxes. The geometries and basis sets are identical. However, the iterations are different in a bizarre way. The (working) linux iterations have energies that look like:
-1.07240839848
-1.12183592844
-1.12295601995
-1.12295601796
Whereas the mac has energies
-1.07240839848
-1.12183592844
-1.12295601995
-1.12119876382
-1.12116211967
-1.12116219319
Which means the integrals work (since the first few energies are the same). Most likely place is some instability in the Ax=b solve in the DIIS routine, but I haven't found that yet. Will let everyone know if/when this is fixed.

------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev_______________________________________________ Pyquante-devel mailing list Pyq...@li...<mailto:Pyq...@li...> https://lists.sourceforge.net/lists/listinfo/pyquante-devel

[Pyquante-devel] Bug found in the test suite on MacOS

[Muller, R. <rm...@sa...>]

I'm getting a failure in the test suite on my mac laptop. Doesn’t fail on my linux box. Still trying to track this down.

The test321G test in the UnitSuite fails:

======================================================================
FAIL: test321G (__main__.UnitTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Tests/UnitSweet.py", line 121, in test321G
    self.assertAlmostEqual(solv.energy,-1.122956,4)
AssertionError: -1.1211621931894917 != -1.122956 within 4 places

----------------------------------------------------------------------

I pulled out the test and ran it on my mac and linux boxes. The geometries and basis sets are identical. However, the iterations are different in a bizarre way. The (working) linux iterations have energies that look like:
-1.07240839848
-1.12183592844
-1.12295601995
-1.12295601796
Whereas the mac has energies
-1.07240839848
-1.12183592844
-1.12295601995
-1.12119876382
-1.12116211967
-1.12116219319
Which means the integrals work (since the first few energies are the same). Most likely place is some instability in the Ax=b solve in the DIIS routine, but I haven't found that yet. Will let everyone know if/when this is fixed.

[Pyquante-devel] PyQuante 1.6.4 released

[Muller, R. <rm...@sa...>]

I released PyQuante v 1.6.4 a few minutes ago.

Rick

Re: [Pyquante-devel] Intended PyQuante changes before next point release

[Jussi L. <jus...@ik...>]

On Fri, 21 Jan 2011 06:50:57 -0700
"Muller, Richard" <rm...@sa...> wrote:
> I haven't made a PyQuante point release in a long while. I'm going to
> make one today, and then plan to make another minor point release
> shortly, then make a major release within a month or so. I wanted to
> make sure I had collected all of the requested changes people had
> sent me recently:

I'll add a few things to the wishlist (for the distant future):

- Extend the basis set definitions to handle shells of larger angular
  momentum. I would suggest doing this on-the-fly by using
  the libint-style algorithm

  for(int i=0; i<=am; i++) {
    int nx = am - i;
    for(int j=0; j<=i; j++) {
      int ny = i-j;
      int nz = j;

      add_function(nx,ny,nz);
     }
  }

- Obara-Saika evaluation of 1-electron integrals.
  I did this for my own code that is under development, it speeded up
  the evaluation by something like 25-30x. The most important bit are
  the nuclear attraction integrals: with big basis sets the THO routine
  is awfully slow. An OS routine will do it a *lot* faster.

- Implementation of a spherical harmonics basis.
  This is useful for basis sets with high angular momentum. The
  generation of the conversion matrices is a simple task (a couple of
  hundred lines of C++ code); one just has to convert the integrals to
  the spherical harmonics basis after they have been evaluated with
  cartesians. The memory requirements can be reduced by a significant
  amount, but the handicap is in the necessity of doing the 2-electron
  integral transforms.

- Direct formation of the Fock matrix
  I've done this in my own code that uses libint, however currently the
  implementation is a bit messy and a lot slower than using tabled
  integrals.
  Why is this important? For instance in an aug-cc-pVTZ calculation of
  the water dimer (184 basis functions) the ERIs take 1 G 158 M of
  memory. Going to aug-cc-pVQZ the memory requirement is already 14 G 85
  M. 

- Density fitting basis sets for pure DFT.
  This makes pure DFT calculations faster by at least an order of
  magnitude, since 2-electron integrals don't need to be calculated.
-- 
Jussi Lehtola
jus...@ik...

[Pyquante-devel] Intended PyQuante changes before next point release

[Muller, R. <rm...@sa...>]

I haven't made a PyQuante point release in a long while. I'm going to make one today, and then plan to make another minor point release shortly, then make a major release within a month or so. I wanted to make sure I had collected all of the requested changes people had sent me recently:

Changes before next minor point release:
* None: release svn code. Test on Linux and Mac.

Changes before subsequent minor point release:
* Create a Defaults.py module that keeps program-wide default
 information; make sure that defaults can always be overrided by
 kwargs, but also make sure that anytime kwargs gets a default
 response, it's from Defaults and not something hardwired.
* Redo the integral code:
 - Separate one_e ints from two_e ints
 - Two different flags (C vs Python, and which package) control ints
   now. 
 - Make the libint call analogous to the cint or crys calls. The
   branch point may have to be moved to an earlier point in the code. 
 - Kill the fact in pyints, using math.factorial instead
 - Address Jussi's integral question in pyints/cints
 - Two e integral test suite
 - Code should all work even if Cython not installed
 - C-code compile without error messages
* Implement Jussi's ccbasis functions

Changes before next major point release:
* GGA:
 - BLYP
 - Consistent testing with libxc
 - LSD
* Numerical Frequencies & Thermochemistry
* Rotion type ROHF (+ GVB?)
* MINDO cleaning:
 - Remove verbosity from MINDO routines
 - Unify (or subclass) MINDO3 atoms with normal atoms
 - Use atom.get_nel_mindo() in Mindo routines rather than 
   atom.Z
 - Use molecule.get_nel() rather than MINDO3.get_nel() in mindo

Re: [Pyquante-devel] Evaluation of ERIs

[Gabriele L. <gab...@gm...>]

Thank you very much for pointing this out! I'll check about the licence
headers (I'll ask you for clarifications if I don't get something).

- Gabriele

2010/12/2 Jussi Lehtola <jus...@ik...>

> Hi,
>
>
>
> first of all, when the libint backend is used, a *lot* of unnecessary
> memory is allocated. Please find attached a patch to fix this. I
> checked in valgrind using a small system (H2 cc-pVTZ) that the extra
> memory is not needed.
>
> Second, as libint is GPLv2+ licensed, the compiled libint module will
> also be under the GPL. The module source does not contain any license
> headers; maybe Gabriele would like to add them?
>
> Third, I've started meddling around with a code of my own that is
> supposed to integrate tightly with libint for HF and libxc for DFT.
> PyQuante has been loads of help in this, as the source is quite
> readable and I have something to cross-check with.
>
> As a first step, I have been implementing the integrals from the paper
> of Taketa, Huzinaga and O'ohata (THO) [H. Phys. Soc. Japan, 21, 2313,
> 1966]. I guess that the routines in cints.c have been checked to
> produce the correct results. However, when I look at the equation 2.22
> in THO, the exponent of \delta is
>  - i1 - i2 +    r1+r2  + u,
> not
>  - i1 - i2 + 2*(r1+r2) + u
> as in cints.c. Is there something I'm not seeing right..? Why do the
> powers differ?
>
> --
> Jussi Lehtola
> jus...@ik...
>
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> Pyquante-devel mailing list
> Pyq...@li...
> https://lists.sourceforge.net/lists/listinfo/pyquante-devel
>
>

Re: [Pyquante-devel] Evaluation of ERIs

[Jussi L. <jus...@ik...>]

On Thu, 2 Dec 2010 19:02:22 +0200
Jussi Lehtola <jus...@ik...> wrote:
> As a first step, I have been implementing the integrals from the paper
> of Taketa, Huzinaga and O'ohata (THO) [H. Phys. Soc. Japan, 21, 2313,
> 1966]. I guess that the routines in cints.c have been checked to
> produce the correct results. However, when I look at the equation 2.22
> in THO, the exponent of \delta is
>   - i1 - i2 +    r1+r2  + u,
> not
>   - i1 - i2 + 2*(r1+r2) + u
> as in cints.c. Is there something I'm not seeing right..? Why do the
> powers differ?
> 

Actually, I came across another discrepancy as well...

For the nuclear attraction integral, equation (2.18) contains
CPx^(i-2r-2u). CP is r_C - r_P, where the nucleus sits at r_c and r_P
is the center of the product Gaussian. The term is evaluated correctly
in the function A_term in cints.c.

However, the function is called (by A_array) with the argument
CPx=px-x3, where x3 is the nuclear coordinate.
-- 
Jussi Lehtola
jus...@ik...

[Pyquante-devel] Evaluation of ERIs

[Jussi L. <jus...@ik...>]

Hi,



first of all, when the libint backend is used, a *lot* of unnecessary
memory is allocated. Please find attached a patch to fix this. I
checked in valgrind using a small system (H2 cc-pVTZ) that the extra
memory is not needed.

Second, as libint is GPLv2+ licensed, the compiled libint module will
also be under the GPL. The module source does not contain any license
headers; maybe Gabriele would like to add them?

Third, I've started meddling around with a code of my own that is
supposed to integrate tightly with libint for HF and libxc for DFT.
PyQuante has been loads of help in this, as the source is quite
readable and I have something to cross-check with.

As a first step, I have been implementing the integrals from the paper
of Taketa, Huzinaga and O'ohata (THO) [H. Phys. Soc. Japan, 21, 2313,
1966]. I guess that the routines in cints.c have been checked to
produce the correct results. However, when I look at the equation 2.22
in THO, the exponent of \delta is
  - i1 - i2 +    r1+r2  + u,
not
  - i1 - i2 + 2*(r1+r2) + u
as in cints.c. Is there something I'm not seeing right..? Why do the
powers differ?

-- 
Jussi Lehtola
jus...@ik...

[Pyquante-devel] website/documentation

[Gabriele L. <gab...@gm...>]

Hi!
I've finally merged libint branch, the API is well-defined, if someone wants
to use/extend it don't exitate to contact me.

I want to move on other stuff (I wanted to do an Avogadro extension, but for
now Avogadro won't run on my machine for some obscure reasons).
One thing that I want to manage is a restructuring/design of the website, I
have some (little) experience in web design and developement and I would be
happy to mantain/update a website.

My ideas are:
1) design a logo :)
2) design and implement the website for introduction,links,news something
visually attractive.
3) maybe splitting the docs in more sections (and pages):
   - getting started
   - user guide
   - API documentation
   - cookbook (this maybe can be designed with some wiki features)

Want to hear opinions around this ideas.

Bye,

- Gabriele

Re: [Pyquante-devel] R: Re: Libint Integration

[Gabriele L. <gab...@gm...>]

Thank you very much for your kindness, I appreciate that! I have also to
thank you twice because I've yet took inspiration from your work on the
github pyquante branch... ;)

Bye,

- Gabriele

2010/5/3 Ondrej Certik <on...@ce...>

> On Sun, May 2, 2010 at 12:28 PM, Gabriele Lanaro
> <gab...@gm...> wrote:
> > Hi Jussi,
> >
> > I meant what you've just said (evei if I didn't explained me better),
> I'll
> > ship the .pyx + .c file, the .pyx to extend and the .c to build the
> > extensions.
> > In the svn tree I can effectively take off the .c files, and adding
> cython
> > as a "development" dependency, however since cython is needed only for my
> > extensions, shipping the .c files removes the dependency also for devs...
> > (for example Rick that haven't used it for his extensions).
> >
> > Thank you for commenting!
>
>
> Nice job, it's cool that you use Cython. I have quite a lot of
> experience with it, so if you get stuck or need any help, I'll do my
> best.
>
> Ondrej
>

Re: [Pyquante-devel] R: Re: Libint Integration

[Ondrej C. <on...@ce...>]

On Sun, May 2, 2010 at 12:28 PM, Gabriele Lanaro
<gab...@gm...> wrote:
> Hi Jussi,
>
> I meant what you've just said (evei if I didn't explained me better), I'll
> ship the .pyx + .c file, the .pyx to extend and the .c to build the
> extensions.
> In the svn tree I can effectively take off the .c files, and adding cython
> as a "development" dependency, however since cython is needed only for my
> extensions, shipping the .c files removes the dependency also for devs...
> (for example Rick that haven't used it for his extensions).
>
> Thank you for commenting!


Nice job, it's cool that you use Cython. I have quite a lot of
experience with it, so if you get stuck or need any help, I'll do my
best.

Ondrej