Initial coupling to SpeedyWeather via example script

[bgroenks96]

This PR is an initial attempt at coupling Terrarium to SpeedyWeather by extending SpeedyWeather.AbstractLand.

Currently, we couple the PrimitiveDryModel to a Terrarium soil column on a rocky planet (no oceans).

Coupling is via skin temperature only. Surface energy fluxes from radiation are currently ignored. There is still some work to be done in debugging instability with the implicit skin temperature scheme and surface energy balance.

This PR also adds a CoupledSoilAtmosphereModel which combines a SoilModel with a SurfaceEnergyBalance and PrescribedAtmosphere.

Additional changes:

• Make FieldInputSource just define input variables rather than storing its own Fields; this is simpler and less redundant.
• Adds a benchmarking script for CPU vs. GPU (used for P2F GA poster)

Resolves #41

[maximilian-gelbrecht]

I like the general approach.

So currently in the actual running code in the script you just define Terrarium as a land component of SpeedyWeather. And you don't actually use the CoupledSoilAtmosphereModel that you define in the package. Can you give a bit of the thought process in which situations you would do what. Also are there any problems still with CoupledSoilAtmosphereModel that there's no example or test?

[bgroenks96]

The current setup where the SoilModel is coupled directly to Speedy via a temperature-BC is not really meaningful or useful for any practical coupled land-atmosphere modeling. It was only intended as a first step. There might be isolated cases where it's still useful, like coupled thermal simulations over large spatiotemporal scales, but... those use cases are far and few between.

The CoupledSoilAtmosphereModel represents the "real", physically-based coupling between the ground and atmosphere based on the SEB is basically an initial iteration of the main interface for future coupled simulations. At the moment, it's not working because the SEB coupling with Speedy is not stable. The skin temperature diverges to large, unrealistic values after a few timesteps.

We still need to figure out what the problem is there, but I suspect part of the problem is that Terrarium uses a fairly small upper soil layer of 5-10 cm in thickness (ideally we should actually be targeting 1-2 cm... especially for soil water and carbon), whereas Speedy's bucket land model uses a thicker 20 cm layer. Possible bugs in the flux calculations notwithstanding, the two solutions in the end will probably be (a) take smaller timesteps or (b) use an implicit time stepper.

[maximilian-gelbrecht]

What do you see as TODOs here aside from some cleanup. I guess this PR will be more focussed on the initial temperature BC coupling, and then we try to resolve the outstanding issues in a follow up?

[bgroenks96]

Yeah I'll just clean up the script and make sure it's working with the temperature-only coupling. In a meeting with @milankl, we determined that the cause of instability in temperature-only coupling with small surface layers (5 cm thick) was due to Speedy taking timesteps that were too big.

So I think for PrimitiveDry the skin temperature coupling with Speedy-based surface fluxes can be considered successful.

[bgroenks96]

@maximilian-gelbrecht I think this is ready to go.

We will definitely need to investigate performance and how to speed things up. Even working around the weird SpeedyWeather FFTW threading bug, I get ~4-5x slowdown compared to running Speedy standalone with its default bucket land model.

Of course the other logical next step is investigating the stability issues with SEB coupling.

In addition, I tried running a 1-year simulation with this temperature-only coupling and it crashed with NaNs near the end :(

So yeah, long way to go, but this is nonetheless a good start, I think.

[bgroenks96]

@maximilian-gelbrecht Would you prefer if initialize had the following signature?

initialize(model::AbstractModel, timestepper::AbstractTimeStepper, inputs::InputSource...)

[bgroenks96]

Already done in d2db0f5 :)

[maximilian-gelbrecht]

I think that would make it just more convenient.

[bgroenks96]

Ok that took an unreasonable amount of time, but it's fixed now...