dgasmith / gau2grid Goto Github PK

View Code? Open in Web Editor NEW

28.0 28.0 12.0 929 KB

Fast computation of a gaussian and its derivative on a grid.

Home Page: https://gau2grid.readthedocs.io/en/latest/

License: BSD 3-Clause "New" or "Revised" License

Python 88.39% CMake 11.29% Shell 0.32%

c collocations grid numpy python

gau2grid's People

Contributors

Stargazers

Watchers

Forkers

loriab raimis wavefunction91 hokru eclipseo hjjvandam andysim susilehtola ilfreddy evaleev amandadumi yansonggu

gau2grid's Issues

Update Build Cartesian Orders

As @loriab pointed out the molden order is not hooked up to build.

The following lines (at least) need to be fixed:
https://github.com/dgasmith/gau2grid/blob/master/CMakeLists.txt#L17, https://github.com/dgasmith/gau2grid/blob/master/CMakeLists.txt#L33, https://github.com/dgasmith/gau2grid/blob/master/cmake/gau2gridConfig.cmake.in#L50-L54, https://github.com/dgasmith/gau2grid/blob/master/cmake/gau2gridConfig.cmake.in#L17-L18

Build issues macOS + gcc-8.0 (Also #42)

This is reproducible.

cmake -H. -Bbuild -DCMAKE_C_COMPILER=gcc-8 -DCMAKE_CXX_COMPILER=g++-8 -DCMAKE_Fortran_COMPILER=gfortran-8

Homebrew installed gcc-8

Components of NWChemEx cannot compile properly with clang, hence we are using gcc on a Mac right now. Not clear where it goes wrong. Most likely the path to the include file is not found?

Bert

Originally posted by @wadejong in #42 (comment)

Add soversion to gau2grid library

I need to get this packaged in Fedora so that I can finally update psi4 to the 1.2 series.

However, gau2grid doesn't have an soname, which should be added.
https://fedoraproject.org/wiki/Packaging:Guidelines#Downstream_.so_name_versioning

Remove mpmath

Make mpmath an optional dependency only if one wishes to extend the maximum angular momentum. Accomplish this by pre-compiling and serializing up to AM=16 so that this maximum is not often hit.

Windows-ported version

Would it be possible to tag 757e615, so in psi4/psi4#1124 I could refer to a tag rather than a hash.

fast_transpose slower than naive_transpose

I've been running various DFT calculations with PSI4 inside Intel's VTune and gg_fast_transpose popped up a top hotspot As as test I exchanged it to gg_naive_transpose and saw a significant speed up (50% for a C60 test) for that function.

It's only 4-5% of the total CPU time for single-points, so no real bottleneck to worry about, but wondering why the blocked-transpose might be so much slower.

[regression in 1.3.1] Fails for python-2.7

-- Found Python 2.7: /usr/local/bin/python2.7 (found version 2.7.15)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
AttributeError: 'module' object has no attribute 'commonpath'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
AttributeError: 'module' object has no attribute 'commonpath'
CMake Error at CMakeLists.txt:163 (install):
  install DIRECTORY given no DESTINATION!


-- Configuring incomplete, errors occurred!
See also "/usr/ports/math/py-gau2grid/work-py27/gau2grid-1.3.1/build/temp.freebsd-11.2-STABLE-amd64-2.7/CMakeFiles/CMakeOutput.log".
See also "/usr/ports/math/py-gau2grid/work-py27/gau2grid-1.3.1/build/temp.freebsd-11.2-STABLE-amd64-2.7/CMakeFiles/CMakeError.log".
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "setup.py", line 147, in <module>
    zip_safe=False,
  File "/usr/local/lib/python2.7/site-packages/setuptools/__init__.py", line 143, in setup
    return distutils.core.setup(**attrs)
  File "/usr/local/lib/python2.7/distutils/core.py", line 151, in setup
    dist.run_commands()
  File "/usr/local/lib/python2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/usr/local/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/usr/local/lib/python2.7/distutils/command/build.py", line 127, in run
    self.run_command(cmd_name)
  File "/usr/local/lib/python2.7/distutils/cmd.py", line 326, in run_command
    self.distribution.run_command(command)
  File "/usr/local/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "setup.py", line 33, in run
    self.build_extension(ext)
  File "setup.py", line 56, in build_extension
    subprocess.check_call(['cmake', ext.sourcedir] + internal_cmake_args, cwd=self.build_temp, env=env)
  File "/usr/local/lib/python2.7/subprocess.py", line 190, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmake', '/usr/ports/math/py-gau2grid/work-py27/gau2grid-1.3.1', '-DPYTHON_EXECUTABLE=/usr/local/bin/python2.7', '-DSPHERICAL_ORDER=gaussian', '-DINSTALL_PYMOD=ON', '-DENABLE_XHOST=ON', '-DBUILD_FPIC=ON', '-DBUILD_SHARED_LIBS=ON', '-DMAX_AM=6', '-DENABLE_GENERIC=OFF', '-DCARTESIAN_ORDER=row', '-DCMAKE_BUILD_TYPE=Release', '-DNATIVE_PYTHON_INSTALL=ON', '-DCMAKE_BUILD_TYPE=Release']' returned non-zero exit status 1
*** Error code 1

Worked fine in version 1.3.0

FreeBSD 11.2 amd64

gau2grid not working on any other architectures than x86_64

gau2grid has been approved in Fedora, but the builds fail on every other architecture than x86_64.

https://koji.fedoraproject.org/koji/taskinfo?taskID=29866555

It appears there are at least two separate issues in the code.

First, on i686 and armv7hl I get

[ 14%] Generating gau2grid.h, gau2grid_phi.c, gau2grid_deriv1.c, gau2grid_deriv2.c, gau2grid_spherical.c, gau2grid_helper.c
/usr/bin/python3.7 -c "import sys;                                      sys.path.append('/builddir/build/BUILD/gau2grid-1.2.0');                                      import gau2grid as gg;                                      gg.c_gen.generate_c_gau2grid(8, path='/builddir/build/BUILD/gau2grid-1.2.0/objdir', cartesian_order='row', spherical_order='gaussian')"
Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/numpy/lib/format.py", line 527, in _read_array_header
    dtype = numpy.dtype(d['descr'])
TypeError: data type "<f16" not understood
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/builddir/build/BUILD/gau2grid-1.2.0/gau2grid/__init__.py", line 5, in <module>
    from . import RSH
  File "/builddir/build/BUILD/gau2grid-1.2.0/gau2grid/RSH.py", line 43, in <module>
    _load_saved_rsh_coefs()
  File "/builddir/build/BUILD/gau2grid-1.2.0/gau2grid/RSH.py", line 29, in _load_saved_rsh_coefs
    coefs = rsh_data[key_name + "coeffs"]
  File "/usr/lib/python3.7/site-packages/numpy/lib/npyio.py", line 251, in __getitem__
    pickle_kwargs=self.pickle_kwargs)
  File "/usr/lib/python3.7/site-packages/numpy/lib/format.py", line 642, in read_array
    shape, fortran_order, dtype = _read_array_header(fp, version)
  File "/usr/lib/python3.7/site-packages/numpy/lib/format.py", line 530, in _read_array_header
    raise ValueError(msg % (d['descr'],))
