theochem / cgbasis Goto Github PK

The repository was renamed but many files inside the repo need to be updated consistently.

See theochem/horton#257 for details.

@tovrstra So we ran into this problem earlier but I never noticed it. The compile fails because the GCC version is too old I think. I'm actually not sure how it even managed to succeed in builds like this.

There's gcc 7.2.0 in the anaconda channel, but it looks like the compiler is only available on Linux. Libgcc (of various versions) is available on all systems though the anaconda channel. I think the reason they don't include the osx compiler is because they want them to use clang (which is also available in the anaconda channel).

So I guess we're out of options? We should be building our codes with modern C++ requirements on clang for osx and gcc for linux. I don't even know if libint/libxc build successfully in clang. Another possibility is that we use the gcc that's included in Travis, and include the anaconda libgcc for the corresponding version? That way we don't have to rebuild our entire toolchain... (technically though, everything we install from conda is already using clang to build, so we're actually doing something bad at the moment...)

In file included from gbasis/gbasis.h:26:0,
from gbasis/cext.cpp:460:
gbasis/ints.h:26:10: fatal error: libint2.h: No such file or directory
#include "libint2.h"

No major API changes. Lots of small cleanups. Docstrings may still be out of date.

The check_delta function used in the unit tests is not great. We should use https://github.com/theochem/derivcheck instead.

@tovrstra Have you seen this error before?

Current tag is: 0.1.0
/home/travis/.rvm/gems/ruby-2.2.7/gems/octokit-4.6.2/lib/octokit/response/raise_error.rb:16:in `on_complete': POST https://api.github.com/repos/theochem/gbasis/releases: 404 - Not Found // See: https://developer.github.com/v3 (Octokit::NotFound)

The builds are failing. I'm pretty sure it's not an issue with the keys...

Conda seems to build on 3.7 even on a 3.6 host. Needs more investigation...

The C++ part is a bit beefier than it needs to be right now, especially if we transition to using PySCF for vanilla integrals and only want to keep GBasis for the exotic integrals. It's a little difficult to make modifications to the code right now because of it.

There are two parts I think we can simplify: the one-electron integrals, and the two-electron integrals.

For the 1e ints, we can probably replace the C++ implementation entirely with Python (and little snippets of Cython). I think this shouldn't be too much slower.

For 2e ints, one way we might be able to decrease the C++ load is to only use C++ to ask libint for integrals of specific shells, 4 shells (ie <ss|ss>) at a time. It would effectively be replacing the gbw code with Python and using it for generating the integrals, and also perform the cart_to_pure in Python. It won't save us from having to write code to interface with libint when we want new kernels, but at least it we won't have to dig through that much C++ to do it. Also we could (finally) switch over to the standard sub-shell ordering everyone else is using with less C++ hacking.

An added benefit of writing code this way is that we can ask for integrals 1 set of shells at a time. This is useful for direct-SCF/CI algorithms and makes our memory issues largely moot (there still is probably some use for Cholesky/DF etc).

One (fairly obvious?) thing to note about asking libint for specific sets of shells: We should probably initialize the libint C++ object only once when the python class is instantiated. The initialization costs of C++ would be too heavy otherwise.

Another possibility to simplify the 2e integrals might be to look into the new libint C++11 interface. The documentation says you should be able to implement new operators/kernels, but I haven't seen any code yet...

The iterators in https://github.com/theochem/gbasis/blob/master/gbasis/iter_gb.h do not allow for much flexibility when one is interested in only a part of an array. A simple approach to computing only a part of an array would be useful for the Cholesky code and for parallelization with packages like dask.

Setup on "macOS High Sierra" using conda environments:
Python=3.64 and 2.7.14
Cython=0.27.3
Numpy=1.14.0

Trying ./setup.py build_ext -i, you get:

Traceback (most recent call last):
  File "./setup.py", line 31, in <module>
    version=get_version(),
  File "./setup.py", line 15, in get_version
    with open('gbasis/version.py', 'r') as f:
FileNotFoundError: [Errno 2] No such file or directory: 'gbasis/version.py'

I added gbasis.version.py by hand, and then you get:

/Users/farnaz.heidarzadeh/anaconda3/lib/python3.6/site-packages/setuptools/dist.py:364: UserWarning: The version specified ('"0.1.0"') is an invalid version, this may not work as expected with newer versions of setuptools, pip, and PyPI. Please see PEP 440 for more details.
  "details." % self.metadata.version
running build_ext
cythoning gbasis/cext.pyx to gbasis/cext.cpp
building 'gbasis.cext' extension
creating build
creating build/temp.macosx-10.7-x86_64-3.6
creating build/temp.macosx-10.7-x86_64-3.6/gbasis
gcc -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Users/farnaz.heidarzadeh/anaconda3/include -arch x86_64 -I/Users/farnaz.heidarzadeh/anaconda3/include -arch x86_64 -I/Users/farnaz.heidarzadeh/anaconda3/lib/python3.6/site-packages/numpy/core/include -I/Users/farnaz.heidarzadeh/anaconda3/include/python3.6m -c gbasis/cext.cpp -o build/temp.macosx-10.7-x86_64-3.6/gbasis/cext.o
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++ [enabled by default]
In file included from /Users/farnaz.heidarzadeh/anaconda3/lib/python3.6/site-packages/numpy/core/include/numpy/ndarraytypes.h:1816:0,
                 from /Users/farnaz.heidarzadeh/anaconda3/lib/python3.6/site-packages/numpy/core/include/numpy/ndarrayobject.h:18,
                 from /Users/farnaz.heidarzadeh/anaconda3/lib/python3.6/site-packages/numpy/core/include/numpy/arrayobject.h:4,
                 from gbasis/cext.cpp:539:
/Users/farnaz.heidarzadeh/anaconda3/lib/python3.6/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:15:2: warning: #warning "Using deprecated NumPy API, disable it by " "#defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]
 #warning "Using deprecated NumPy API, disable it by " \
  ^
In file included from gbasis/gbasis.h:26:0,
                 from gbasis/cext.cpp:550:
gbasis/ints.h:26:21: fatal error: libint2.h: No such file or directory
 #include "libint2.h"
                     ^
compilation terminated.
error: command 'gcc' failed with exit status 1

We should first get rid of some big data files before tackling this. See #6

Currently the data used in the tests are spread over three places:

• directories with npz files in gbasis/test/data
• gbasis/test/gobasis_data.py
• gbasis/test/mol_data.py

The latter two can be put in these directories as well. It would also be cleaner and simpler to have just one function to load data, rather than different ones.

We should port over a basic website, extracting parts from the old HORTON website where needed.

• Machinery to build Gaussian basis from molecule and basis set string will move to theochem/gbasis
• Remove all integrals routines
• Move remaining grid compute functions outside of the class, make them free functions.

We should make it possible to use different backends to compute certain integrals, e.g. LibInt and libcint

This is the issue with all the detail: theochem/horton#87 The main conclusion is that the ordering of the pure functions (D and up) needs to be changed to be consistent with PySCF, Psi4 and NWChem. See e.g. https://en.wikipedia.org/wiki/Table_of_spherical_harmonics#Real_spherical_harmonics.

Related to theochem/iodata#2 MolSSI/QCSchema#12

Instead of summing of the diagonal elements of Hessian matrix at a given point, it's better to directly compute the laplacian. Any thoughts?

Some of our unit tests are grossly inefficient: they use large data files and errors in higher angular momenta may still go undetected because they can be lower than the thresholds for lower angular momenta. For example: https://github.com/theochem/gbasis/blob/master/gbasis/test/test_fns.py#L508

Instead, it would be better to run such tests with single-shell basis sets, and loop over all possible combinations of angular momenta. When needed, pseudo-random density matrices can be used in the test.

This is very cumbersome with the current API, see e.g.

https://github.com/theochem/gbasis/blob/master/gbasis/gobasis.py#L412

Hi guys. I'm trying to use gbasis within the density matrix code. I ran into a type conversion error. Any suggestions on how I can fix it? Does it have anything to do with the version of numpy I am using (currently 1.14.3)? Please find my output below. The code itself is on the quantum elephant repo (densitymatrices).

(var2dm) ❯ nosetests -v var2DM
test_misc.test_prep_electron_int ... /home/jenefre/miniconda3/envs/var2dm/lib/python3.6/site-packages/gbasis/utils.py:76: FutureWarning: Conversion of the second argument of issubdtype from `float` to `np.floating` is deprecated. In future, it will be treated as `np.float64 == np.dtype(float).type`.
  if coordinates.shape != (natom, 3) or not np.issubdtype(coordinates.dtype, np.float):
ERROR

======================================================================
ERROR: test_misc.test_prep_electron_int
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/jenefre/miniconda3/envs/var2dm/lib/python3.6/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/home/jenefre/Documents/githubcode/densitymatrices/var2DM/test/test_misc.py", line 12, in test_prep_electron_int
    mol.pseudo_numbers, '3-21G')
  File "/home/jenefre/Documents/githubcode/densitymatrices/var2DM/misc.py", line 73, in prep_electron_int
    na = obasis.compute_nuclear_attraction(coords, nums, chrgs)
  File "gbasis/cext.pyx", line 693, in gbasis.cext.GOBasis.compute_nuclear_attraction
ValueError: Buffer dtype mismatch, expected 'double' but got 'long'

----------------------------------------------------------------------
Ran 1 test in 0.026s

FAILED (errors=1)

We should just disable the cache when making a release. It's on a new branch so it'll get packed. The master cache is really the only one we're interested in...

At the moment, all arrays with integrals are the result of a call to a method of the GOBasis class. However, there are situations where different indexes of one array should be related to different basis sets. For example:

• 2-, 3- and 4-index overlap operators, for projection purposes @kimt33
• 3-index coulomb integrals for density fitting @matt-chan

gbasis/fns.h:273:67: error: expected member name or ';' after declaration specifiers
: GB1ExpGridFn(max_shell_type, nfn, 1, norb), poly_work{0.0}, offset(0),
^
gbasis/fns.h:273:62: error: expected '('
: GB1ExpGridFn(max_shell_type, nfn, 1, norb), poly_work{0.0}, offset(0),
^
gbasis/fns.h:273:66: error: expected ';' after expression
: GB1ExpGridFn(max_shell_type, nfn, 1, norb), poly_work{0.0}, offset(0),
^
;
gbasis/fns.h:273:63: warning: expression result unused [-Wunused-value]
: GB1ExpGridFn(max_shell_type, nfn, 1, norb), poly_work{0.0}, offset(0),
^~~
gbasis/fns.h:326:71: error: expected member name or ';' after declaration specifiers
: GB1ExpGridFn(max_shell_type, nfn, 3, norb * 3), poly_work{0.0}, offset(0),
^
gbasis/fns.h:326:66: error: expected '('
: GB1ExpGridFn(max_shell_type, nfn, 3, norb * 3), poly_work{0.0}, offset(0),
^
gbasis/fns.h:326:70: error: expected ';' after expression
: GB1ExpGridFn(max_shell_type, nfn, 3, norb * 3), poly_work{0.0}, offset(0),
^
;
gbasis/fns.h:326:67: warning: expression result unused [-Wunused-value]
: GB1ExpGridFn(max_shell_type, nfn, 3, norb * 3), poly_work{0.0}, offset(0),
^~~
gbasis/fns.h:429:58: error: expected member name or ';' after declaration specifiers
: GB1DMGridFn(max_shell_type, 1, 1), poly_work{0.0}, offset(0) {}
^
gbasis/fns.h:429:53: error: expected '('
: GB1DMGridFn(max_shell_type, 1, 1), poly_work{0.0}, offset(0) {}
^
gbasis/fns.h:429:57: error: expected ';' after expression
: GB1DMGridFn(max_shell_type, 1, 1), poly_work{0.0}, offset(0) {}
^
;
gbasis/fns.h:429:54: warning: expression result unused [-Wunused-value]
: GB1DMGridFn(max_shell_type, 1, 1), poly_work{0.0}, offset(0) {}
^~~
gbasis/fns.h:475:58: error: expected member name or ';' after declaration specifiers
: GB1DMGridFn(max_shell_type, 4, 3), poly_work{0.0}, offset(0),
^
gbasis/fns.h:475:53: error: expected '('
: GB1DMGridFn(max_shell_type, 4, 3), poly_work{0.0}, offset(0),
^
gbasis/fns.h:475:57: error: expected ';' after expression
: GB1DMGridFn(max_shell_type, 4, 3), poly_work{0.0}, offset(0),
^
;
gbasis/fns.h:475:54: warning: expression result unused [-Wunused-value]
: GB1DMGridFn(max_shell_type, 4, 3), poly_work{0.0}, offset(0),
^~~
gbasis/fns.h:538:50: error: no matching constructor for initialization of 'GB1DMGridGradientFn'
explicit GB1DMGridGGAFn(long max_shell_type) : GB1DMGridGradientFn(max_shell_type, 4) {}
^ ~~~~~~~~~~~~~~~~~
gbasis/fns.h:474:12: note: candidate constructor not viable: requires single argument 'max_shell_type', but 2 arguments were provided
explicit GB1DMGridGradientFn(long max_shell_type)
^
gbasis/fns.h:466:7: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 2 were provided
class GB1DMGridGradientFn : public GB1DMGridFn {
^
gbasis/fns.h:568:58: error: expected member name or ';' after declaration specifiers
: GB1DMGridFn(max_shell_type, 3, 1), poly_work{0.0}, offset(0), offset_l1(0),
^
gbasis/fns.h:568:53: error: expected '('
: GB1DMGridFn(max_shell_type, 3, 1), poly_work{0.0}, offset(0), offset_l1(0),
^
gbasis/fns.h:568:57: error: expected ';' after expression
: GB1DMGridFn(max_shell_type, 3, 1), poly_work{0.0}, offset(0), offset_l1(0),
^
;
gbasis/fns.h:568:54: warning: expression result unused [-Wunused-value]
: GB1DMGridFn(max_shell_type, 3, 1), poly_work{0.0}, offset(0), offset_l1(0),
^~~
gbasis/fns.h:626:59: error: expected member name or ';' after declaration specifiers
: GB1DMGridFn(max_shell_type, 10, 6), poly_work{0.0}, offset(0),
^
gbasis/fns.h:626:54: error: expected '('
: GB1DMGridFn(max_shell_type, 10, 6), poly_work{0.0}, offset(0),
^
gbasis/fns.h:626:58: error: expected ';' after expression
: GB1DMGridFn(max_shell_type, 10, 6), poly_work{0.0}, offset(0),
^
;
gbasis/fns.h:626:55: warning: expression result unused [-Wunused-value]
: GB1DMGridFn(max_shell_type, 10, 6), poly_work{0.0}, offset(0),
^~~
fatal error: too many errors emitted, stopping now [-ferror-limit=]
8 warnings and 20 errors generated.
error: command 'clang' failed with exit status 1

clang --version
Apple LLVM version 8.1.0 (clang-802.0.42)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

The unit tests for c++ are run through Cython right now. In addition, Python numpy arrays are used to store the reference data, but we should store in a binary format (Eigen compatible?) and move the tests into GTests.

I referenced this in #33 and I think @tovrstra mentioned this even as far back as #4 (!), but it would be nice to compute integrals by sets of shells for things like direct-SCF/CI.

Stijn has also requested by index. I think this should be possible with some Python glue (we'd still compute by shell, but throw away the ones which weren't requested).

Stijn has suggested we add access to properties of the basis functions (ie exponent, center, normalization, angular momentum(?), etc) by index. So for example, the properties of the [5,2] element of the overlap matrix. Right now, you can infer what they are if you know how the subshell, the basis ordering, and the attributes of GBasis are implemented. It's a lot of internal algorithmic knowledge that I also think we shouldn't be expecting casual users to know.

This should be implemented as python utils I think. It should be fairly easy to do as well, possibly a good intro project into GBasis.

I'm thinking of splitting GOBasis into 4 Cython parts. 1-body terms, 2-body terms, grid functions, and testing wrappers.

It should be possible to keep the Python interface using a wrapper class. It would have the benefit of vastly simplifying the cext.pyx file and also ints.cpp, etc. Right now we have 5000 line monstrosities which are really painful to build and work with. Also, it would mean we could put each part into its own directory.

I'm not sure if it's worth the time investment though. New users would definitely appreciate it....