Release v0.3.6

* Fixes to tutorial

Makefile

@@ -7,5 +7,4 @@ upload:
 clean:
 	rm dist/*
 
-all-dist:
-	sdist upload clean
+all-dist: sdist upload clean

calliope/_version.py

@@ -1 +1 @@
-__version__ = '0.3.5'
+__version__ = '0.3.6'

changelog.rst

@@ -3,6 +3,11 @@
 Release History
 ===============
 
+0.3.6 (2016-09-23)
+------------------
+
+* |fixed| Version 0.3.5 changes were not reflected in tutorial
+
 0.3.5 (2015-09-18)
 ------------------
 

doc/user/introduction.rst

@@ -11,7 +11,7 @@ Calliope was designed to address questions around the transition to renewable en
 
 * `SWITCH <http://switch-model.org/>`_: A power system model focused on renewables integration, using multi-stage stochastic linear optimization, as well as hourly resource potential and demand data. Written in the commercial AMPL language and GPL-licensed [Fripp2012]_.
 * `Temoa <http://temoaproject.org/>`_: An energy system model with multi-stage stochastic optimization functionality which can be deployed to computing clusters, to address parametric uncertainty. Written in Python/Pyomo and AGPL-licensed [Hunter2013]_.
-* `OSEMOSyS <http://www.osemosys.org/>`_: A simplified energy system model similar to the MARKAL/TIMES model families, which can be used as a stand-alone tool or integrated in the `LEAP energy model <http://www.energycommunity.org/LEAP/>`_. Written in GLPK, a free subset of the commercial AMPL language, and Apache 2.0-licensed [Howells2011]_.
+* `OSeMOSYS <http://www.osemosys.org/>`_: A simplified energy system model similar to the MARKAL/TIMES model families, which can be used as a stand-alone tool or integrated in the `LEAP energy model <http://www.energycommunity.org/LEAP/>`_. Written in GLPK, a free subset of the commercial AMPL language, and Apache 2.0-licensed [Howells2011]_.
 
 Additional energy models that are partially or fully open can be found on the `Open Energy Modelling Initiative's wiki <http://wiki.openmod-initiative.org/wiki/Model_fact_sheets>`_.
 

doc/user/tutorial.rst

@@ -106,23 +106,24 @@ Let's now look at the first location definition:
 
 There are several things to note here:
 
-* The location defines a level (0). The current version of Calliope allows only two levels: 0 and 1. Transmission between locations at level 0 can take place if transmission links are defined between them. Transmission between locations at level 0 and 1, on the other hand, is unlimited. Level 1 locations can be grouped within level 0 locations, all level 1 locations plus the containing level 0 location are implicitly on a "copperplate" with no transmission constraints. Finally, balancing of supply and demand takes place only at level 0, so a model needs to define at least one level 0 location.
 * The location specifies a list of technologies that it allows (``techs``). Note that technologies listed here must have been defined elsewhere in the model configuration.
 * It also overrides some options for both ``demand_power`` and ``ccgt``. For the latter, it simply sets a location-specific maximum capacity constraint. For ``demand_power``, the options set here are related to reading the demand time series from a CSV file. CSV is a simple text-based format that stores tables by comma-separated rows. Note that we did not define any ``r`` option in the definition of the ``demand_power`` technology. Instead, this is done directly via a location-specific override. For this location, the file ``demand-1.csv`` is loaded, and the demand is then scaled such that the demand peak is at the given value. Note that in Calliope, a supply is positive and a demand is negative, so the peak demand is actually a negative value. Finally, the ``x_map`` option allows us to read a CSV file with a single column named "demand" and tell Calliope to load data from that column for region ``r1``. This is necessary unless the column name(s) in the CSV file already correspond to the location names defined in the model configuration.
 
 The remaining location definitions look like this:
 
 .. literalinclude:: ../../calliope/example_model/model_config/locations.yaml
    :language: yaml
-   :lines: 19-32
+   :lines: 18-29
 
-``r2`` is very similar to ``r1``, except that it does not allow the ``ccgt`` technology. The three ``csp`` locations are defined together, i.e. they each get the exact same configuration. They are ``within`` the location ``r1`` and allow only the ``csp`` technology, this allows us to model three possible sites for CSP plants within ``r1`` (i.e., with no transmission constraints from these locations to ``r1`` or other locations within ``r1``).
+``r2`` is very similar to ``r1``, except that it does not allow the ``ccgt`` technology. The three ``csp`` locations are defined together, i.e. they each get the exact same configuration. They are ``within`` the location ``r1`` and allow only the ``csp`` technology, this allows us to model three possible sites for CSP plants within ``r1``.
 
-For transmission technologies, the model also needs to know which level 0 locations can be linked, and this is set up in the model configuration as follows:
+Locations that do not specify a ``within`` are implicitly at the topmost level. Transmission between locations at the topmost level can only take place if transmission links are defined between them. On the other hand, locations which are specified as ``within`` another location can automatically and without any losses transmit energy to and from their parent location. In other words, a topmost location and all its contained locations together are implicitly assumed to be on a "copperplate" with no transmission constraints. Balancing of supply and demand takes place only at the topmost level.
+
+For transmission technologies, the model also needs to know which top-level locations can be linked, and this is set up in the model configuration as follows:
 
 .. literalinclude:: ../../calliope/example_model/model_config/locations.yaml
    :language: yaml
-   :lines: 38-42
+   :lines: 35-40
 
 ---------------------------
 Files that define the model