diff --git a/paper/paper.md b/paper/paper.md index cd79b2df..a469d92a 100644 --- a/paper/paper.md +++ b/paper/paper.md @@ -31,7 +31,9 @@ Data handling for energy system optimisation models is a necessary but tedious t # Statement of need -The Open Source energy MOdelling SYStem, or OSeMOSYS [@howells2011], is a highly cited and widely used open-source framework for conducting long-term energy system planning studies [@groissbock2019]. The original, and still highly used, implementation of OSeMOSYS is formulated in the mathematical programming language, [GNU MathProg](https://github.com/OSeMOSYS/OSeMOSYS_GNU_MathProg). While MathProg [@GNULinearProgramming2012] is open-source, fitting with the ethos of OSeMOSYS, it requires all data to be stored in a single large and unwieldy text file. Data edits to this file are tedious, error-prone, and difficult to integrate into automated workflows. Furthermore, model result files are often difficult to interface with unless processing work is first performed. In addition to the MathProg implementation, OSeMOSYS has also been formulated in [PuLP]( https://github.com/OSeMOSYS/OSeMOSYS_PuLP), [Pyomo](https://github.com/OSeMOSYS/OSeMOSYS_Pyomo), [Julia JUMP](https://github.com/sei-international/NemoMod.jl) and [GAMS](https://github.com/OSeMOSYS/OSeMOSYS_GAMS). A software gap exists to provide OSeMOSYS modellers with an easy way to work with different input data formats and process result files. +The Open Source energy MOdelling SYStem, or OSeMOSYS [@howells2011], is a highly cited and widely used open-source framework[^1] for conducting long-term energy system planning studies [@groissbock2019]. The original, and still highly used, implementation of OSeMOSYS is formulated in the mathematical programming language, [GNU MathProg](https://github.com/OSeMOSYS/OSeMOSYS_GNU_MathProg). While MathProg [@GNULinearProgramming2012] is open-source, fitting with the ethos of OSeMOSYS, it requires all data to be stored in a single large and unwieldy text file. Data edits to this file are tedious, error-prone, and difficult to integrate into automated workflows. Furthermore, model result files are often difficult to interface with unless processing work is first performed. In addition to the MathProg implementation, OSeMOSYS has also been formulated in [PuLP]( https://github.com/OSeMOSYS/OSeMOSYS_PuLP), [Pyomo](https://github.com/OSeMOSYS/OSeMOSYS_Pyomo), [Julia JUMP](https://github.com/sei-international/NemoMod.jl) and [GAMS](https://github.com/OSeMOSYS/OSeMOSYS_GAMS). A software gap exists to provide OSeMOSYS modellers with an easy way to work with different input data formats and process result files. + +[^1]: A SCOPUS search for “TITLE-ABS-KEY ( osemosys ) AND LANGUAGE ( english )” returned 81 results between 2018 to 2023. Moreover, the original OSeMOSYS paper has over 550 citations as of September 2023. Compared to other open energy modelling frameworks that are based around a single (Python) implementation, such as PyPSA[@pypsa2018] or 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.