[Draft] Adding new nml options to gradually increase timestep size

[abishekg7]

This PR proposes two new namelist options, config_dt_init and config_dt_rampup_duration, in order to slowly ramp up the time step size of the model upto the standard timestep size given by config_dt. Initially the model starts with a timestep size equal to config_dt_init and with every time advancement, increases the timestep size by a dt_incr, which is (temporarily) defined as a module level variabe in mpas_atm_core. This accumulation of timestep size occurs until the elapsed time has reached config_dt_rampup_duration. At the end of this period, the timestep size is exactly equal to the specified config_dt

To compute the dt_incr, we assume that the accumulation of the timestep size occurs in an arithmetic sequence,

a, a+d, a+2d, a+3d,......., a+nd

where a is the initial timestep size config_dt_init and d would be the dt_incr. We know that the sum of the arithmetic sequence for integers above is given by:

Sn = n/2(2a + (n-1)d)

which must equal config_dt_rampup_duration. With this, we can solve for n as

n = 2*config_dt_rampup_duration/((config_dt + config_dt_init)

From which we can derive dt_incr

In practice, while the timestep size at the end of the ramp up period exactly matches config_dt, the total time advancement duration may not necessarily match config_dt_rampup_duration, perhaps due to using an integer summation formula for floats. So we limit n to the floor of the real value, and compute the difference between config_dt_rampup_duration and the estimated time advanced after the first n timesteps, and set this difference as the first model timestep. The second timestep uses config_dt_init as the timestep size.

---

In addition to the above changes, this PR also includes changes to parts of the code which assume a constant timestep size. This is still work in progress