Input/Output Path Structure

[ddbaptiste]

Issue #16 requests that RESPONDv2 creates outputs in relative paths closer to the inputs.

There are various ways that we can go about this, each with their own merits and weaknesses.
In the next sections, I've explained a few approaches I considered.

So far, I've not found a single solution that I think is ideal, so any insight or opinions into what we should do here are welcomed!

A Simple Approach

A simple approach would be for the output folders to be created in the same directory as the inputs. For example, for the command

src/respond "inputs" 1 6

the resultant folder inputs/ would be

inputs
├── input_set1
├── input_set2
├── input_set3
├── input_set4
├── input_set5
├── output1
├── output2
├── output3
├── output4
└── output5

This has the advantages of being simple to implement and being quite intuitive to the user, but it is also very inflexible and can create a lot of clutter when running many simulations (this can lead to slowdowns when attempting to index/browse files after runs).

Local Configuration

Another option is to add a parameter to each input folder's sim.conf specifying the location to save the output. I think that this is cumbersome from an analyst perspective, so this is not desirable.

Global Configuration

We can read a configuration file in the root project folder (e.g. RESPONDSimulationv2/RESPOND.conf), where global information such as where to save outputs is located. I think that this route would create clutter, which works against one of the central motivations of the rewrite, making the inputs less spread out and easier to work with.

[MJC598]

I must say, I am immediately not a fan of outputs existing inside an inputs folder

[MJC598]

Why don't we create a file structure that discards all contents except .gitkeeps and have analysts drop files there? It would remove the option but standardize the process

[ddbaptiste]

I agree that I don't love the idea of outputs living in an input folder, but that's a matter of what the user names the folder containing their inputs.

Why don't we create a file structure that discards all contents except .gitkeeps and have analysts drop files there? It would remove the option but standardize the process

Are you suggesting that we keep things how they already are, i.e. have the build/outputs/ directory where outputs are created by default? Or am I misunderstanding?

Pinging @hczwick for an analyst perspective as well.

[hczwick]

I think keeping the outputs in build/outputs just puts them really far away - for me it's less annoying to specify in the sim.conf where I want the outputs to go. The most intuitive way for me would be something like this, where the output folder and input folder sit right next to each other

[ddbaptiste]

The most intuitive way for me would be something like this, where the output folder and input folder sit right next to each other

This, I certainly agree with.

Something like this

screening
├── some-change
│   ├── input1
│   ├── input2
│   ├── input3
│   ├── output1
│   ├── output2
│   └── output3
└── status-quo
    ├── input1
    ├── input2
    ├── input3
    ├── output1
    ├── output2
    └── output3

could be a solid middle-ground, maintaining the ability to understand the meaning of the data and keeping inputs and outputs together. A folder like the scripts/ folder in your example could be included under screening/, i.e. screening/scripts/.

[ddbaptiste]

How could I have failed to present the most obvious approach of all?!

Runtime Input

We can change the command used to call the simulation such that it takes another argument, e.g.

src/respond <input folder> <output folder> <run start #> <run end #+1>

[ddbaptiste]

The conclusion landed on here is sufficient. Closing.