Pre-commit Update

.clang-format

@@ -34,7 +34,7 @@ AlwaysBreakBeforeMultilineStrings: false
 AlwaysBreakTemplateDeclarations: true
 BinPackArguments: true
 BinPackParameters: true
-BraceWrapping:   
+BraceWrapping:
   AfterClass:      false
   AfterControlStatement: false
   AfterEnum:       false
@@ -65,7 +65,7 @@ DisableFormat:   false
 ExperimentalAutoDetectBinPacking: false
 FixNamespaceComments: true
 ForEachMacros:   [ foreach, Q_FOREACH, BOOST_FOREACH ]
-IncludeCategories: 
+IncludeCategories:
   - Regex:           '^"'
     Priority:        1
   - Regex:           '^<'

.flake8

@@ -0,0 +1,2 @@
+[flake8]
+extend-ignore = E203, E701, E741, W503

.github/workflows/pull_request.yaml

@@ -23,8 +23,6 @@ on:
 jobs:
   check_formatting:
     uses: NWChemEx/.github/.github/workflows/check_formatting.yaml@master
-    with:
-      license_config: ".github/.licenserc.yaml"
 
   test_nwx_docs:
     uses: NWChemEx/.github/.github/workflows/test_nwx_docs.yaml@master

.github/.licenserc.yaml → .licenserc.yaml

