Use Mollist2 as internal system information data structure

doc/source/develop.md

@@ -10,11 +10,9 @@ You can hardly use `Git` effectively if you have no idea how it works. There are
 
 ---
 
-Now I assume you know how to use `Git`.
-
 Let's start with the first and most important rule:
 
-### **DO NOT PUSH TO THE MASTER BRANCH**.
+**DO NOT PUSH TO THE MASTER BRANCH**.
 
 Why? Keep on reading and you'll know. Actually, we've protected the master branch so that you can't push to it.
 For a large project, this rule must be followed even for the owner of the project.
@@ -31,26 +29,26 @@ git checkout -b develop
 Now you can make any modifications you like and commit them to your branch.
 **After** you have **committed** all you want, you can merge all changes to the master following the procedures below:
 
-1. Check if your genius branch is working by running `pytest` under the root directory.
+1. Check if your branch is working by running `pytest` under the root directory.
 1. Push your local branch to the `GitHub` server:
     ```
     git push origin develop
     ```
 2. Create a *Pull Request (PR)* for your branch. This is done in the `GitHub` web pages. Near the button to choose the currently shown branches you can find another button called `New pull request`. Write helpful information when creating
 the PR.
 3. Check the status of the tests. These tests must all pass.
-4. If anything went wrong with the tests or you want to further modify your codes, don't worry - it's not a big deal. 
+4. If anything went wrong with the tests or you want to further modify your codes, don't worry - it's perfectly common. 
 You can continue your local development as usual and push them to your remote branch, after that, your PR will be automatically updated and all tests will be run again.
-5. Wait for a reviewer to review and approve your code. Usually, this will happen after you've introduced your code in the code session of the group meeting. Then the reviewer will merge your code for you if he's OK with your implementation.
+5. Wait for a reviewer to review and approve your code. Then the reviewer will merge your code for you if he's OK with your implementation.
 
 Now you can do anything you want with your branch. Delete them, rename them, commit new codes, anything you like.
 It's not related to the master branch anymore. 
 You can continue your development on your branch and submit another PR after a while, 
 or you can start a new branch.
 
 You can compare this approach with the directly-push-to-master way. Which one is more safe and easier to manage if there are lots of contributors? IMO, the benefits of all the fuss are:
-- The master branch is always stable. It is guaranteed that anyone at any time will get a working version of Renormalizer by cloning the master branch.
-- The conflicts between different commits are mitigated. Suppose someone modified a lib function and commit to master before you, your commit might not work on the latest master branch although it might work on your local machine. This can be avoided With PR where the merged branch is also tested.
+- The master branch is always stable. It is guaranteed that anyone at any time is able to get a working version of Renormalizer by cloning the master branch.
+- The conflicts between different commits are mitigated. Suppose someone modified a lib function and commit to master before you, your commit might not work on the latest master branch although it might work on your local machine. This can be avoided with PR where the merged branch is also tested.
 - You're allowed to modify the history of your commits. The history of the master branch shall not be modified but you can do anything you like in your own branch. 
 - Changes in the code are dressed with contexts. In PRs there will be more explanations, discussions and cross-reference with other issues and PRs. This will help other people and your future self understand the code.
 

doc/source/index.rst

@@ -27,7 +27,6 @@ Contents
    develop.md
    tutorial.md
    model.rst
-   basis.rst
    mps.rst
    gs.rst
    spectrum.rst

doc/source/model.rst

@@ -1,15 +1,60 @@
 Model
 *************************************
 
-Define the system
+Use the class :class:`~renormalizer.model.Model`, :class:`~renormalizer.model.HolsteinModel`,
+or :class:`~renormalizer.model.SpinBosonModel` to define the calculated system.
+These classes require :class:`~renormalizer.model.basis.BasisSet` and :class:`~renormalizer.model.Op`
+as input.
+
+The Model classes
 =================
-Use the class :class:`~renormalizer.model.MolList` or :class:`~renormalizer.model.MolList` to define the calculated system.
 
-.. autoclass:: renormalizer.model.mlist.MolList2
+.. autoclass:: renormalizer.model.Model
+    :members:
+    :inherited-members:
+
+
+.. autoclass:: renormalizer.model.HolsteinModel
+    :members:
+    :inherited-members:
+
+
+.. autoclass:: renormalizer.model.SpinBosonModel
+    :members:
+    :inherited-members:
+
+Basis Functions
+===============
+
+.. autoclass:: renormalizer.model.basis.BasisSet
+    :members:
+    :inherited-members:
+
+
+.. autoclass:: renormalizer.model.basis.BasisSHO
+    :members:
+    :inherited-members:
+
+.. autoclass:: renormalizer.model.basis.BasisSimpleElectron
+    :members:
+    :inherited-members:
+
+.. autoclass:: renormalizer.model.basis.BasisMultiElectron
     :members:
     :inherited-members:
 
+.. autoclass:: renormalizer.model.basis.BasisMultiElectronVac
+    :members:
+    :inherited-members:
+
+.. autoclass:: renormalizer.model.basis.BasisHalfSpin
+    :members:
+    :inherited-members:
+
+
+The Operator Class
+==================
 
-.. autoclass:: renormalizer.model.mlist.MolList
+.. autoclass:: renormalizer.model.Op
     :members:
     :inherited-members: