Gab

1. I added a "name" field to all the files listed in TestInput.json - I'm guessing the R code will crash if these are not present in production. It would have been silly to recode without putting this facility in - the plots need to have this information on them.

2. TestInput.json now contains two example benchmark files (i.e. different model outputs for the same site), and I added these files to the repository as TestBenchmark1.nc and TestBenchmark2.nc. These needn't be provided in production - the R code will just check if they're there and use them (add lines to relevant plots) if they are. The "number" field is intended to indicate the rank the user gave to the benchmark - i.e. if this was the user's first nominated benchmark for their MO, number = '1'. in reality this will be a number between 1 and 3 (but passed as a character of course).

3. I changed the test site data files to be a site for which I already had two other MOs available to be benchmarks - file sizes are similar to before.

4. Errors are now part of the output list, as you suggested. Each list item now has an 'error' field which contains a string. There is also a 'bencherror' string, which reports what, if anything, went wrong with adding the user's nominated benchmarks to the plots. For example, some plots (at least for the moment) cannot add benchmark information, and this is noted in the bencherror string for these analyses. Maybe a table with two columns is still warranted for this information.

5. In addition to the "type" field for each analysis in the output structure, I've added an 'analysistype' and 'variablename' field. I will want these when we build the report generation feature - feel free to ignore for now (happy to chat more about the scope of this if you like - I think it's relatively straightforward).

6. Similar to 5, there is a also a 'metrics' field in the output structure which will return 'scores' for the MO in each analysis, which I'll want for report generation. These are just hard coded for now (rather than reporting meaningful values) - it's just the communication structure to get the info back to the database. At some point when we implement report generation, we will want to save and later retrieve this information at a user's request.

7. SingleSiteExperiment.R is coded to allow use of the 'parallel' package if we can build it on the analysis server. It's checked in with this stuff commented out, but just three or four comments need to be removed to turn it into the parallel version should that package be available. With this relatively short test data set, on my laptop, it drops total analysis time from ~65 seconds to 27 and it will only come closer to scaling to the number of cores for larger datasets.

8. I've left a 'system.time' call and print statement in the TestSingleSiteExperiment.R script to let us see how much the parallel option helps in production.

9. I assume no significance was attached to what was printed to screen - it's changed a little.