psi4 / gdma

Anthony Stone's Gaussian Distributed Multipole Analysis wrapped in CMake

Status
Latest Release
Communication
Foundation
Installation
Demo

Psi4 is an open-source suite of ab initio quantum chemistry programs designed for efficient, high-accuracy simulations of molecular properties. We routinely perform computations with >2500 basis functions on multi-core machines.

With computationally demanding portions written in C++, exports of many C++ classes into Python via Pybind11, and a flexible Python driver, Psi4 strives to be friendly to both users and developers.

• Users' Website www.psicode.org

• Downloading and Installing Psi4 https://psicode.org/psi4manual/master/build_faq.html (for the CMake adept, see CMakeLists.txt

• Manual http://bit.ly/psi4manual (built nightly from master branch) or https://psicode.org/psi4manual/1.4.0/index.html (last release)

• Tutorial https://psicode.org/psi4manual/master/tutorial.html for Psithon (psi4 job.in), https://psicode.org/psi4manual/master/psiapi.html for PsiAPI (python job.py)

• Forum http://forum.psicode.org

• Communication & Support https://psicode.org/psi4manual/master/introduction.html#technical-support

• GitHub https://github.com/psi4/psi4 (authoritative repository)

• Continuous Integration Status on Linux and Windows

• Anaconda https://anaconda.org/psi4 (binary available for Linux, Mac, Mac Silicon, Windows, and WSL Windows ) ) instructions

• Coverage Python and C++ source code lines hit by running most of the test suite.

• Interested Developers https://psicode.org/developers.php (replacement page needed) (welcome to fork psi4/psi4 and follow GitHub contribution procedure)

• Sample Inputs http://www.psicode.org/psi4manual/master/testsuite.html (also in samples/)

• Download Tarball https://github.com/psi4/psi4/releases

License

Psi4: an open-source quantum chemistry software package

Copyright (c) 2007-2024 The Psi4 Developers.

The copyrights for code used from other parties are included in the corresponding files.

Psi4 is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, version 3.

Psi4 is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public License along with Psi4; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

The full text of the GNU Lesser General Public License (version 3) is included in the COPYING.LESSER file of this repository, and can also be found here.

Citation

The journal article reference describing Psi4 is:

D. G. A. Smith, L. A. Burns, A. C. Simmonett, R. M. Parrish, M. C. Schieber, R. Galvelis, P. Kraus, H. Kruse, R. Di Remigio, A. Alenaizan, A. M. James, S. Lehtola, J. P. Misiewicz, M. Scheurer, R. A. Shaw, J. B. Schriber, Y. Xie, Z. L. Glick, D. A. Sirianni, J. S. O'Brien, J. M. Waldrop, A. Kumar, E. G. Hohenstein, B. P. Pritchard, B. R. Brooks, H. F. Schaefer III, A. Yu. Sokolov, K. Patkowski, A. E. DePrince III, U. Bozkaya, R. A. King, F. A. Evangelista, J. M. Turney, T. D. Crawford, C. D. Sherrill, "Psi4 1.4: Open-Source Software for High-Throughput Quantum Chemistry", J. Chem. Phys. 152(18) 184108 (2020).

• for Psi4 v1.1
• for Psi4NumPy
• for Psi4 alpha releases
• for Psi3

gdma's Issues

make conda package

• Mac
• Linux

licensing

Stone speaks of licenses, but not for this particular code.

• inform Stone of this hosting and CMake build scheme. He was ok with exactly this code in Psi4 itself, so no reason a separate repo should be a problem, so courtesy communication.
• inform Stone of imminent conda package. @loriab has talking points, if required
• see if there's a license we can put into this repo

cmake 2023 updates

• update old files

  • copy over xhost.cmake that has new compilers. import it instead of one-liner. adapt if C, not CXX.
    • No, since mostly fortran
  • expand safeguards to new build types, RelWithDebInfo, and MinSizeRel
  • update cmake min version to 3.16
  • replace SameMajorVersion with now-available SameMinorVersion if appropriate
    • AnyNewVersion -> SameMajorVersion
  • remove any ${PN} in main project CMake as they tend to get clobbered in/after find_package
  • any new project-specific options, prepend in project-case, like ambit_ENABLE_PYTHON. does not apply to e.g., BUILD_TESTING, BUILD_SHARED_LIBS

