minor revisions

paper/paper.bib

@@ -199,6 +199,7 @@ @software{huppmann2021
     volume={1},
     journal={Open Research Europe},
     title = {pyam: analysis and visualization of integrated-assessment and macro-energy scenarios [version 2; peer review: 3 approved]},
+    year = {2021},
 }
 
 @article{kiviluoma2021,

paper/paper.md

@@ -37,7 +37,7 @@ The Open Source energy MOdelling SYStem, or OSeMOSYS [@howells2011], is a highly
 
 Compared to other open energy modelling frameworks that are based around a single (Python) implementation, such as PyPSA [@pypsa2018] and Calliope [@Pfenninger2018], the OSeMOSYS framework does not have standard data processing functions. For example, in PyPSA, users instantiate a `Network` object which has methods to import data (from various formats such as CSV, netCDF, and pypower), manipulate data, build and solve the model, and export results. In contrast, users of OSeMOSYS are required to prepare the input data and process results data themselves. otoole addresses the need in the OSeMOSYS community to standardize data handling functions across multiple different model implementations.
 
-Utilities to facilitate data management in energy system models have existed for as long as the energy system modelling frameworks themselves. For example, see the proprietary solutions [TIMES-VEDA](https://iea-etsap.org/index.php/etsap-tools/data-handling-shells/veda) and [PLEXOS](https://www.energyexemplar.com/), or the open-source solutions pyam[@huppmann2021] and Spine-Toolbox[@kiviluoma2021]. These utilities offer some similar functionality to otoole but are often tailored to specific frameworks (in the case of proprietary solutions), focus on workflow management, or are concerned with result analysis rather than data processing. Given the flexible nature of OSeMOSYS, many different models exist with unique parameters, variables, and constraints. The OSeMOSYS community requires a tool to process input and result data regardless of model structure and implementation.
+Utilities to facilitate data management in energy system models have existed for as long as the energy system modelling frameworks themselves. For example, see the proprietary solutions [TIMES-VEDA](https://iea-etsap.org/index.php/etsap-tools/data-handling-shells/veda) and [PLEXOS](https://www.energyexemplar.com/), or the open-source solutions pyam [@huppmann2021] and Spine-Toolbox [@kiviluoma2021]. These utilities offer some similar functionality to otoole but are often tailored to specific frameworks (in the case of proprietary solutions), focus on workflow management, or are concerned with result analysis rather than data processing. Given the flexible nature of OSeMOSYS, many different models exist with unique parameters, variables, and constraints. The OSeMOSYS community requires a tool to process input and result data regardless of model structure and implementation.
 
 otoole supports three different input file formats: wide-format Excel files (pivoted on the year index), long-format CSV files, and GNU MathProg files. With otoole, users can convert between any of these formats to meet their skill level and workflow requirements. Furthermore, otoole can process result solution files from the open-source solvers GLPK [@GNULinearProgramming2012] and CBC [@forrest2022], and the commercial solvers Gurobi [@gurobioptimizationllcGurobiOptimizerReference2022] and CPLEX [@ibmCPLEXUsersManual2022], into tabulated CSV results.
 
@@ -53,13 +53,13 @@ The development of otoole was originally mentioned in [@niet2021] through a disc
 
 While otoole was originally created to assist MathProg OSeMOSYS modellers, its functionality can easily extend to other implementations of OSeMOSYS, and any workflow that uses non-OSeMOSYS MathProg data files.
 
-otoole follows a strategy design pattern [@gamma1994, p.315]. Two abstract base classes define how otoole reads and writes data, named ReadStrategy and WriteStrategy respectively. The ReadStrategy class reads model data or result data into an internal data structure (currently a dictionary of pandas DataFrames). While the WriteStrategy class writes out data to a format specified by the user. The ReadResults abstract class is responsible for calculating intermediate results if required. A schematic of this design pattern is shown in \autoref{fig:design-pattern}.
+otoole follows a strategy design pattern [@gamma1994, p.315]. Two abstract base classes define how otoole reads and writes data, named ReadStrategy and WriteStrategy respectively. The ReadStrategy class reads model data or result data into an internal data structure (currently a dictionary of pandas DataFrames), with a ReadResults abstract class responsible for calculating intermediate results if required. The WriteStrategy class writes out data into a format specified by the user. A schematic of this design pattern is shown in \autoref{fig:design-pattern}.
 
 ![otoole Design Pattern \label{fig:design-pattern}](images/class-diagram.png)
 
 The advantage of designing otoole around a strategy pattern is that it allows for the easy addition of new file formats and model implementations. For example, there are existing OSeMOSYS implementations written in Python and GAMS, and new implementations may be created in the future. New reading and writing classes can easily add data conversion into and out of these formats. This is especially useful for benchmarking each implementation against one another to check for inconsistencies, measure performance, or to migrate OSeMOSYS models from one format to another. This same extensibility logic applies to the reading of results. For example, support for the new open-source solver, HiGHS [@huangfu2018], can be added through a class that inherits from ReadResults and implements reading logic specific to HiGHS.
 
-When converting between formats, the user supplies otoole with a configuration file that describes the parameters, sets, and variables in the model. This allows otoole to work with any version of OSeMOSYS regardless of the model's parameters, sets, or variables. This is particularly useful for extensions of OSeMOSYS, such of the Climate, Land, Energy, and Water framework [@bazilian2011], which adds parameters to OSeMOSYS to represent other energy sectors. Moreover, describing the model through a configuration file allows otoole to work with any MathProg model file; not just OSeMOSYS models.
+When converting between formats, the user supplies otoole with a configuration file that describes the parameters, sets, and variables in the model. This allows otoole to work with any version of OSeMOSYS regardless of the model's parameters, sets, or variables. This is particularly useful for extensions of OSeMOSYS, such as the Climate, Land, Energy, and Water framework [@bazilian2011], which adds parameters to OSeMOSYS to represent other energy sectors. Moreover, describing the model through a configuration file allows otoole to work with any MathProg model file; not just OSeMOSYS models.
 
 # Installation and Example