CN annsum_counter can trigger mid-year, and at different times for different columns

_From @billsacks on May 16, 2017 21:20_

With the fix that I'm putting in place for http://bugs.cgd.ucar.edu/show_bug.cgi?id=1597 and http://bugs.cgd.ucar.edu/show_bug.cgi?id=2458 (though this was true before that fix to some extent): The logic for updating some annually-accumulating quantities - which is based on annsum_counter_col in CNAnnualUpdateMod - means that we don't necessarily do these annual updates at the end of the year. This may be by design: Rather than always updating at the end of the year, we update each column when that column has been active for a year since its last update.

In many cases, these are equivalent, but it's possible for the current logic to differ from the end of the year based on the history of the initial conditions file. Specifically: If the initial conditions file has a history that included running for part of a year and then resetting to the start of the year (or some other time in the year), then the annsum_counter will be out of sync with the year boundary. One example of when this can happen is when you run init_interp for a few time steps to produce an interpolated initial conditions file.

This becomes more troublesome when different columns trigger at different times. This can happen because of dynamic landunits, since the counter only accumulates for active columns. So, when you have (a) counter out of sync with the year boundary, and (b) dynamic landunits (via a transient run), then you can get different columns triggering at different times.

I can see two possible solutions:

1. Keep the annsum_counter-based code, but have some logic to reset tempsum and the counter to 0 at the start of a startup run **if** the run is starting at the beginning of the year. This won't fix all cases, but will fix the most common issues that arise due to there being some messy history underlying an initial conditions file.

2. Stop using annsum_counter. Instead, make the annual sums at the year boundary, based on the time manager. However, this change by itself could be problematic in the case where someone runs for (e.g.) 6 months, creating an initial conditions file, then starts a new run with that file from some other time of year: In this case, for the first year of the run, we would accumulate something other than 12 months of npp (etc.) using code like this:

```Fortran
tempavg_agnpp(p) = tempavg_agnpp(p) + dt/secsperyear * agnpp(p)
```

We could handle that by changing the accumulation to:

```Fortran
tempsum_agnpp(p) = tempsum_agnpp(p) + dt * agnpp(p)
dtsum(p) = dtsum(p) + dt
```

Then, at the year boundary, divide by that total accumulated dt - which may not be 365 days, depending on the history of the initial conditions file.

(It could be a bit tricky to allow backwards compatibility with old restart files in this respect, though.)

cc @ekluzek

_Copied from original issue: NCAR/CLM#7_