@@ -24,5 +24,7 @@ header:
     - docs/requirements.txt
     - docs/source/bibliography/*.bib
     - version.txt
+    - build/
+    - .flake8
 
   comment: never

LICENSE

@@ -174,4 +174,4 @@
       incurred by, or claims asserted against, such Contributor by reason
       of your accepting any such warranty or additional liability.
 
-   END OF TERMS AND CONDITIONS
+   END OF TERMS AND CONDITIONS

docs/requirements.txt

@@ -1,6 +1,6 @@
 GitPython
+setuptools
 sphinx==v7.2.6
 sphinx_rtd_theme==1.3.0
-sphinxcontrib-bibtex
-setuptools
 sphinx_tabs
+sphinxcontrib-bibtex

docs/source/background/motivation.rst

@@ -21,7 +21,7 @@ Chemist Motivation
 
 .. note::
 
-   Some of the todos on this page are partially addressed in the overview and 
+   Some of the todos on this page are partially addressed in the overview and
    should be moved here.
 
 TODO: explain traditional stack (UI to computation)

docs/source/conf.py

@@ -21,13 +21,14 @@
 # http://www.sphinx-doc.org/en/master/config
 
 import os
+
 import git
 
 # -- Project information -----------------------------------------------------
 
-project = u'Chemist'
-copyright = u'2020, NWChemEx Community'
-author = u'NWChemEx Community'
+project = "Chemist"
+copyright = "2020, NWChemEx Community"
+author = "NWChemEx Community"
 
 ##############################################################################
 #           Shouldn't need to change anything below this point               #
@@ -61,43 +62,47 @@
 
 # If your documentation needs a minimal Sphinx version, state it here.
 #
-needs_sphinx = '1.3'
+needs_sphinx = "1.3"
 
 # Add any Sphinx extension module names here, as strings. They can be
 # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
 # ones.
 extensions = [
-    'sphinx.ext.autodoc', 'sphinx.ext.mathjax', 'sphinx.ext.githubpages',
-    'sphinx.ext.autosummary', 'sphinx_rtd_theme', 'sphinxcontrib.bibtex',
-    'sphinx_tabs.tabs'
+    "sphinx.ext.autodoc",
+    "sphinx.ext.mathjax",
+    "sphinx.ext.githubpages",
+    "sphinx.ext.autosummary",
+    "sphinx_rtd_theme",
+    "sphinxcontrib.bibtex",
+    "sphinx_tabs.tabs",
 ]
 
 # Add any paths that contain templates here, relative to this directory.
-#templates_path = ['_templates']
+# templates_path = ['_templates']
 
 # The suffix(es) of source filenames.
 # You can specify multiple suffix as a list of string:
 #
 # source_suffix = ['.rst', '.md']
-source_suffix = '.rst'
+source_suffix = ".rst"
 
 # The master toctree document.
-master_doc = 'index'
+master_doc = "index"
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.
 #
 # This is also used if you do content translation via gettext catalogs.
 # Usually you set "language" from the command line for these cases.
-language = 'en'
+language = "en"
 
 # List of patterns, relative to source directory, that match files and
 # directories to ignore when looking for source files.
 # This pattern also affects html_static_path and html_extra_path .
 exclude_patterns = []
 
 # The name of the Pygments (syntax highlighting) style to use.
-pygments_style = 'sphinx'
+pygments_style = "sphinx"
 
 # Should figures be numbered?
 numfig = True
@@ -107,20 +112,20 @@
 # The theme to use for HTML and HTML Help pages.  See the documentation for
 # a list of builtin themes.
 #
-html_theme = 'sphinx_rtd_theme'
+html_theme = "sphinx_rtd_theme"
 
-html_logo = 'assets/logo.png'
+html_logo = "assets/logo.png"
 
 # Theme options are theme-specific and customize the look and feel of a theme
 # further.  For a list of options available for each theme, see the
 # documentation.
 #
-html_theme_options = {'logo_only': True}
+html_theme_options = {"logo_only": True}
 
 # Add any paths that contain custom static files (such as style sheets) here,
 # relative to this directory. They are copied after the builtin static files,
 # so a file named "default.css" will overwrite the builtin "default.css".
-#html_static_path = ['_static']
+# html_static_path = ['_static']
 
 # Custom sidebar templates, must be a dictionary that maps document names
 # to template names.
@@ -135,12 +140,12 @@
 # -- Options for HTMLHelp output ---------------------------------------------
 
 # Output file base name for HTML help builder.
-htmlhelp_basename = project + 'doc'
+htmlhelp_basename = project + "doc"
 
 # -- Extension configuration -------------------------------------------------
 
 # -- Options for bibtex ------------------------------------------------------
 
-bibtex_bibfiles = ['bibliography/background.bib']
-bibtex_reference_style = 'super'
-bibtex_default_style = 'plain'
+bibtex_bibfiles = ["bibliography/background.bib"]
+bibtex_reference_style = "super"
+bibtex_default_style = "plain"

docs/source/developer/adding_an_operator.rst

@@ -19,25 +19,25 @@ Notes on Adding an Operator
 To add a new operator to Chemist requires modifications in several places. They
 are collected here for convenience.
 
-- Forward declare it in 
+- Forward declare it in
   include/chemist/quantum_mechanics/operator/operator_fwd.hpp
-- Declare the class in 
+- Declare the class in
   include/chemist/quantum_mechanics/operator/<operator_name>.hpp
 - Define the class in src/chemist/quantum_mechanics/operator/<operator_name>.cpp
-- Add it to the OperatorVisitor class in 
+- Add it to the OperatorVisitor class in
   include/chemist/quantum_mechanics/operator/operator_visitor.hpp
-- Define the new OperatorVisitor functions in 
+- Define the new OperatorVisitor functions in
   src/chemist/quantum_mechanics/operator/operator_visitor.cpp
-- Add unit tests to 
+- Add unit tests to
   tests/cxx/unit_tests/quantum_mechanics/operator/<operator_name>.cpp
 - Add unit tests to
   tests/python/unit_tests/quantum_mechanics/operator/<operator_name>.py
-  
+
 .. note::
 
    "<operator_name>" in the above file names should be replaced with your
    operator's actual name.
 
 As a helpful hint, copy/paste ``kinetic.hpp`` / ``kinetic.cpp`` for one-
 particle operators and ``Coulomb.hpp`` / ``Coulomb.cpp`` for two-particle
-operators and then find/replace the name.
+operators and then find/replace the name.

docs/source/developer/design/chemical_system/molecule.rst

@@ -335,4 +335,4 @@ Future Considerations
 
 - Could template ``Atom`` on the type of the nucleus and introduce additional
   nucleus types in cases where the nucleus is to be treated quantum
-  mechanically.
+  mechanically.

docs/source/developer/design/chemical_system/system.rst

@@ -30,9 +30,9 @@ What is a Chemical System?
 Many quantum chemistry codes talk about the "molecule" as being the input to
 the code; however, in chemistry, molecules are simply sets of atoms. Even with
 the general definition adopted in :ref:`md_what_is_a_molecule` there are often
-additional parts to the system being studied -- for example external fields -- 
-that are not captured by the "molecule" concept. We define the chemical system 
-to be the entire system we are trying to model. This will almost always 
+additional parts to the system being studied -- for example external fields --
+that are not captured by the "molecule" concept. We define the chemical system
+to be the entire system we are trying to model. This will almost always
 include a molecule.
 
 .. _csd_considerations:
@@ -76,6 +76,4 @@ Model parameters
    In many cases it is a fine-line between model parameters and the system
    being modeled. Generally speaking we prefer to treat model parameters
    separate from the chemical system when they can be clearly distinguished.
-   Of note the AO basis set is considered separately. 
-
-
+   Of note the AO basis set is considered separately.

docs/source/developer/design/dsl.rst

@@ -18,7 +18,7 @@ DSL Component
 
 These are notes on designing the DSL component.
 
-- We'll need DSLs for combining wavefunctions, operators, and potentially 
+- We'll need DSLs for combining wavefunctions, operators, and potentially
   BraKets and chemical systems.
 - This component is an attempt to create a reusable DSL framework. It stops
   shy of evaluating the expression that is created.

docs/source/developer/design/quantum_mechanics/braket/index.rst

@@ -18,47 +18,47 @@
 Design of the BraKet Component
 ##############################
 
-This is a collection of notes on the design of the classes for the BraKet 
+This is a collection of notes on the design of the classes for the BraKet
 component and should be formalized at some point.
 
 - In prototyping ``BraKet`` and ``TensorRepresentation`` were property types;
   however, this was burdensome when vector spaces/wavefunctions exhibited
-  inheritance, e.g., if x inherits from y, then the property type 
-  ``BraKet<y, Kinetic<Electron>, y>`` was different from 
+  inheritance, e.g., if x inherits from y, then the property type
+  ``BraKet<y, Kinetic<Electron>, y>`` was different from
   ``BraKet<x, Kinetic<Electron>, x>``. Moreover because the latter property
   type did not inherit from the former, implicit conversion could not happen.
   With ``BraKet`` (and ``TensorRepresentation``) being traditional classes we
   can define our own implicit conversions easily.
-- Rigorously kets are vectors and bras are operations which project onto a 
+- Rigorously kets are vectors and bras are operations which project onto a
   vector.
-- The "projection" part of the bra involves antilinear projection on to a 
+- The "projection" part of the bra involves antilinear projection on to a
   vector. In practice, bras are labeled with the complex conjugate of the
   vector they project on to, i.e., if u is the complex conjugate of v than the
   bra which projects on to u is actually labeled v.
 
-   - The points here being: one, we don't expect the user to specify the 
-     projection, it's implied, and two based on the labeling convention we need 
+   - The points here being: one, we don't expect the user to specify the
+     projection, it's implied, and two based on the labeling convention we need
      to internally take the complex conjugate of whatever the user gives us.
 
 - Following from the last points a bra-ket is rigorously a scalar; however,
   since this scalar is a tensor element it is also common to represent the
   entire tensor by specifying a generic element of the tensor in bra-ket form.
 
-   - Think of :math:`\textbf{A}=\braket{i\mid A\mid j}` as the analog of 
+   - Think of :math:`\textbf{A}=\braket{i\mid A\mid j}` as the analog of
      :math:`\textbf{A} = a_{ij}`.
    - From a design standpoint this means we want to be able to specify both an
      entire tensor and a tensor element with bra-ket objects. The two are
      distinguished based on whether the usr provides a specific vector or a
      generic vector (which we represent by the entire vector space it can stand
      for).
 
-      - We have separate base classes for Wavefunction and VectorSpace. Should 
+      - We have separate base classes for Wavefunction and VectorSpace. Should
         we have separate base classes for scalar vs tensor BraKets?
 
-        - Users likely will expect "Wavefunction, Operator, Wavefunction" to 
-          evaluate to a scalar (or vector depending on the operator) and 
-          "VectorSpace, Operator, VectorSpace" to evaluate to a 
-          tensor. 
+        - Users likely will expect "Wavefunction, Operator, Wavefunction" to
+          evaluate to a scalar (or vector depending on the operator) and
+          "VectorSpace, Operator, VectorSpace" to evaluate to a
+          tensor.
         - Define ``TensorRepresentation`` for ``BraKet`` that evaluate to
           tensors and ``TensorElement`` for ``BraKet`` that evaluate to an
           element of the tensor.
@@ -75,4 +75,4 @@ component and should be formalized at some point.
 .. figure:: assets/braket_hierarchy.png
    :align: center
 
-   BraKet class hierarcy.
+   BraKet class hierarcy.

docs/source/developer/design/quantum_mechanics/operator/hamiltonian.rst

@@ -22,8 +22,8 @@ These are musings on the design of the Hamiltonian class and should be turned
 into full documentation at some point.
 
 - The Hamiltonian will always be an indefinite operator.
-    
-    - This is necessary because, in general, it will contain a mix of one- and 
+
+    - This is necessary because, in general, it will contain a mix of one- and
       two-particle operators. Bra-kets of such an operator only makes sense with
       many-particle wavefunctions.
 
@@ -35,18 +35,18 @@ into full documentation at some point.
     Hamiltonian has. On the other this will complicate interfaces.
   - Order of parameters can be managed by convention.
   - Is it templated on operators present or particles present?
-  - If on particles, how do we know that it say contains not just single 
+  - If on particles, how do we know that it say contains not just single
     ``Electron`` terms, but also terms that depend on pairs of ``Electron``
     objects?
 
 .. code-block:: c++
-   
+
    // These are the proposed templating schemes
 
    // Templated on operators ("easily" deduced from ctor)
    Hamiltonian<T_e_type, V_en_type, V_ee_type, V_nn_type> H0;
 
-   // Templated on particle types (no distinction of what definite terms appear) 
+   // Templated on particle types (no distinction of what definite terms appear)
    Hamiltonian<ManyElectrons, Nuclei> H1
 
    // Templated on definite sizes
@@ -59,10 +59,10 @@ Creation, usage APIs:
 .. code-block:: c++
 
    auto [T_e, V_en, V_ee, V_en, V_nn] = get_operators();
-   
+
    // Works with C++17, could deduce any of the above types
    Hamiltonian H(T_e + V_en + V_ee + V_en + V_nn);
-  
+
    // If templated, SFINAE could be used to enable/disable these functions
    T_e = H.T_e(); // Takes an optional offset in case there's more than one
 
@@ -93,9 +93,9 @@ example:
     using pt0 = EvaluateBraKet<BraKet<Determinant, H_type0, Determinant>>;
     using pt1 = EvaluateBraKet<BraKet<Determinant, H_type1, Determinant>>;
 
-Here Hamiltonians of ``H_type0`` could only be passed to ``pt0`` and 
+Here Hamiltonians of ``H_type0`` could only be passed to ``pt0`` and
 Hamiltonians of ``H_type1`` could only be passed to ``pt1``. More than likely
 ``pt0`` could handle Hamiltonians of ``H_type1`` (though it is unlikely that
 ``pt1`` could handle Hamiltonians of ``H_type0``).
 
-Verdict: Go with type-erased to avoid combinatorial interaction of terms.
+Verdict: Go with type-erased to avoid combinatorial interaction of terms.