ValueError: descr is not a valid dtype descriptor: '<f16'

Second, on ppc64le, aarch64 and s390x I get

[ 28%] Building C object CMakeFiles/gg.dir/gau2grid_phi.c.o
/usr/bin/cc -Dgg_EXPORTS  -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection -DNDEBUG -fPIC   -std=c99 -o CMakeFiles/gg.dir/gau2grid_phi.c.o   -c /builddir/build/BUILD/gau2grid-1.2.0/objdir/gau2grid_phi.c
/builddir/build/BUILD/gau2grid-1.2.0/objdir/gau2grid_phi.c:13:10: fatal error: mm_malloc.h: No such file or directory
 #include <mm_malloc.h>
          ^~~~~~~~~~~~~
compilation terminated.

Function and header prefixes

It would be useful to be able to compile multiple versions of gau2grid with different ordering paths. This would require prefixes on all functions and headers.

More generic C interface

Note: this is not a bug, just a suggestion for an improvement.

Would it be possible to generate a more generic C interface viz the specification style for Cartesian points into the drivers? Currently, the specification dictates that the Cartesian points be specified as 3 unit-stride arrays of length "N". Specifically what I'm looking for is one of the following

A specification which allows a single unit stride array of length 3*N which contains the cartesian points contiguously
A more flexible specification which allows the user to specify the stride of the X,Y,Z arrays, e.g. the X array could be length N with stride 3.

Allow for CCA ordering of solid harmonic Gaussians

Currently, the only option for spherical Gaussians is to be returned in the Gaussian ordering
[0, -1, +1, -2, +2, ..., -L, +L]

CCA dictates the order
[-L, -L+1, -L+2, ..., 0, L+1, L+2, ... L]

