Veg change

[mt-digital]

Review @jerickson42 additions for updating vegetation code and dependent parameters

[mt-digital]

Thanks for the updates. I like your object-oriented approach to scenarios.

Two things we need to address before merging:

First, as noted in the line note above "we need to add some kind of uniqueness or handling of repeat scenario names". For this let's just tack on a dash and a number, e.g. if the user passes myscenario but there's already a myscenario, make it myscenario-2. If myscenario-2 already exists, increment to 3, and so on.

The second thing has not been very clear, my apologies. The way Lisa and Rui developed to communicate which HRU should be updated is by a single HRU index. We can achieve this by translating the HRU index to a (row, col) index using the ncattrs, then just using what you've already built.

So, pls fix those then we can merge! Thanks

[karlbenedict]

As an alternative to the sequential numbering of repeat scenario names I might suggest appending a timestamp (to seconds) to each scenario name (in all cases, not just in the case of repeated scenario names), giving the names some general temporal information, but also (likely) providing unique names. Associating a random hash with each scenario when it is generated, and using that hash as the internal identifier (a-la GitHub's hash fingerprinting identifier model) that is pretty much ensured to be unique should provide a relatively bulletproof scenario specification tracking capability, first within the web server, but also for scenarios when they are uploaded to the VWP.

[mt-digital]

Timestamps will be stored in the DB that tracks scenario runs, so we are already tracking temporal information there. Similarly, the virtual watershed uses UUIDs for its modelrun identifier, so there is never a conflict over file names.

I want sequential numbering because we often are just playing around, and as a user I want to know if this was the nth time I tried it or the (n-1)th time I tried it. UUIDs will result in a lot of clutter on the front end when we display the scenario names which may already be long.

These are the reasons I asked John to do it the way I did. I respectfully prefer he implements it the way I asked him originally.

[karlbenedict]

That sounds good. I wonder if it would be useful to plan for eventual exposure of the timestamps through the API/web interface in addition to the sequential suffixes.

Thanks, Karl

On Mar 10, 2016, at 6:09 PM, Matt Turner notifications@github.com<mailto:notifications@github.com> wrote:

Timestamps will be stored in the DB that tracks scenario runs, so we are already tracking temporal information there. Similarly, the virtual watershed uses UUIDs for its modelrun identifier, so there is never a conflict over file names.

I want sequential numbering because we often are just playing around, and as a user I want to know if this was the nth time I tried it or the (n-1)th time I tried it. UUIDs will result in a lot of clutter on the front end when we display the scenario names which may already be long.

These are the reasons I asked John to do it the way I did. I respectfully prefer he implements it the way I asked him originally.

— Reply to this email directly or view it on GitHubhttps://github.com/VirtualWatershed/prms-vegetation-scenarios/pull/18#issuecomment-194960346.

[mt-digital]

Yes, definitely. Right now they are displayed in the web interface which is served by the API, so the timestamp of when the scenario run request was received and when it was finished. I can't remember if @itsrifat's modeling server gives the user timestamps for modelrun start/finish. We need to have the timestamp more prominent on the web interface for the wider virtual watershed.

[itsrifat]

@mtpain The modeling server keeps a timestamp for each of the progress event fired while running the model. So techniaclly we can get an estimate of how much time is elapsed for the whole modelrun from the time difference of the events. Foe example, in case of isnobal we get something like this:

Event	Time
initialize	12-3-16 20:30:23
convert_input_nc_to_ipw	12-3-16 20:31:23
run_model_in_shell	12-3-16 20:33:23
convert_output_ipw_to_nc	12-3-16 20:34:23
finalize	12-3-16 20:35:23