Merge branch 'develop' into fix-submesh-equation

Author: valentinsulzer

.all-contributorsrc

@@ -550,7 +550,18 @@
       "avatar_url": "https://avatars.githubusercontent.com/u/112731474?v=4",
       "profile": "https://github.com/iatzak",
       "contributions": [
-        "doc"
+        "doc",
+        "bug",
+        "code"
+      ]
+    },
+    {
+      "login": "ayeankit",
+      "name": "Ankit Kumar",
+      "avatar_url": "https://avatars.githubusercontent.com/u/72691866?v=4",
+      "profile": "https://github.com/ayeankit",
+      "contributions": [
+        "code"
       ]
     }
   ],

.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/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

.github/workflows/url_checker.yml

@@ -13,7 +13,7 @@ jobs:
       - name: Checkout
         uses: actions/checkout@v3
       - name: URLs-checker
-        uses: urlstechie/urlchecker-action@0.0.31
+        uses: urlstechie/urlchecker-action@master
         with:
           # A comma-separated list of file types to cover in the URL checks
           file_types: .rst,.md,.py,.ipynb

.gitignore

@@ -6,6 +6,7 @@
 *.DS_Store
 *.mat
 *.csv
+*.hidden
 
 # don't ignore important .txt and .csv files
 !requirements*
@@ -61,9 +62,6 @@ dist/
 coverage.xml
 htmlcov/
 
-# black setup file seems to make Travis CI fail
-pyproject.toml
-
 # virtual enviroment
 env/
 venv/

.pre-commit-config.yaml

@@ -10,11 +10,12 @@ repos:
         exclude: assets/js/webapp\.js
 
   - repo: https://github.com/psf/black
-    rev: 22.12.0
+    rev: 23.1.0
     hooks:
       - id: black
 
-  - repo: https://github.com/PyCQA/flake8
-    rev: 6.0.0
+  - repo: https://github.com/charliermarsh/ruff-pre-commit
+    rev: "v0.0.246"
     hooks:
-      - id: flake8
+      - id: ruff
+        args: [--ignore=E741, --exclude=__init__.py]

CHANGELOG.md

@@ -2,11 +2,25 @@
 
 ## Features
 
-- 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)).
+- Added temperature control to experiment class. ([#2518])(https://github.com/pybamm-team/PyBaMM/pull/2518)
+- The "particle size" option can now be a tuple to allow different behaviour in each electrode([#2672](https://github.com/pybamm-team/PyBaMM/pull/2672)).
+
+## Bug fixes
+
+- Fixed the length scaling for the first dimension of r-R plots ([#2663](https://github.com/pybamm-team/PyBaMM/pull/2663)).
+
+# [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

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
 
@@ -89,7 +90,7 @@ black {source_file_or_directory}
 
 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.
 

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.