Both orderings are common place in KS codes, thus this would be a useful option to set at configuration

Tagged version doesn't match CMake project version

Tagged version doesn't match CMake project version:

gau2grid/CMakeLists.txt

Line 4 in 757e615

VERSION 1.1.0

As a result, Psi4 configuration fails: https://travis-ci.org/psi4/psi4/jobs/412702471

[regression in 1.3.1] Python module installer attempts to create a directory outside of the stage directory

CMake Error at cmake_install.cmake:36 (file):
  file INSTALL cannot make directory
  "/usr/local/lib/python3.6/site-packages/gau2grid": Permission denied

1.3.0 worked fine.

FreeBSD 11.2 amd64

coefficients for individual spherical harmonic components

Right now, for L>0 basis functions, the code only allows a single coefficient. I would like to individually specify coefficients for each component of a L>0 function. For instance, I would like to specify a coefficient c_x for p_x, but a different c_y for p_y and so on. I hope this makes sense.

I have a workaround right now, but it does not work with the collocation_basis function, which would be much cleaner and faster. I'm hoping that adding this shouldn't be too difficult.

Build problems with macOS + gcc

When trying to build gau2grid with gcc 8.2.0 on macOS, I get a
lot of the following warnings

/tmp/gau2grid/build/gau2grid_deriv2.c: In function 'gg_collocation_L8_deriv2':
/tmp/gau2grid/build/gau2grid_pragma.h:35:62: warning: incompatible implicit declaration of built-in function 'aligned_alloc'
     #define ALIGNED_MALLOC(alignment, size)                  aligned_alloc(alignment, size)
                                                              ^~~~~~~~~~~~~
/tmp/gau2grid/build/gau2grid_deriv2.c:5637:51: note: in expansion of macro 'ALIGNED_MALLOC'
     double* PRAGMA_RESTRICT cache_data = (double*)ALIGNED_MALLOC(64, 256 * sizeof(double));
                                                   ^~~~~~~~~~~~~~
/tmp/gau2grid/build/gau2grid_pragma.h:35:62: note: include '<stdlib.h>' or provide a declaration of 'aligned_alloc'
     #define ALIGNED_MALLOC(alignment, size)                  aligned_alloc(alignment, size)

finally resulting in a linker error:

Undefined symbols for architecture x86_64:
  "_aligned_alloc", referenced from:
      _gg_collocation_L0 in gau2grid_phi.c.o
      _gg_collocation_L1 in gau2grid_phi.c.o
      _gg_collocation_L2 in gau2grid_phi.c.o
      _gg_collocation_L3 in gau2grid_phi.c.o
      _gg_collocation_L4 in gau2grid_phi.c.o
      _gg_collocation_L5 in gau2grid_phi.c.o
      _gg_collocation_L6 in gau2grid_phi.c.o
      ...
ld: symbol(s) not found for architecture x86_64

I tried to include <stdlib.h> in the respective file, but it did not seem to work.
Any ideas on this issue?

Add pregenerated C code for release / distribution

[...Extending an offline discussion...]

Currently, the build requires numpy to generate the C interface. Since there''s not currently any arch deduction (mu-arch, cache sizes, etc) in the CMake build and all optimizations are handled by #pragma simd etc, it should be possible to distribute pregenerated C source source code to avoid the generation step for each release. I'm kind of envisioning something that resembles the release structure generated by Libint where the "compiler" (code generation) and exported libs are separate

Crash in scf-property psi4 test when using 2.0 gau2grid with psi4 originally built against 1.3.x

I got a bug report from the automatic testing infrastructure about psi4 and gau2grid, see
https://ci.debian.net/data/autopkgtest/testing/amd64/p/psi4/3146850/log.gz

It seems psi4 crashed in libgg if it was originally built against 1.3.1 but is now dynamically linked to 2.0. This is possible as the SONAME did not change and might hint at the fact that it should have been changed?

Here is the backtrace:

	Nuclear repulsion energy..........................................PASSED
	SCF energy........................................................PASSED
	SCF DIPOLE X......................................................PASSED
	SCF DIPOLE Y......................................................PASSED
	SCF DIPOLE Z......................................................PASSED
	SCF QUADRUPOLE XX.................................................PASSED
	SCF QUADRUPOLE YY.................................................PASSED
	SCF QUADRUPOLE ZZ.................................................PASSED
	SCF QUADRUPOLE XY.................................................PASSED
	SCF QUADRUPOLE XZ.................................................PASSED
	SCF QUADRUPOLE YZ.................................................PASSED

