Allow model and inputs+defs to reside in different directories.

[jrawbits]

For a variety of runtime reasons, I'd like to be able to put the model script in a different folder than the folder that contains "defs" and "inputs" and that holds the outputs. It's easy to do just by exposing the model script file parameter. The fix is entirely transparent (due to defaults, no existing model script needs to be changed). Also, on the defaults, it is very important to use consistent capitalization ("Run_Model.R") and to ensure that the model script file itself is named exactly like that: otherwise the models crash unpredictably on Linux (and possibly on Mac) due to file system case sensitivity.

[jrawbits]

This fix should apply readily to any of the current VisionEval branches.

[bstabler]

@jrawbits - please review the suggested revisions with respect to the tests that run the models, including with the GUI, since these are not passing. Thanks.

[jrawbits]

I'll figure this out once we have everything merged. I think it is inconsistency in file name format (upper/lower case) mostly. But I didn't look closely at what might be malfunctioning in VEGUI and the rest though I wouldn't be surprised if is the same problem.

[landisrm]

VEGUI doesn't currently pay much attention to what is happening in run_model.R. It makes a lot of assumptions about what the file names are, and it only works currently because it's assumptions happen to be consistent with the way things are specified in initializeModel. See Issue 245. That might have something to do with the tests failing.

Another point is that it would be great if we could avoid having to specify the path of a file within itself, as in Run_Model.R, which specifies:

initializeModel(
  ModelScriptFile = "../Run_Model.R",
  ParamDir = "defs",

This seems like an easy place to make confusing mistakes.

If run_model.R (or Run_Model.R, it shouldn't matter which) is called via Rscript or source, we could easily get the path to it for parseModelScript and we wouldn't have to manually specify it in initializeModel. The "run_model" script could also be named arbitrarily, which should be allowed.

[jrawbits]

What I'm envisioning ultimately is simply being able to throw an "initialize" structure at the VisionEval Framework (i.e. the set of parameters to initializeModel, enhanced to allow full specification of where everything is), and put the actual lines of model (runModule) in an entirely separate file. So it's not "Run_Model.R" referring to itself, but initializeModel referring to another file that has all the model steps - that would make it much easier to run the same model steps on a mountain of different input scenarios. So you'd do something like this to run a model on a scenario:

visioneval::initializeModel (
ModelScript = "models/VERSPM/VERSPM-Steps.R",
ParamDir = "models/VERSPM/Test1/defs",
InputDir = "models/VERSPM/Test1/Scenario1",
... etc. ...
)
visioneval::Run()

Where the (currently non-existent) Run function just executes the model setup that was processing by initializeModel. Probably might be able to just collapse initializeModel and Run into a single function call.

[landisrm]

I see, that makes sense to me. It seems reasonable that visioneval::initializeModel would just call "Run" at the end. Basically, you would just have a function that provides the locations of the model steps and all of the input files (which can all be arbitrary full paths) and then runs the model.

So we're just saying that run_model.R only has the model steps, not the initializeModel function. Then initializeModel needs to point to the model steps.

[jrawbits]

Exactly.

[landisrm]

Currently, initializeModel parses run_model.R and creates a data.frame of the module calls available in getModelState()$ModuleCalls_df.

What if instead of having a script that calls runModule (i.e. @jrawbits VERSPM-Steps.R above), we specify the module calls in a CSV that is just like ModuleCalls_df. Then all run_model.R does is call initializeModel with the proper pointers to files. In initializeModel, visioneval::parseModelScript simply reads the CSV into a data.frame.

[landisrm]

Updated this PR in #247.