Merge pull request #2635 from pybamm-team/develop

Make release v23.1

Author: brosaplanella

.all-contributorsrc

@@ -529,7 +529,8 @@
       "profile": "https://github.com/agriyakhetarpal",
       "contributions": [
         "infra",
-        "code"
+        "code",
+        "doc"
       ]
     },
     {

.github/PULL_REQUEST_TEMPLATE.md

@@ -14,7 +14,7 @@ Please add a line in the relevant section of [CHANGELOG.md](https://github.com/p
 
 # Key checklist:
 
-- [ ] No style issues: `$ flake8`
+- [ ] No style issues: `$ pre-commit run`
 - [ ] All tests pass: `$ python run-tests.py --unit`
 - [ ] The documentation builds: `$ cd docs` and then `$ make clean; make html`
 

.github/workflows/benchmark_on_push.yml

@@ -11,8 +11,15 @@ jobs:
         uses: actions/setup-python@v4
         with:
           python-version: 3.8
-      - name: Install asv
-        run: pip install -U pip virtualenv asv
+      - name: Install Linux system dependencies
+        run: |
+          sudo apt-get update
+          sudo apt install gfortran gcc libopenblas-dev
+      - name: Install python dependencies
+        run: |
+          python -m pip install --upgrade pip wheel setuptools virtualenv asv wget cmake casadi numpy
+      - name: Install SuiteSparse and Sundials
+        run: python scripts/install_KLU_Sundials.py
       - name: Fetch base branch
         run: |
           # This workflow also runs for merge commits
@@ -22,6 +29,7 @@ jobs:
           if [ $current_branch != "develop" ]; then
               git fetch origin develop:develop
           fi
+
       - name: Run benchmarks
         run: |
           asv machine --machine "GitHubRunner"
@@ -30,7 +38,7 @@ jobs:
           HEAD_COMMIT=$(git rev-parse HEAD)
           echo $BASE_COMMIT | tee commits_to_compare.txt
           echo $HEAD_COMMIT | tee -a commits_to_compare.txt
-          asv run HASHFILE:commits_to_compare.txt --m "GitHubRunner" --show-stderr
+          asv run HASHFILE:commits_to_compare.txt --m "GitHubRunner" --show-stderr -v
       - name: Compare commits' benchmark results
         run: |
           BASE_COMMIT=$(head -1 commits_to_compare.txt)

.github/workflows/test_on_push.yml

@@ -36,8 +36,8 @@ jobs:
 
       - name: Check style
         run: |
-          python -m pip install "tox<4"
-          tox -e flake8
+          python -m pip install pre-commit
+          pre-commit run ruff
 
   build:
     needs: style

.gitignore

@@ -61,9 +61,6 @@ dist/
 coverage.xml
 htmlcov/
 
-# black setup file seems to make Travis CI fail
-pyproject.toml
-
 # virtual enviroment
 env/
 venv/

.pre-commit-config.yaml

@@ -14,7 +14,8 @@ repos:
     hooks:
       - id: black
 
-  - repo: https://github.com/PyCQA/flake8
-    rev: 6.0.0
+  - repo: https://github.com/charliermarsh/ruff-pre-commit
+    rev: "v0.0.237"
     hooks:
-      - id: flake8
+      - id: ruff
+        args: [--ignore=E741, --exclude=__init__.py]

CHANGELOG.md

@@ -1,5 +1,19 @@
 # [Unreleased](https://github.com/pybamm-team/PyBaMM/)
 
+# [v23.1](https://github.com/pybamm-team/PyBaMM/tree/v23.1) - 2023-01-31
+
+## Features
+
+- Changed linting from `flake8` to `ruff` ([#2630](https://github.com/pybamm-team/PyBaMM/pull/2630)).
+- Changed docs theme to pydata theme and start to improve docs in general ([#2618](https://github.com/pybamm-team/PyBaMM/pull/2618)).
+- New `contact resistance` option, new parameter `Contact resistance [Ohm]` and new variable `Contact overpotential [V]` ([#2598](https://github.com/pybamm-team/PyBaMM/pull/2598)).
+- Steps in `Experiment` can now be tagged and cycle numbers be searched based on those tags ([#2593](https://github.com/pybamm-team/PyBaMM/pull/2593)).
+
+## Bug fixes
+
+- Fixed a bug where the solid phase conductivity was double-corrected for tortuosity when loading parameters from a BPX file ([#2638](https://github.com/pybamm-team/PyBaMM/pull/2638)).
+- Changed termination from "success" to "final time" for algebraic solvers to match ODE/DAE solvers ([#2613](https://github.com/pybamm-team/PyBaMM/pull/2613)).
+
 # [v22.12](https://github.com/pybamm-team/PyBaMM/tree/v22.12) - 2022-12-31
 
 ## Features
@@ -12,6 +26,7 @@
 
 ## Bug fixes
 
+- Allow models that subclass `BaseBatteryModel` to use custom options classes ([#2571](https://github.com/pybamm-team/PyBaMM/pull/2571))
 - Fixed bug with `EntryPoints` in Spyder IDE ([#2584](https://github.com/pybamm-team/PyBaMM/pull/2584))
 - Fixed electrolyte conservation when options {"surface form": "algebraic"} are used
 - Fixed "constant concentration" electrolyte model so that "porosity times concentration" is conserved when porosity changes ([#2529](https://github.com/pybamm-team/PyBaMM/pull/2529))

CITATION.cff

@@ -24,6 +24,6 @@ keywords:
   - "expression tree"
   - "python"
   - "symbolic differentiation"
-version: "22.12"
+version: "23.1"
 repository-code: "https://github.com/pybamm-team/PyBaMM"
 title: "Python Battery Mathematical Modelling (PyBaMM)"

CONTRIBUTING.md

@@ -63,17 +63,18 @@ Finally, if you really, really, _really_ love developing PyBaMM, have a look at
 
 PyBaMM follows the [PEP8 recommendations](https://www.python.org/dev/peps/pep-0008/) for coding style. These are very common guidelines, and community tools have been developed to check how well projects implement them. We recommend using pre-commit hooks to check your code before committing it. See [installing and using pre-commit](https://github.com/pybamm-team/PyBaMM/blob/develop/CONTRIBUTING.md#installing-and-using-pre-commit) section for more details.
 
-### Flake8
+### Ruff
 
-We use [flake8](http://flake8.pycqa.org/en/latest/) to check our PEP8 adherence. To try this on your system, navigate to the PyBaMM directory in a console and type
+We use [ruff](https://github.com/charliermarsh/ruff) to check our PEP8 adherence. To try this on your system, navigate to the PyBaMM directory in a console and type
 
 ```bash
-flake8
+python -m pip install pre-commit
+pre-commit run ruff
 ```
 
-Flake8 is configured inside the file `tox.ini`, under the section `[flake8]`, allowing us to ignore some errors. If you think this should be added or removed, please submit an [issue](#issues)
+ruff is configured inside the file `pre-commit-config.yaml`, allowing us to ignore some errors. If you think this should be added or removed, please submit an [issue](#issues)
 
-When you commit your changes they will be checked against flake8 automatically (see [infrastructure](#infrastructure)).
+When you commit your changes they will be checked against ruff automatically (see [infrastructure](#infrastructure)).
 
 ### Black
 
@@ -85,11 +86,11 @@ We use [black](https://black.readthedocs.io/en/stable/) to automatically configu
 black {source_file_or_directory}
 ```
 
-2. Editor: black can be [configured](https://test-black.readthedocs.io/en/latest/editor_integration.html) to automatically reformat a python script each time the script is saved in an editor.
+2. Editor: black can be [configured](https://test-black.readthedocs.io/en/latest/editor_integration.html) to automatically reformat a Python script each time the script is saved in an editor.
 
 If you want to use black in your editor, you may need to change the max line length in your editor settings.
 
-Even when code has been formatted by black, you should still make sure that it adheres to the PEP8 standard set by [Flake8](#flake8).
+Even when code has been formatted by black, you should still make sure that it adheres to the PEP8 standard set by [ruff](#ruff).
 
 ### Naming
 
@@ -111,7 +112,7 @@ On the other hand... We _do_ want to compare several tools, to generate document
 1. Core PyBaMM: A minimal set, including things like NumPy, SciPy, etc. All infrastructure should run against this set of dependencies, as well as any numerical methods we implement ourselves.
 2. Extras: Other inference packages and their dependencies. Methods we don't want to implement ourselves, but do want to provide an interface to can have their dependencies added here.
 3. Documentation generating code: Everything you need to generate and work on the docs.
-4. Development code: Everything you need to do PyBaMM development (so all of the above packages, plus flake8 and other testing tools).
+4. Development code: Everything you need to do PyBaMM development (so all of the above packages, plus ruff and other testing tools).
 
 Only 'core pybamm' is installed by default. The others have to be specified explicitly when running the installation command.
 
@@ -214,7 +215,7 @@ This also means that, if you can't fix the bug yourself, it will be much easier
 
    or by just commenting out all the tests you don't want to run.
 
-2. Set break points, either in your IDE or using the python debugging module. To use the latter, add the following line where you want to set the break point
+2. Set break points, either in your IDE or using the Python debugging module. To use the latter, add the following line where you want to set the break point
 
    ```python
    import ipdb; ipdb.set_trace()
@@ -257,7 +258,7 @@ This also means that, if you can't fix the bug yourself, it will be much easier
 
       You can then step through the expression tree, using the `children` attribute, to pinpoint exactly where a bug is coming from. For example, if `expression_tree.jac(y)` is failing, you can check `expression_tree.children[0].jac(y)`, then `expression_tree.children[0].children[0].jac(y)`, etc.
 
-3. To isolate whether a bug is in a model, its jacobian or its simplified version, you can set the `use_jacobian` and/or `use_simplify` attributes of the model to `False` (they are both `True` by default for most models).
+3. To isolate whether a bug is in a model, its Jacobian or its simplified version, you can set the `use_jacobian` and/or `use_simplify` attributes of the model to `False` (they are both `True` by default for most models).
 4. If a model isn't giving the answer you expect, you can try comparing it to other models. For example, you can investigate parameter limits in which two models should give the same answer by setting some parameters to be small or zero. The `StandardOutputComparison` class can be used to compare some standard outputs from battery models.
 5. To get more information about what is going on under the hood, and hence understand what is causing the bug, you can set the [logging](https://realpython.com/python-logging/) level to `DEBUG` by adding the following line to your test or script:
 
@@ -340,9 +341,9 @@ Adding the command
 pybamm.print_citations()
 ```
 
-to the end of a script will print all citations that were used by that script. This will print bibtex information to the terminal; passing a filename to `print_citations` will print the bibtex information to the specified file instead.
+to the end of a script will print all citations that were used by that script. This will print BibTeX information to the terminal; passing a filename to `print_citations` will print the BibTeX information to the specified file instead.
 
-When you contribute code to PyBaMM, you can add your own papers that you would like to be cited if that code is used. First, add the bibtex for your paper to [CITATIONS.txt](pybamm/CITATIONS.txt). Then, add the line
+When you contribute code to PyBaMM, you can add your own papers that you would like to be cited if that code is used. First, add the BibTeX for your paper to [CITATIONS.txt](pybamm/CITATIONS.txt). Then, add the line
 
 ```python3
 pybamm.citations.register("your_paper_bibtex_identifier")
@@ -368,7 +369,7 @@ Note that this file must be kept in sync with the version number in [pybamm/**in
 
 Each change pushed to the PyBaMM GitHub repository will trigger the test and benchmark suites to be run, using [GitHub actions](https://github.com/features/actions).
 
-Tests are run for different operating systems, and for all python versions officially supported by PyBaMM. If you opened a Pull Request, feedback is directly available on the corresponding page. If all tests pass, a green tick will be displayed next to the corresponding test run. If one or more test(s) fail, a red cross will be displayed instead.
+Tests are run for different operating systems, and for all Python versions officially supported by PyBaMM. If you opened a Pull Request, feedback is directly available on the corresponding page. If all tests pass, a green tick will be displayed next to the corresponding test run. If one or more test(s) fail, a red cross will be displayed instead.
 
 Similarly, the benchmark suite is automatically run for the most recently pushed commit. Benchmark results are compared to the results available for the latest commit on the `develop` branch. Should any significant performance regression be found, a red cross will be displayed next to the benchmark run.
 

GOVERNANCE.md

@@ -0,0 +1,139 @@
+# PyBaMM Governance
+
+The following contains the formal governance structure of the PyBaMM
+project. This document clarifies how decisions are made with respect
+to community interactions, including the relationship between
+open source development and work that may be funded by for-profit
+and non-profit entities.
+
+## Code of Conduct
+
+The PyBaMM community strongly values inclusivity and diversity. Everyone
+should treat others with the utmost respect. Everyone in the community
+must adhere to the
+[Code of Conduct](https://github.com/pybamm-team/PyBaMM/blob/develop/CODE-OF-CONDUCT.md) which
+reflects the values of our community. Violations of the code should be
+reported to members of the steering council, where the offenses will be
+handled on a case-by-case basis.
+
+## Current Steering Council
+
+- [Ferran Brosa Planella](https://www.brosaplanella.xyz)
+- [Saransh Chopra](https://saransh-cpp.github.io)
+- Scott Marquis
+- [Gregory Offer](https://www.imperial.ac.uk/people/gregory.offer)
+- [Valentin Sulzer](https://sites.google.com/view/valentinsulzer)
+
+## Advisory Committee
+
+TBA
+
+# Governing Rules and Duties
+
+## Steering Council
+
+The Project has a Steering Council that consists of Project
+Contributors who have produced contributions that are substantial in
+quality and quantity, and sustained over at least one year. The role
+of the Council is to provide active leadership for the Project in
+making everyday decisions on technical and administrative issues,
+through working with and taking input from the Community.
+
+During the everyday project activities, Council Members participate in
+all discussions, code review and other project activities as peers
+with all other Contributors and the Community. In these everyday
+activities, Council Members do not have any special power or privilege
+through their membership on the Council. However, it is expected that
+because of the quality and quantity of their contributions and their
+expert knowledge of the Project Software and Services that Council
+Members will provide useful guidance, both technical and in terms of
+project direction, to potentially less experienced Contributors.
+
+The Steering Council and its Members play a special role in certain
+situations. In particular, the Council may:
+
+- Make decisions about the overall scope, vision and direction of
+  the project.
+- Make decisions about strategic collaborations with other
+  organizations or individuals.
+- Make decisions about specific technical issues, features, bugs and
+  pull requests. They are the primary mechanism of guiding the code
+  review process and merging pull requests.
+- Make decisions about the Services that are run by the Project and
+  manage those Services for the benefit of the Project and Community.
+- Make decisions when regular community discussion does not produce
+  consensus on an issue in a reasonable time frame.
+
+Steering Council decisions are taken by simple majority, with the
+exception of changes to the Governance Documents which follow the
+procedure in the section 'Changing the Governance Documents'.
+
+### Steering Council membership
+
+To become eligible for being a Steering Council Member, an individual
+must be a Project Contributor who has produced contributions that are
+substantial in quality and quantity, and sustained over at least one
+year. Potential Council Members are nominated by existing Council
+Members or by the Community and voted upon by the existing Council
+after asking if the potential Member is interested and willing to
+serve in that capacity.
+
+When considering potential Members, the Council will look at
+candidates with a comprehensive view of their contributions. This will
+include but is not limited to code, code review, infrastructure work,
+mailing list and chat participation, community help/building,
+education and outreach, design work, etc. We deliberately do not
+set arbitrary quantitative metrics to avoid encouraging behavior
+that plays to the metrics rather than the project's overall well-being.
+We want to encourage a diverse array of backgrounds, viewpoints and
+talents in our team, which is why we explicitly do not define code as
+the sole metric on which Council membership will be evaluated.
+
+If a Council Member becomes inactive in the project for a period of
+one year, they will be considered for removal from the Council. Before
+removal, the inactive Member will be approached by another Council
+member to ask if they plan on returning to active participation. If
+not they will be removed immediately upon a Council vote. If they plan
+on returning to active participation soon, they will be given a grace
+period of one year. If they do not return to active participation
+within that time period they will be removed by vote of the Council
+without further grace period. All former Council members can be
+considered for membership again at any time in the future, like any
+other Project Contributor. Retired Council members will be listed on
+the project website, acknowledging the period during which they were
+active in the Council.
+
+The Council reserves the right to eject current Members if they are
+deemed to be actively harmful to the Project's well-being, and
+attempts at communication and conflict resolution have failed.
+
+## Fiscal Decisions
+
+All fiscal decisions are made by the steering council to ensure any
+funds are spent in a manner that furthers the mission of the Project.
+Fiscal decisions require majority approval by acting steering council
+members.
+
+## Advisory Committee
+
+The Project will consider setting up an Advisory Committee that works to ensure the long-term
+well-being of the Project. The role of the Committee will be to advise the Steering Council.
+
+## Conflict of interest
+
+It is expected that Steering Council and Advisory Committee Members
+will be employed at a wide range of companies, universities and non-profit
+organizations. Because of this, it is possible that Members will have
+conflicts of interest. Such conflicts of interest include, but are not
+limited to:
+
+- Financial interests, such as investments, employment or contracting
+  work, outside of the Project that may influence their work on the
+  Project.
+- Access to proprietary information of their employer that could
+  potentially leak into their work with the Project.
+
+All members of the Council and Committee shall disclose any conflict of
+interest they may have. Members with a conflict of interest in a
+particular issue may participate in Council discussions on that issue,
+but must recuse themselves from voting on the issue.