Think about how to construct timestepper caches

[bgroenks96]

In #43, we modified the timestepper interface such that intermediary stages/caches are stored in the timestepper struct itself. However, this somewhat complicates the construction/specification of the timestepper by the user since it now depends on the state, which is not available pre-initialize.

Copy of comment from @maximilian-gelbrecht in #43:

But you are raising a good point nonetheless. We actually need kwargs for the timestepper. At the moment it would be okay to just forward all additional kwargs from initialize directly to the timestepper. But would we want to keep that in the long run? I think it's a bit inelegant. We already depend on Flatten anyway, so maybe it's actually best to just take in an instance of the timestepper and then reconstruct the timestepper with the correct stage/cache.

We should think more about how to do this long-term. I am still in favor of separating the cache from the timestepper, I think, but we can discuss more here.

[maximilian-gelbrecht]

Okay so

1. I think first we need a stop-gap solution because currently you can't set the timestep well. I would propose to just do that by forwarding all kwargs to initialiaze(::Model) to the timestepper. That's literally just two lines of code changed and it works for now.

2. Long-term: when you say separating cache from timestepper, are you also saying that you'd like to have a cache with a hierarchical structure in the ModelState, and then again the time steppers / solvers themselves in the individual models?

[bgroenks96]

This is being addressed in #46

The initial solution, following your changes in #43, was to just have initialize recreate the timestepper with the stage allocated (initially set to nothing when passing into initialize).

However, in fixing the Enzyme tests, I noticed that we now have the (maybe) issue that the timestepper struct becomes non-constant memory and thus needs to become Duplicated in our Enzyme tests. It definitely complicates the interface for AD but maybe this is OK? Alternatively, we could just copy the whole ModelDriver (formerly ModelState). What do you think?

[bgroenks96]

I think a more general solution would be to remove clock from StateVariables (so it's only Fields) and then wrap it in state type that holds the clock and timestepper cache. However, this has the downside that it makes the model state an even more complex data structure and, since getproperty will have to be forwarded again, further obfuscates the structure from the user.

[maximilian-gelbrecht]

I think I would be fine with that and don't find it too concerning to basically nest one level deeper.

[maximilian-gelbrecht]

Just noting down what we talked about last week or so: with the recent revisions, it would be very easy to change what we currently have for the Heun solver and have the cache just fetch all prognostic fields and not copy the whole state anymore.