• Python

  • if still on old NumPy/pb11 Py detection, switch to approx. find_package(Python 3.7 COMPONENTS Interpreter Development NumPy REQUIRED)
  • update any set(Python_ADDITIONAL_VERSIONS
  • update cmake_minimum_required(VERSION 3.16) for Py detection
  • update any PYTHON_EXECUTABLE to Python_EXECUTABLE
  • remove any old FindPythonLibsNew.cmake
  • if any pybind11, check that find_package(Python) before find_package(pybind11)
  • if any pybind11 target, remove PREFIX/SUFFIX from properties
  • psi4: update the call in external/

• editable config.cmake location

  • add option(<project>_INSTALL_CMAKEDIR) to make Config.cmake location editable with variable, incl any subprojects like TargetLAPACK.
  • recipe: specify in bld.bat as -D <project>_INSTALL_CMAKEDIR="Library\share\cmake\<project>" ^ if CMAKE_INSTALL_PREFIX="%PREFIX%"
  • psi4: add the call in external/ (CMAKE_ARGS and <project>_DIR and any TargetLAPACK, etc.)

• modernize target install/export

  • for install(TARGETS), use full runtime/arch/lib DESTINATIONs so Windows can work
  • for install(TARGETS), consider a descriptive EXPORT so not repeating targets filename
  • for install(EXPORT), use descriptive EXPORT and lang or type names to Targets files

• make properties target-centered, particularly for FetchContent usage. target and find_package(<package>) should provide same info.

  • define export_properties variable and append it to all base targets (e.g., static and shared always-built libs)
  • set the version on the target. use casing like in the config file, probaly project(CheMPS2) --> CheMPS2_VERSION
  • set all other properties that were project-specific vars in the config (like Libint_MAX_AM_ERI) on the target
  • check through find_package() that targets are fully loaded (--log-level verbose and extra stuff in Config.cmake can help)
  • define aliases matching imported targets, add_library(ambit::ambit ALIAS ambit-shared). Favor shared if both can be built together.
  • rename any CMAKE_SOURCE_DIR/CMAKE_BINARY_DIR to PROJECT_SOURCE_DIR/PROJECT_BINARY_DIR
  • check fetch_content works

• modernize <project>Config.cmake.in

  • kill off all PN with something like set(amb ambit) # NameSpace. PN gets overwritten a lot, so let's specialize it.
  • remove find_header, find_file, find_library find_exe reminicent of Find<project>.cmake rather than <project>Config.cmake
  • read find_project variables off target, rather than setting from file_header/lib/exe results
  • if any Find files installed, add list(APPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_LIST_DIR})
  • check components with check_required_components(<project>) (probably already present)
  • NEVER load exported <project>Targets.cmake before all components confirmed found and all dependencies confirmed found
  • run a find_project(<project>) to check that vars match target (same as 4th bullet prev. section)

• check that all dependencies are handled (sometimes outsourced to psi4, like BLAS for dkh)

  • add TargetLAPACK if using BLAS/LAPACK
  • copy over new FindTargetLAPACK, FindTargetHDF5 as needed. modify if only use BLAS
  • install the Find files with the Config
  • in config file, add any find_dependency that we were leaving for psi4 before

• handling lib and pylib as separate projects

  • there's room for opinion on this. see discussion at GH:jturney/ambit/pyambit/CMakeLists.txt .
  • YES, do have an ENABLE_PYTHON (or better, _ENABLE_PYTHON) so library can be built alone
  • PROBABLY YES, do have a project(pyproject) so python can be built alone after detecting project
  • CHOOSING YES, do have a ambit_PYMOD variable attached to the target and Config?
  • CHOOSING YES, same Config.cmake file for C++ and Py, where latter optional and detected with COMPONENTS Python? It's easy enough to have the targets exported to Targets-Python.cmake so same file can manage.
  • details on separate pylib
    • for installation positioning, use PYMOD_INSTALL_LIBDIR if var already exists b/c in psi orbit. otherwise emulate libint (LIBINT2_INSTALL_PYMODDIR) or libxc (PYLIBXC_INSTALL_PYMODDIR)
    • copy over basic and relevant options from main project
    • copy over version from main project. notate where to sync verson
      notes for packagers about config.cmake
    • install whole py intf module, incl tests
    • remove restriction that pb11 module can only link to shared library. remove PIC for pb11 module since it handles that
    • for Linux-style install ONLY, write a Python component to Config.cmake
    • if a Py-style install is wanted, toggle Linux-style and Py-style install with something like LIBINT2_PREFIX_PYTHON_INSTALL
    • leave a note for packagers about lib/pylib and config.cmake choices

• particular for this project: gdma

  • add executable back
  • add py module
  • add windows

final address and tag

Create a tag (more a build version tag than a code version tag). See that the tag and correct repo address are in psi4 GH and conda.

update version

Apparently 2.2.11 is available. No obvious statement of what's different. This repo/psi4 should probably be upgraded.