investigate moving snow_Aging() routine

[har917]

The snow aging routine (cbl_snowAging()) is currently called as part of the evaluation of the albedo (snow age is a contributor to albedo in snow-impacted areas). The snow aging routine needs to know the change in snow amount (%snowd - %osnowd) from the previous time step. Since the albedo is called first this requires that snow amount in previous time step is available - strictly this includes on the first time step and so %osnowd needs to be in the restart/initalisation.

It would be preferable (at least for the coupled configurations) that this not be a requirement.

However - conceptually at least - it should be possible to move the snow aging routine to avoid this need. Two element

• set %osnowd = %snowd at the start of the time step (part of cbm())
• move the call to snowAging() from current location to after the soil/snow time stepping - snowAge can then use the snow incremented during the current time step to age the snow.

This move would not be bitwise reproducible but would

• address restart issue previously noted
• consolidate the time stepping of CABLE's state variables in (roughly) the same part of the sequence (see also time stepping of canopy%cansto. #505)

[har917]

There is at least one additional important note for this issue within the coupled applications (AM3) - namely the interaction with the prognostic bank.

• if snow_aging() is moved to after soil_snow_main() but remains inside cbm then %snage will need to be added to the prognostic bank and reset in between calls to cbm_impl

---

Other notes:

• There are also other interactions with the initialisation routines of the two coupled applications - however these are more of a tidy up.
• once implemented we could a) remove osnowd from the offline restart and b) convert osnowd from an element of the ssnow% type and hence from MPI