Skip to content

Commit 4bf4880

Browse files
authored
More docs fixes (#813)
* Clearer documentation for existing capacity file * Documentation for making a new release
1 parent 8c73dda commit 4bf4880

File tree

3 files changed

+43
-9
lines changed

3 files changed

+43
-9
lines changed

docs/developer-guide.rst

Lines changed: 26 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,26 @@
1+
Developer Guide
2+
===============
3+
4+
This is a work-in-progress guide for developers.
5+
6+
Making a new release
7+
--------------------
8+
9+
The process for making a new release of MUSE is simple:
10+
11+
- Check the current version number. The best way to do this is to look at the latest
12+
tagged release on `GitHub <https://github.com/EnergySystemsModellingLab/MUSE_OS/releases>`_.
13+
- Decide on the new version number, incrementing the second
14+
digit for major changes (e.g. ``v1.2.5`` -> ``v1.3.0``), or the third digit for minor changes
15+
(e.g. ``v1.2.5`` -> ``v1.2.6``). Note the the first digit must NOT be incremented as this
16+
is reserved for the `MUSE2 project <https://github.com/EnergySystemsModellingLab/MUSE2>`_.
17+
- Update the version number and date in ``CITATION.cff``
18+
- Write a release notes document in ``docs/release-notes/`` for the new version, following the
19+
template of previous release notes. Make sure to link this in ``docs/release-notes/index.rst``.
20+
- On GitHub, go to "Releases" -> "Draft a new release". Create a new tag named after the
21+
new version number (e.g. "v1.3.0"), and give the release a matching title.
22+
Then click "Publish release".
23+
- This will automatically trigger a new release on `PyPI <https://pypi.org/project/MUSE-OS/>`_,
24+
a new DOI on `Zenodo <https://zenodo.org/records/14832641>`_, and
25+
a new documentation build on `ReadTheDocs <https://muse-os.readthedocs.io/en/latest/>`_.
26+
Allow some time for these to complete, then check that everything looks correct.

docs/index.rst

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -23,6 +23,7 @@ ModUlar energy system Simulation Environment: MUSE
2323
inputs/index
2424
user-guide/index
2525
advanced-guide/index
26+
developer-guide
2627
faq
2728
api
2829
release-notes/index

docs/inputs/existing_capacity.rst

Lines changed: 16 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -4,12 +4,17 @@
44
Existing Capacity
55
==========================
66

7-
This file provides the installed capacity in base year and the decommissioning
8-
profile in the future periods for each technology in a sector, in each region.
9-
10-
Each sector should have an existing capacity file, which should follow the structure
11-
reported in the table below, and be referenced from the TOML settings file using the
12-
``existing_capacity`` key.
7+
Each sector must have an existing capacity file, which defines the total capacity of all
8+
pre-defined assets in that sector. This data must be given in the form of a decommissioning
9+
profile, which shows how much capacity of each technology exists in each region at the
10+
start of the simulation, and how it is expected to decline over time as these assets are
11+
decommissioned. Any assets installed *by MUSE* during the simulation will be added on
12+
top of this existing capacity.
13+
14+
This file should follow the structure shown in the example table below, and be referenced from
15+
the TOML settings file using the ``existing_capacity`` key. For example, in this case,
16+
the file shows that in region1 there is 5 MW of existing residential electric boiler
17+
capacity in 2010, of which 0.5 MW will remain active in 2020, and none will remain by 2030.
1318

1419
.. csv-table:: Existing capacity of technologies: the residential boiler example
1520
:header: technology, region, 2010, 2020, 2030, 2040, 2050
@@ -18,10 +23,12 @@ reported in the table below, and be referenced from the TOML settings file using
1823
resBoilerElectric, region2, 39, 3.5, 1, 0.3, 0
1924

2025
``technology``
21-
represents the technology ID and needs to be consistent across all the data inputs.
26+
represents the technology ID, which must match a technology defined in the
27+
sector's technodata file.
2228

2329
``region``
24-
represents the region ID and needs to be consistent across all the data inputs.
30+
represents the region ID, which must match a region defined in the settings TOML.
2531

2632
Years (one column per year)
27-
represent the simulated periods.
33+
represent the years in the simulation. The values in these columns represent
34+
the total installed capacity of the technology in the given year/region.

0 commit comments

Comments
 (0)