Program received signal SIGSEGV, Segmentation fault.
gg_collocation_L0_deriv1 (npoints=npoints@entry=63, xyz=0x1c15630, xyz_stride=29971088, nprim=30494448, coeffs=0x1, exponents=0x1279180, center=0xee0ec0, order=14698288, phi_out=0x0, phi_x_out=0x1b171a0, 
    phi_y_out=0x1b62200, phi_z_out=0x1b6ea10) at ./obj-x86_64-linux-gnu/gau2grid_deriv1.c:80
80	./obj-x86_64-linux-gnu/gau2grid_deriv1.c: No such file or directory.
(gdb) bt
#0  gg_collocation_L0_deriv1 (npoints=npoints@entry=63, xyz=0x1c15630, xyz_stride=29971088, nprim=30494448, coeffs=0x1, exponents=0x1279180, center=0xee0ec0, order=14698288, phi_out=0x0, phi_x_out=0x1b171a0, 
    phi_y_out=0x1b62200, phi_z_out=0x1b6ea10) at ./obj-x86_64-linux-gnu/gau2grid_deriv1.c:80
#1  0x00007ffff59447c0 in gg_collocation_deriv1 (L=L@entry=0, npoints=npoints@entry=63, xyz=xyz@entry=0x1c15630, xyz_stride=xyz_stride@entry=29971088, nprim=nprim@entry=30494448, coeffs=<optimized out>, 
    exponents=<optimized out>, center=<optimized out>, order=<optimized out>, phi_out=<optimized out>, phi_x_out=<optimized out>, phi_y_out=<optimized out>, phi_z_out=0x1b6ea10)
    at ./obj-x86_64-linux-gnu/gau2grid_helper.c:86
#2  0x00007ffff6f2ab7b in psi::BasisFunctions::compute_functions (this=0x1a76f10, block=...) at /build/psi4-3cv7JI/psi4-1.2.1/psi4/src/psi4/libfock/points.cc:705
#3  0x00007ffff6f2cf90 in psi::UKSFunctions::compute_points (this=this@entry=0x1a76f10, block=std::shared_ptr<class psi::BlockOPoints> (use count 4, weak count 0) = {...})
    at /usr/include/c++/8/ext/atomicity.h:96
#4  0x00007ffff6f6cd0d in psi::UV::compute_V (this=0x12dd250, ret=std::vector of length 2, capacity 2 = {...}) at /usr/include/c++/8/bits/shared_ptr.h:129
#5  0x00007ffff6e882ae in psi::scf::UHF::form_V (this=0x1463560) at /usr/include/c++/8/ext/atomicity.h:98
#6  0x00007ffff6e8d657 in psi::scf::UHF::form_G (this=0x1463560) at /build/psi4-3cv7JI/psi4-1.2.1/psi4/src/psi4/libscf_solver/uhf.cc:181
#7  0x00007ffff6e5b016 in psi::scf::HF::iterations (this=0x1463560) at /build/psi4-3cv7JI/psi4-1.2.1/psi4/src/psi4/libscf_solver/hf.cc:1645
#8  0x00007ffff6e50a09 in psi::scf::HF::compute_energy (this=0x1463560) at /build/psi4-3cv7JI/psi4-1.2.1/psi4/src/psi4/libscf_solver/hf.cc:490
#9  0x00007ffff635a75e in pybind11::cpp_function::cpp_function<double, psi::Wavefunction, , pybind11::name, pybind11::is_method, pybind11::sibling, char [41]>(double (psi::Wavefunction::*)(), pybind11::name const&, pybind11::is_method const&, pybind11::sibling const&, char const (&) [41])::{lambda(psi::Wavefunction*)#1}::operator()(psi::Wavefunction*) const (this=<optimized out>, this=<optimized out>, 
    c=<optimized out>) at /usr/include/pybind11/pybind11.h:72

The last lines in output.dat are:

  ==> DiskJK: Disk-Based J/K Matrices <==

    J tasked:                  Yes
    K tasked:                  Yes
    wK tasked:                  No
    Memory (MB):               375
    Schwarz Cutoff:          1E-12

    OpenMP threads:              1

  Minimum eigenvalue in the overlap matrix is 2.6982852745E-02.
  Using Symmetric Orthogonalization.

  SCF Guess: Generalized Wolfsberg-Helmholtz.

  ==> Iterations <==

                        Total Energy        Delta E     RMS |[F,P]|

