search

OSeMOSYS / OSeMOSYS_GNU_MathProg

The GNU MathProg implementation of OSeMOSYS
Apache License 2.0
9 stars 14 forks source link

Make output file a parameter #31

Closed tniet closed 4 years ago

tniet commented 4 years ago

Made a parameter called SelectedResultsFile so it is possible to specify the output file in the parameters file. Updated Simplicity and utopia model files to match.

This change allows one parameter to specify a change to the output file. This is especially useful when running multiple scenarios since this allows the parameter file for each scenario to have a different output file specified, preventing collisions between outputs of different model runs even if the different scenarios are running in the same folder.

willu47 commented 4 years ago

Hi @tniet - many thanks for this.

Manually editing the model file to specify the location of the results has always been a problem. However, I'm not sure this covers all the bases yet?

For example:

  1. would it be better to call the parameter ResultsPath. This could then be applicable for the summary results which are currently printed out, as well another case where you have a folder containing multiple csv files created by tout commands (as with model files generated by Momani for example). Ideally, this path should be any absolute or relative location.
  2. one weakness of the current set up is that when running multiple scenarios from the one model file, each of the result files is overwritten by the subsequent run. We could rename this parameter Scenarioname, which would be more in-keeping with the conceptualisation embedded in Momani, where results are linked to scenarios, which inherit the basic model structure and data from a Model (or parent scenario). Then we could name result files according to the ScenarioName.
tniet commented 4 years ago

Hi @willu47

I like adding a separate ResultsPath variable that would allow for specifying the path to the output file as well as the specific file name. If users want to use the current directory they could specify ".". And that's an easy addition to the structure.

In terms of naming the parameter I'm not sure ScenarioName is clear as to what the parameter does (or how I want it to work). Would we use this to then create a structured output such as: ResultsPath&ScenarioName&"SelectedResults.csv" Then the file is still always called "SelectedResults.csv", and in my view that doesn't solve the issue.

With both a ResultsPath and a SelectedResultsFile parameter then I think it's closer to what we're looking for. MoManI output could be redirected to the ResultsPath with the required filenames for MoManI, and the SelectedResultsFile can be renamed to the users' needs/wants.

tniet commented 4 years ago

Hi @willu47

And a question about Travis CI - I changed the parameter files to match the updated structure with OSeMOSYS short. Are the failed checks due to Travis CI using OSeMOSYS long to run the checks? If so, we need to have some way of indicating that changes are to the short code only and still need to be ported to the long code (or two separate checks, one for the short version and one for the long version).

And is it possible to get more detailed output from Travis CI? The errors are "Branch" and "Pull Request" which doesn't tell us anything about the actual error that is causing the failure...

Thanks!

willu47 commented 4 years ago

View the full log of Travis CI runs here

willu47 commented 4 years ago

...we need to have some way of indicating that changes are to the short code only and still need to be ported to the long code (or two separate checks, one for the short version and one for the long version). Yep, at the moment, the tests for long and short code versions use the same datafile tests/Utopia.txt to run the tests, so missing the parameter for the long version causes a read error when reading the modified datafile. I've now updated the long osemosys file to match the changes you made in the short version of the code and the tests pass.

But, we still need to decide what to add.

Personally, I would like to do away with SelectedResultsFile.csv and instead produce a folder of CSV files. The format of SelectedResultsFile.csv means that it is not easily readable. It would be better if each section were its own file. If we implemented this, then perhaps we would only need the ResultsPath symbolic parameter?

tniet commented 4 years ago

Hi @willu47

Good point about SelectedResults.csv vs. a list of csv's that output each variable in a folder. The MoManI version of the code uses this second approach and outputs a series of csv files. Maybe we can grab some of the code from the MoManI version using the tout command and then, as you suggest, a results path is more sensible than a file path.

Cheers, Taco..