.. _contribution_tips:
Contribution tips
#################
Installing from source
======================
Create a code directory where you will install the virtual env and other TORAX
dependencies.
```shell
mkdir /path/to/torax_dir && cd "$_"
```
Where `/path/to/torax_dir` should be replaced by a path of your choice.
Create a TORAX virtual env.
```shell
python3 -m venv toraxvenv
source toraxvenv/bin/activate
```
Download and install the TORAX codebase via http:
```shell
git clone https://github.com/google-deepmind/torax.git
```
or ssh (ensure that you have the appropriate SSH key uploaded to github).
```shell
git clone git@github.com:google-deepmind/torax.git
```
Enter the TORAX directory and pip install the dependencies.
```shell
cd torax; pip install -e .
```
If you want to install with the dev dependencies (useful for running `pytest`
and installing `pyink` for lint checking), then run with the `[dev]`:
```shell
cd torax; pip install -e .[dev]
```
Optional: Install additional GPU support for JAX if your machine has a GPU:
https://jax.readthedocs.io/en/latest/installation.html#supported-platforms
Code reviews
============
All submissions, including submissions by project members, require review. We
use GitHub pull requests for this purpose. Consult
`[GitHub Help] `_ for more
information on using pull requests.
Documentation
=============
If appropriate for the change you are making, please update the documentation
as part of your contribution.
TORAX's documentation is written in `[reStructuredText] `_.
All documentation is found in the torax/docs directory, in .rst files. Please either
modify the existing files or create new files and links as appropriate.
Once you have written your documentation, you can stage it to see how it looks
before you commit it to the repository. To stage your documentation, run the
following command from the docs folder in the TORAX repository:
.. code-block:: console
make html
This will generate the documentation in the `docs/_build/html` directory. You can then view
the documentation by opening the `index.html` file in your browser.
Run ``pwd`` to find the path to the `docs/_build/html` directory and then point your browser
to `file:///path/to/torax/docs/_build/html/index.html`.
The staged documentation is cleaned up from your local repository by running the command:
.. code-block:: console
make clean
Following the submission of your pull request, the documentation will be
automatically regenerated and published to TORAX's readthedocs server.
Testing
=======
TORAX's tests are written in the `[pytest] `_ framework
While all tests are run automatically on GitHub when you push a pull request, it
is a good idea to run them locally while you are developing your feature. Ensure
that you have installed the required developer dependencies (including pytest)
by having run the following command from the TORAX root directory:
.. code-block:: console
pip install -e .[dev]
To run all tests, run the following command from the TORAX root directory:
.. code-block:: console
pytest -n
with `` being the number of processes that you want to use in parallel.
It is recommended to run tests with the environment variable ``TORAX_ERRORS_ENABLED=True`` to
enable full test coverage. However, it is then recommended to revert back to ``TORAX_ERRORS_ENABLED=False``
when running TORAX in production mode, to enable the persistent JAX cache.
To run a specific test, run the following command from the TORAX root directory,
in this case running all the geometry tests.
.. code-block:: console
pytest torax/_src/geometry/tests/geometry_test.py
Further filtering is possible, for example running only the ``test_face_to_cell`` test (in geometry.py):
.. code-block:: console
pytest -k face_to_cell
Which runs any test containing the string expression ``face_to_cell``.
Where appropriate, please add tests for your changes.
An important class of test is the sim test. These are integration tests running
the configs in the ``torax/tests/test_data/`` directory, and comparing to the ground-truth
``.nc`` TORAX outputs found in the same directory. Sim tests can be triggered separately
by a command (from the TORAX root directory) such as:
.. code-block:: console
pytest -n torax/tests/sim_test.py
If any sim tests fail, they write their output to the ``/tmp/torax_failed_sim_test_outputs/.nc``.
This is useful for debugging, and also to stage new output files for replacing the ground-truth files,
if you expect that your change to the code produces different outputs.
To compare the absolute and relative differences between the failed sim tests
to the ground-truth files, run the following command from the TORAX root directory:
.. code-block:: console
python3 torax/tests/scripts/compare_sim_tests.py
This command has the optional flag ``--failed_test_output_dir `` which
takes a directory containing the failed test outputs, instead of the default
directory ``/tmp/torax_failed_sim_test_outputs``.
It is sometimes useful to plot the difference between the ground-truth and a
failed TORAX sim test, either for debugging or to verify that the magnitude of
difference is as expected. To do this, run the following command from the root of
the TORAX repository. Using ``test_qlknnheat`` as an example:
.. code-block:: console
plot_torax --outfile torax/tests/test_data/test_qlknnheat.nc /tmp/torax_failed_sim_test_outputs/test_qlknnheat.nc
If it is deemed that the new outputs should replace the ground-truth files,
they can be copied over using the following command, again with this example working
when run from the TORAX repository root:
.. code-block:: console
python3 torax/tests/scripts/copy_sim_tests.py
Where we also have the optional flag ``--failed_test_output_dir `` which
takes a directory containing the failed test outputs, instead of the default
directory ``/tmp/torax_failed_sim_test_outputs``.
Finally, there are use-cases where it is desirable to rerun all the sim tests,
even if the tests are passing. An example is when the output API changes and we
wish to keep all the test ``.nc`` files up-to-date. In this case, run the following
command from the TORAX root directory:
.. code-block:: console
python3 torax/tests/scripts/run_and_save_all_benchmarks.py
This script has the following optional flags:
* ``--output_dir`` (default ``/tmp/torax_sim_outputs``): directory where to save the outputs
* ``--num_proc`` (default ``16``): number of processes to use
The ``compare_sim_tests.py`` can be used for sanity checking the outputs, and the
``copy_sim_tests.py`` can be used to replace the ground-truth files. Note that the
``--failed_test_output_dir`` flag in the compare and copy scripts needs to be set
to the same output directory as the ``run_and_save_all_benchmarks.py`` script.
Regenerating Unit Test References
=================================
Some unit tests (particularly for physics and geometry calculations) rely on
pre-calculated reference values stored in torax/_src/test_utils/references.json.
If you make a change that intentionally and correctly alters these values, you
will need to regenerate this reference file.
To do this, a dedicated script is provided.
Regenerating All Reference Cases
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
To regenerate all reference cases and overwrite the existing JSON file, run the
following command from the TORAX root directory:
.. code-block:: console
python3 torax/tests/scripts/regenerate_torax_refs.py --write_to_file
For printing a summary of the regenerated values to stdout for quick inspection,
add a ``--print_summary`` flag. For a dry-run with no write, remove the
``--write_to_file`` flag.
Regenerating a Specific Case
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If you only need to update a specific reference case (e.g.,
circular_references), you can specify it with the --case flag.
.. code-block:: console
python3 torax/tests/scripts/regenerate_torax_refs.py --case=circular_references --write_to_file
.. important::
When making changes to the output structure, e.g. adding fields,
a subset of the sim tests will fail. To pass these specific tests, it is
required to update ``implicit.nc``, ``test_changing_config_before.nc``, and
``test_changing_config_after.nc``. However, the recommended workflow when
changing output API is to run the ``run_and_save_all_benchmarks.py`` script,
which also updates the aforementioned files. When doing so, it is further
strongly recommended to afterwards run the ``compare_sim_tests.py`` script to
verify that the changes to the ground-truth files are as expected. For pure
output API changes, these should be zero. Results of ``compare_sim_tests.py``
should be shared in the pull request discussion.