Provide better handling of time zones

[arbennett]

After discussion of #8 for adjusting time within a given timezone the issue came up that we may want to account for different time zone standards. The current implementation is similar to nautical time, with 24 equally spaced time zones (15 degree longitude widths).

A situation where this might not be the best is if forcing data is provided from a source where timezones are given in some other format, where there would be a discrepancy between the the expected offset and the actual offset.

[bartnijssen]

@arbennett : Do we need this for V1.0.0 or can we reproduce VIC behavior without it?

[arbennett]

The first paragraph describes the simple case which is implemented, while the second paragraph is about what might be useful to somebody in the future.

[bartnijssen]

It does bring up the following interesting(?) case: If I have a netcdf file of a large domain (e.g. CONUS) and I have a timestamp at noon, is that then local noon at each individual grid cell in the file? That is, would I get a spatial field that would never occur in the real world in that the sun would be at the same zenith angle for every point along the same parallel? That would potentially create problems with averages over large spatial domains at resolutions less than a day. We never really handled this in the old VIC mode in which all grid cells run independently (or in the subsequent conversion to netcdf).

[bartnijssen]

@arbennett: When I have a spatial slice in the netcdf output file from metsim, is the time for that slice in local time or in UTM, i.e. if the time says noon, is that local time or not? That is currently not clear to me and it affects how the file can be used.

[arbennett]

Yes, that time would be local to each grid cell.

[bartnijssen]

OK - that is slightly odd (i.e. not necessarily what people would expect). It doesn't matter for V1, but we do need to make sure we clarify that in the documentation and in the metadata of the NetCDF file. I'll open a separate issue for that specific part (documentation and metadata) and will add that to V1.0

How we do that eventually will remain open.

[tbohn]

Just to chime in here with some background - what Andrew is describing is the same behavior that the old code in VIC 4.2 did as well. I had inserted some logic (don't remember exact details) to distinguish between the case that we're seeing and the case of gridded atmospheric model output (which might be in UTM). I forget whether there was an option to switch between these behaviors - I think so, but I never used it. I think it keyed off of off_gmt - if you wanted to have climate-model-style UTM behavior, you should set off_gmt to 0 everywhere.

The MTCLIM code, before I got my hands on it, always did local time.

[arbennett]

As another note, this issue was taken into account when designing the disaggregation module, and the only change that will have to be made to address this is in the shortwave disaggregation function. There is some infrastructure for this already in place with the use of tiny_offset, but it is not documented publicly.

[bartnijssen]

@tbohn : Understood - but since 4.2 always treated each cell independently, I think that made sense to people then. I don't want to put effort into this at the moment, but want to document it, because it may not be what someone would expect when they look at a spatial slice in a netcdf file. Instead of the sun coming up in the east and setting in the west, in effect our netcdf file represent a flat earth where the solar angle is the same across all grid cells at a given time. This is definitely different than what would come out of a coupled model.

[tbohn]

Sure, just giving background. I think 4.2 handles coupled model output as long as you set off_gmt to 0 everywhere (which also impacts VIC's outputs).

[martynpclark]

Some models use a single time variable (as in MetSim), and use the latitude/longitude coordinates for the solar geometry. In these cases it is suboptimal for MetSim to provide local time, since local time varies across the domain (e.g., for CONUS-domain simulations).

For these cases it is desirable for MetSim to provide the time in UTC.

Note that the code to do this should be trivial, e.g., https://github.com/NCAR/summa/blob/develop/build/source/engine/derivforce.f90#L198-L206

 ! compute the local time
 timeOffset = longitude/360._dp  ! time offset in days
 julianTime = secondsSinceRefTime/secprday + refJulday ! julian time (days) 

 ! convert julian day to year/month/day/hour/minute
 call compcalday(julianTime+timeOffset,          & ! input  = julian day
                 jyyy,jm,jd,jh,jmin,dsec,        & ! output = year, month, day, hour, minute, second
                 err,cmessage)                     ! output = error control
 if(err/=0)then; message=trim(message)//trim(cmessage); return; end if

At the moment a workaround is possible, but this requires running MetSim for each cell independently.

[arbennett]

Solved in #120