Daily vegetation parameters from file about vic

[tbohn]

Here's my proposal for the design of this feature:

1. Create new forcing variables for LAI, albedo, roughness length, and displacement height. They will be handled the same way in initialize_atmos() as other forcings: read from forcing files, shifted temporally as necessary to match up to the desired time convention, and assigned to the veg_var structure.
2. The monthly climatologies of LAI, albedo, etc will remain, but they will be renamed from veg_var.LAI to veg_var.LAIclim, etc. These will retain their 12 monthly elements.
3. New versions of veg_var.LAI etc will be created, having nrecs elements. These are what initialize_atmos() will use to store the input timeseries.
4. If any of these are not supplied as inputs, the monthly climatologies will be assigned in initialize_atmos() (e.g., veg_var.LAI[rec] = veg_var.LAIclim[month]). I could hard-code the interpolation of monthly to daily, or leave that as an option, or leave out the interpolation altogether since someone could supply interpolated climatology as a forcing if they wanted it. Any opinions?
5. Create 4 new output variables: OUT_LAI, OUT_WDMAX, OUT_ROUGH, and OUT_DISPL, so that someone can monitor these for diagnostic purposes. OUT_ALBEDO already exists.
6. How to handle VIC's snow albedo vs forcing albedo: this is a bit of a dilemma due to the different natures of remote-sensing albedo (which measures the entire scene, which could be a mix of exposed veg and snow, not to mention multiple veg cover types) and VIC's "pure" snow and veg albedos. We have a few choices: a) the supplied albedo timeseries is used instead; b) VIC's snow albedo overrides the supplied albedo when snow is present; c) make an option so the user can choose. Joe - perhaps you can weigh in since you've been working on a more sophisticated snow-veg albedo scheme, right? Can I just make a simple behavior, which your new snow-veg albedo scheme can replace when you get that finalized?

[tbohn]

A small correction: currently, LAI, Wdmax, albedo, roughness, and displacement height are all stored in the veg_lib struct, not the veg_var struct. So, I'd be creating new variables in the veg_var struct, without any naming conflict - perhaps no need to rename to *clim.

[jhamman]

Ted,

The implementation you outlined above looks good and I agree that the big question is how to deal with the snow covered vegetation albedo. I’ll start by saying that I think (a) should be an option and be useful in assessing the impacts of any other albedo scheme within VIC. However, the reality of remotely sensed albedo products is that there is a considerable amount of smoothing involved, both spatially and temporally. For this reason, the level of detail that the forcings will resolve will, in some cases, be less than what the model could produce. As you point out above, this really only applies to cases where snow is present. The scientific questions are, how does the lack of resolution influence the finer time/space behavior of snow-covered vegetation, and what happens when the surface albedo doesn’t adjust immediately to changes in surface snow?

The snow albedo scheme Bart and I have worked on includes prescribing the maximum snow covered vegetation albedo. There may be a conceptual problem when you have a time decaying snow albedo that is dependent on a time varying vegetation albedo but this could be sorted out. If we do decide to put this scheme into VIC, I think that most of these changes are orthogonal and could be easily merged with your daily albedos as you suggest in (b).

Either way, I think both options should be available. For now, focus on the simple behavior of (a) and we can revisit the vegetation covered snow albedo scheme at a later date.

[tbohn]

Another detail that could become important: since there are multiple plant functional types (PFTs) per cell, it seems appropriate to specify a separate timeseries of LAI for each PFT. In VIC's current form, this could take the form of multiple columns in the LAI forcing file, one column per PFT, in the order specified in the veg param file.

[tbohn]

This is basically code complete and tested now. Waiting on a few more beta-tests before issuing the pull request.