Streamline the rSFSTEP2 interface

Currently, there is no interface for running rSFSTEP2. The user must manually call cloneSTEPWAT2.sh, generate_rSFSTEP2_structure.sh, run_local.sh, call_sbatch.sh, call_sbatch_database.sh, run_local_database.sh, copycats.sh, and compareFiles.sh.

It would be convenient if instead of calling scripts individually there was one master script that called the individual scripts in the correct order. Instead of inputting the script name and the parameters we would input flags to the master program along with the parameters. I propose we call the master program rSFSTEP2 to make it clear that it wraps the entire wrapper.

Implementation

The master program could be written in C, but we would then have to compile it. Adding a compilation step makes no sense because we are trying to speed up the process, not slow it down. We could ship the pre-compiled program with rSFSTEP2, but this wouldn't allow the compiler to target an operating system and we wouldn't be able to debug on the fly.

Therefore, the implementation should be in Python. Python is interpreted (not compiled) and cross-platform. There is already a Python script in rSFSTEP2, so we are guaranteed that the user already has Python installed. I (@chaukap) am comfortable working in Python so I could implement it quickly.

Example

To run locally we currently call

./cloneSTEPWAT2.sh
./generate_rSFSTEP2_structure.sh <file path> <sites> <scenarios>
./run_local.sh <sites>
./compareFiles.sh <sites>

As you can see, we make four calls and reuse the site parameter 3 times. My proposal is to create a Python script that would look something like

python rSFSTEP2 -d -g -l -c --path <file path> --sites <sites> --scen <scenarios>

where

-d means download STEPWAT2
-g means generate the file structure
-l means run locally
-c means compare files
--path specifies the path to the R_program folder
--sites specifies the number of sites
--scen specifies the number of scenarios

The program would then make the calls in the correct order.

Pros

Less manual input.
No waiting for one script to finish to call the next. They will be called automatically.
No reuse of input parameters, specifically site.
Error checking.
- The master program could error out if scripts are called out of order and provide more detailed explanations. Better yet, if you failed to provide critical input like scenarios, the program ask for the information instead of giving up.

Cons

Learning curve.
- There would be all new flags to learn, which would take some time.

DrylandEcology / rSFSTEP2