Multiple IC paths passed to write.configs

[infotroph]

Bug Description

Per Slack discussion with @mdietze: PEcAn's intended sampling model is that ensembles are created at the PEcAn level and then the configurations are passed, one at a time, for write.configs. to set up a model invocation parameterized to match the configuration it was given.

The current implementation does not do this for initial conditions. Instead the entire set of IC files is passed on to the model config function, where each model has to handle it themself. For example write.configs.SIPNET just picks one at random.

in Slack, @mdietze recommended "if the whole ensemble of poolinitcond paths is being passed to write configs then write configs should be updated to stop with an error and we should fix that before continuing"

As I write this I realize the problem might go deeper -- since write.ensemble configs is called inside run.write.configs, which is itself called from runModule.run.write.configs for each site separately, we may need to climb quite a ways back up the stack to preserve ensemble information correctly across sites.

[mdietze]

Short term priority is to make sure vector inputs are not being passed to write.configs.[MODEL]. As a temporary stop gap, I think we should definitely add checks to write.ensemble.configs to make sure that no vector inputs are passed to write.configs.[MODEL], as this is more efficient than putting such checks in each model's write.configs, and that the code stops with an informative error message. I also suspect that the lack of input sampling may be an issue with the user's pecan.xml not a code design issue (e.g. setting up an input to be ensemble based but not adding info about how that input should be sampled).

For the larger issue of correctly sampling ensembles across sites, we should also check whether this is being done correctly in the SDA code @DongchenZ @Qianyuxuan

So as a partial solution to help move towards doing this, a few years back I had a student take a first rough crack at the Sobol uncertainty partitioning, and as part of that she created an un-committed version of ensemble.R (which includes write.ensemble.configs) that has the ability to both save an ensemble design (both inputs and parameters) and to pass such a design back in as a new argument, samples. This code is a rough first pass, and will require refactoring/rethinking, but I put a copy of this code in this gist for reference: https://gist.github.com/mdietze/ae26dd0c6115ca1a527d15e438572348

Note that this issue is directly relevant to GSOC students interested in the Sobol project

Once write.ensemble.configs can take a design as an input, it should be relatively easy to all pass it into run.write.configs, etc. but it will be a bit of work to pull the code that does the ensemble sampling out of write.ensemble.configs and do that sampling prior to looping over sites.