In my opinion, it should be avoided that for relevant properties concerning the software, e.g. aggregation methods, a lookup in further literature (here Patil et. al) is necessary to understand the paper, since this is one of the major arguments to use your software
Summary:
In my opinion, the description of ETHOS takes up too much of the paper. It should be explained in more detail what I can use the ETHOS.FINE software you submitted for. Rather answer the question what ETHOS.FINE exactly does in the ETHOS cosmos.
The TSAM subpackage should also only play a subordinate role, as it is used by the software you have submitted but is not a major part of it.
Method section:
The methods section remains very general; you should avoid simply referring to Welder's dissertation. Instead, it should be summarized what the model basis looks like and which logics it is following.
Unfortunately, I also have to mention this point in the context of the documentation (see ...), as only the general API documentation can be found here. There is no detailed description of what is done e.g. with the storage or energy system model class. Why don't you take parts of Welder's dissertation in the documentation and include the model and mathematical background?
Statement of Need:
This section should be more detailed. You merely note that Groissböck's paper states that individual tools available on the market do not provide the functionalities you require. You should specify which functions are involved and validate that the statements made by Groissböck in 2018 are still relevant today since the paper is more or less 6 years old. Some of the key functions of your tool were highlighted in Welder's dissertation and can be copied and referenced.
You highlight the applicability of your tool for newcomers without programming experiance. That point is not propperly adressed in your documentation, since there is no general introduction to your tool and its logic. For this use case, the hurdle of getting started must be overcome by a guided full-text documentation from installation to the first simple energy system with a description of the individual parameters. Again, you can make partial use of Welder's dissertation, as it already explains some if not all of the parameters. See also issue #49 here.
--> After you have highlighted the key functionalities more precisely, I would suggest to include the statement of need into your documentation. This will provide a quick basic understanding of the scope of your software when finding the documentation on RTD or the repository on Github.
References:
The dissertation of Welder does not have the right ISBN. During the check of the methodological background I had to search for the right dissertation.
Please check if the rest of your references is linked correctly.
Hi, this an issue about your paper from JOSS Review 6274.
General:
Summary:
Method section:
Statement of Need:
--> After you have highlighted the key functionalities more precisely, I would suggest to include the statement of need into your documentation. This will provide a quick basic understanding of the scope of your software when finding the documentation on RTD or the repository on Github.
References:
Kind regards @GregorBecker