This is with gau2grid 2.0.1, I just saw that 2.0.3 got released and I am going to upload it to Debian right now, but I assume chances are slim that it would be fixed by that?

python install does not copy data directory

Using python setup.py install (miniconda python) the data directory is missing and needs to be copied manually to the correct location.

Allow for inclusion as a CMake Subproject

Ideally, gau2grid could be included in a downstream CMake project as

FetchContent_Declare( gau2grid GIT_REPOSITORY https://github.com/dgasmith/gau2grid.git )
FetchContent_MakeAvailable( gau2grid )

target_link_libraries( my_target PUBLIC gg )

This populates directories ${CMAKE_BINARY_DIR}/_deps/gau2grid-src, etc. The generator on line 58 assumes that CMAKE_SOURCE_DIR and PROJECT_SOURCE_DIR are the same, which is not the case through FetchContent. Making this generator point explicitly to PROJECT_SOURCE_DIR fixes the problem.

A (albeit hacky) workaround of this is the following

  FetchContent_Declare(                                                               
    gau2grid
    GIT_REPOSITORY https://github.com/dgasmith/gau2grid.git                           
  )                                                                                   
  
  FetchContent_GetProperties( gau2grid )                                              
  if( NOT gau2grid_POPULATED )
    FetchContent_Populate( gau2grid )
    file( READ ${gau2grid_SOURCE_DIR}/CMakeLists.txt GAU2GRID_CMAKE_LISTS )
    string( REPLACE "CMAKE_SOURCE_DIR" "PROJECT_SOURCE_DIR" GAU2GRID_CORRECT "${GAU2GRID_CMAKE_LISTS}" )
    file( WRITE ${gau2grid_SOURCE_DIR}/CMakeLists.txt "${GAU2GRID_CORRECT}" )         
    add_subdirectory( ${gau2grid_SOURCE_DIR} ${gau2grid_BINARY_DIR} )                 
  endif()

gau2grid/libgg.so.1 is missing from the plist

The --record plist python feature fails to add this file to the plist.

===> Checking for items in STAGEDIR missing from pkg-plist
Error: Orphaned: %%PYTHON_SITELIBDIR%%/gau2grid/libgg.so.1
===> Checking for items in pkg-plist which are not in STAGEDIR
===> Error: Plist issues found.
*** Error code 1

Build fails: cmake failure

Version 1.3.0 fails:

[ 12%] Generating gau2grid.h, gau2grid_orbital.c, gau2grid_phi.c, gau2grid_deriv1.c, gau2grid_deriv2.c, gau2grid_spherical.c, gau2grid_helper.c
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/ports/math/py-gau2grid/work-py36/gau2grid-1.3.0/gau2grid/c_generator.py", line 151, in generate_c_gau2grid
    sig = RSH.transformation_c_generator(gg_spherical, L, cartesian_order, spherical_order, align=ALIGN_SIZE)
  File "/usr/ports/math/py-gau2grid/work-py36/gau2grid-1.3.0/gau2grid/RSH.py", line 268, in transformation_c_generator
    RSH_coefs = cart_to_RSH_coeffs(L, order=spherical_order)
  File "/usr/ports/math/py-gau2grid/work-py36/gau2grid-1.3.0/gau2grid/RSH.py", line 177, in cart_to_RSH_coeffs
    data = _saved_rsh_coefs[L]
KeyError: 0
gmake[3]: *** [CMakeFiles/gg.dir/build.make:62: gau2grid.h] Error 1
gmake[3]: Leaving directory '/usr/ports/math/py-gau2grid/work-py36/gau2grid-1.3.0/build/temp.freebsd-11.2-STABLE-amd64-3.6'
gmake[2]: *** [CMakeFiles/Makefile2:72: CMakeFiles/gg.dir/all] Error 2
gmake[2]: Leaving directory '/usr/ports/math/py-gau2grid/work-py36/gau2grid-1.3.0/build/temp.freebsd-11.2-STABLE-amd64-3.6'
gmake[1]: *** [Makefile:130: all] Error 2
gmake[1]: Leaving directory '/usr/ports/math/py-gau2grid/work-py36/gau2grid-1.3.0/build/temp.freebsd-11.2-STABLE-amd64-3.6'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "setup.py", line 143, in <module>
    zip_safe=False, )
  File "/usr/local/lib/python3.6/site-packages/setuptools/__init__.py", line 143, in setup
    return distutils.core.setup(**attrs)
  File "/usr/local/lib/python3.6/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/usr/local/lib/python3.6/distutils/dist.py", line 955, in run_commands
    self.run_command(cmd)
  File "/usr/local/lib/python3.6/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "/usr/local/lib/python3.6/distutils/command/build.py", line 135, in run
    self.run_command(cmd_name)
  File "/usr/local/lib/python3.6/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "/usr/local/lib/python3.6/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "setup.py", line 33, in run
    self.build_extension(ext)
  File "setup.py", line 60, in build_extension
    subprocess.check_call(['cmake', '--build', '.'] + build_args, cwd=self.build_temp)
  File "/usr/local/lib/python3.6/subprocess.py", line 291, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmake', '--build', '.', '--config', 'Release', '--', '-j2']' returned non-zero exit status 2.

