Forcing file dates about vic HOT 12 CLOSED

We should just indicate in the documentation how this can be handled and recommend that people include a date. This is not an issue for image mode anyway.

Changing the label to documentation.

from vic.

Related: https://github.com/UW-Hydro/mtclim/issues/2

from vic.

Do we still want this to be part of the VIC.5.0 classic driver? This is a significant backwards incompatible change that would require reformatting existing forcing datasets.

It would be easy enough to write a conversion tool that adds date columns.

If we decide to implement this, my proposal would be that we also include a header for ascii files. the final forcing data format would then be:

YEAR MONTH  DAY SECOND  VAR1    VAR2    VAR3    VAR4    VAR5    VAR6        VAR7
1999 03     01  00000   6.577   212.625 5.758   72.2719 0.0000  0.00293510  4.14
1999 03     01  03600   0.000   212.625 5.383   72.3291 0.0000  0.00319444  2.04
....
1999 03     01  82800   2.002   213.625 5.383   71.321  0.0000  0.00654144  3.25

from vic.

I'd prefer that we do since I think not having the date is an easy source for error (although it does potentially save a lot of space). I agree on the header.

One reason to go to VIC5 rather than VIC 4.3 is so we can break backwards compatibility. People can always fork and write a read routine for classic mode that skips the dates if they don't want it. The default model should support the more explicit case (i.e. with dates).

Including a date conversion tool as part of the tools would be great.

from vic.

I don't see a conflict...

VIC currently can read forcing files that have dates and headers. But it
doesn't actually use that information. I.e., if you have year, month, and
day columns, you'd have to specify "skip" as the forcing variable for each
of these in the global parameter file. And the header line would simply be
skipped rather than interpreted.

You could modify this behavior to include (optional) year, month, day, etc
columns, which VIC could use if present...

On Mon, Dec 22, 2014 at 1:26 PM, Joe Hamman [email protected]
wrote:

Do we still want this to be part of the VIC.5.0 classic driver? This is a
significant backwards incompatible change that would require reformatting
existing forcing datasets.

It would be easy enough to write a conversion tool that adds date columns.

If we decide to implement this, my proposal would be that we also include
a header for ascii files. the final forcing data format would then be:

YEAR MONTH DAY SECOND VAR1 VAR2 VAR3 VAR4 VAR5 VAR6 VAR7
1999 03 01 00000 6.577 212.625 5.758 72.2719 0.0000 0.00293510 4.14
1999 03 01 03600 0.000 212.625 5.383 72.3291 0.0000 0.00319444 2.04
....
1999 03 01 82800 2.002 213.625 5.383 71.321 0.0000 0.00654144 3.25

—
Reply to this email directly or view it on GitHub
#18 (comment).

from vic.

Good point of being able to use the SKIP keyword.

from vic.

@bartnijssen and @tbohn -

What do we think about this issue given where we stand with 5.0 right now. My original thought was to require a header and date/time columns and have VIC use them when determining the forcing fields. This would require a bit of work so I'd like to discuss how to proceed.

from vic.

It's not a big deal for classic, as I mentioned above - classic already has the ability to read a file that has a header and date fields. Although all classic does at the moment is ignore the data. So to make it a requirement, you'd have to have VIC at least read some parts of the header and date fields and complain if these weren't present or weren't valid.

I don't know how much work this would entail for image/cesm - I guess you'd read the variable names from the global param file forcing section? You know better than I do.

from vic.

I don't know how much work this would entail for image/cesm

This change would only impact the Classic Driver.

from vic.

Oh, right, somehow I was thinking of user-specified variable names as part of the deal - but of course you can require that the ascii file headers have only the exact variable names that VIC expects.

from vic.

Still would be my preference to include it since the changes in 5.0 are not required to be backwards compatible anyway. If we do not do this (actually read and check the dates), then we should at least explain in the documentation how people can already include a date (per Ted's comments above).

from vic.

Continued in #579

from vic.