Added Findley Lake dataset

[tbohn]

Provides example parameters and forcings for the lake model, as well as a document explaning how the parameters were derived and comparing the results with observations.

Does not yet contain the results of the example simulations, nor does it contain the observations. The observations are only a table of 2 years of quarterly fluxes.

This closes issue #19

[dgergel]

@tbohn this looks good, I just had two small comments regarding the global parameter files. Would it be too much trouble to go ahead and add the observation data?

[tbohn]

@dgergel @jhamman @bartnijssen Where would you like me to add observations for Findley Lake? Right now, the options appear to be to create an obs directory under either classic/FindleyLake, image/FindleyLake or both, or to make a separate obs/FindleyLake directory under VIC_sample_data, or maybe make docs/obs. Adding the observations for Findley Lake is one of the reasons why I was inquiring about reorganizing the VIC_sample_data directory structure. Let me know what you think.

[dgergel]

@tbohn I think it makes sense with the current structure to add an obs subdirectory under FindleyLake for classic and image drivers at the same level as forcings and parameters

[tbohn]

I find the redundancy of that solution a little less than optimal, although I suppose changes will be made so infrequently that the odds of these getting out of sync are low. But would you be OK with creating an obs directory at the same level as docs or underneath docs?

[dgergel]

@tbohn sure, that's fine by me as well

[tbohn]

@dgergel regarding the $VIC_SAMPLE_DATA vs $VIC_SAMPLE_RESULTS question: The image version of the Stehekin global parameter file uses $VIC_SAMPLE_DATA. The only file (for any of Stehekin, WalnutGulch, or FindleyLake; image or classic) that uses $VIC_SAMPLE_RESULTS is the classic version of the Stehekin global param file.... However, I'm happy to change the output path to $VIC_SAMPLE_RESULTS in all of the global param files if that works better. I assume the reason this was ever done in the first place was so that the user wouldn't write files to the clone of the repo and risk accidentally committing output files to the repo. But then we should also change the state file path to be consistent for the same reason. Otherwise I'd prefer to change the one instance of $VIC_SAMPLE_RESULTS to $VIC_SAMPLE_DATA...

[tbohn]

Oops, let me amend that - now I do see that the image version of the global parameter file for Stehekin uses $VIC_SAMPLE_RESULTS. I'll change all global param files to be consistent with this.

[tbohn]

Actually, now I have a question: why are the results written to $VIC_SAMPLE_RESULTS/sample_image or $VIC_SAMPLE_RESULTS/sample_classic? Does the Travis build system replace that with a directory that indicates which domain this pertains to (e.g., Stehekin)? The reason I ask is that, for WalnutGulch and FindleyLake, I've provided multiple global param files that use different options. I write the results of those to separate results directories whose names include a description of the options so they are unique. If I adopt the $VIC_SAMPLE_RESULTS/sample_image convention, will that cause any problems? Or does Travis not care about this? Perhaps I can adopt the convention but include a note for users to remind them to change the directory to something unique so they don't overwrite their results when they run different global param files.