The underlying cmake command fails:

$ cmake --build . --config Release -- -j2
Error: could not load cache

$ cmake .
A simpler cmake command also fails:

$ cmake .
...
...
-- Setting (unspecified) option INSTALL_PYMOD: OFF
CMake Error at cmake/autocmake_safeguards.cmake:16 (message):
  In-source builds not allowed.  Please run CMake from top directory and
  specify a build directory (e.g., cmake -H.  -Bbuild).
Call Stack (most recent call first):
  CMakeLists.txt:47 (include)


-- Configuring incomplete, errors occurred!

Calculating cubes for visualization using the C interface

I would like to integrate this into Avogadro, and make use of it in a desktop application. In addition, this is wrapped, and used on a server to deliver to web clients using a RESTful API. We effectively load up Gaussian basis sets, and an MO coefficient matrix.

I currently map each basis function to an atom, with a position in space, and then parallelise the code on the grid, effectively giving a smaller grid to each core, writing directly into it from all threads but ensuring only one thread will ever attempt to write to any given scalar. The code figures out which index to write to, its Cartesian position in space, and then iterates over all basis functions for the supplied molecular orbital.

I am open to reorganizing the code, but would like to maintain the high level interface. Load quantum output, then calculate the MO cube, which is then further processed before being visualized. It would be helpful to understand how I would map our basis sets, MO matrix, and atom positions in. Also what the most efficient method of passing in a subset of the cube, and whether we would need multiple copies of the data per thread, or could maintain the single copy that is only read across all threads.

build failure: pybuild installs during build_extension

Just updating the Debian packaging to 1.3.1 results in a build/install failure:

[100%] Built target gg
make[3]: Leaving directory '/<<PKGBUILDDIR>>/build/temp.linux-amd64-3.7'
Install the project...
-- Install configuration: "Release"
-- Installing: /usr/lib/python3/dist-packages/gau2grid
CMake Error at cmake_install.cmake:41 (file):
  file INSTALL cannot make directory
  "/usr/lib/python3/dist-packages/gau2grid": Permission denied


make[2]: *** [Makefile:118: install] Error 1
make[2]: Leaving directory '/<<PKGBUILDDIR>>/build/temp.linux-amd64-3.7'
Traceback (most recent call last):
  File "setup.py", line 147, in <module>
    zip_safe=False,
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 143, in setup
    return distutils.core.setup(**attrs)
  File "/usr/lib/python3.7/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/usr/lib/python3.7/distutils/dist.py", line 966, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python3.7/distutils/dist.py", line 985, in run_command
    cmd_obj.run()
  File "/usr/lib/python3.7/distutils/command/build.py", line 135, in run
    self.run_command(cmd_name)
  File "/usr/lib/python3.7/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "/usr/lib/python3.7/distutils/dist.py", line 985, in run_command
    cmd_obj.run()
  File "setup.py", line 33, in run
    self.build_extension(ext)
  File "setup.py", line 58, in build_extension
    subprocess.check_call(['cmake', '--build', '.', '--target', 'install'], cwd=self.build_temp)
  File "/usr/lib/python3.7/subprocess.py", line 347, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmake', '--build', '.', '--target', 'install']' returned non-zero exit status 2.

I think the root of the problem is that setup.py now runs install in the build_extension stanza, via 6f720c5:

        subprocess.check_call(['cmake', '--build', '.', '--target', 'install'], cwd=self.build_temp)

During build, $DESTDIR is not setup by packaging infrastructure so it tries to install into the root filesystem, not the staging one.

Not sure how install should work otherwise (I've never seen in handled specifically in setup.py), why was that line added in 1.3.1 and what's the purpose? If I remove it, gau2grid builds/installs just fine for me; this is what gets run (and which is mostly in line with README.md):

/usr/bin/python3 setup.py install --root `pwd`/debian/tmp

/cc @loriab