Compare TSM refactor options: `xarray-simlab` vs custom framework.

[xaviernogueira]

In order to create a discussion around how the rest of the model should be refactored, I will start with TSM as it is uncoupled from other modules, smaller in scope, and in its initial form at the moment.

Two options exist...both will be explored:

• Using xarray-simlab split our workflow into Models, Processes, and Variables.
• Using base python have a simular architecture that may be more tailored to our use case.

Having a rough schematic of both will allow next steps to be decided in an informed manner.

[xaviernogueira]

This was assessed. While xarray-simlab is a cool framework, the amount of work needed to implement custom process classes for every variable (of which we have many), would be highly tedious. Additionally, the lack of testing in that repo, as well as the lack of public projects successfully using it raised concerns about getting trapped which is especially an issue on such a short timeline.

Therefore, a similar yet more streamlined framework was built that centralizes time step computation to one core class rather than distributing it across classes for each variable. Variable classes contain functions that will be utilized by the core base.Model class. Therefore the core difference is that our framework knows HOW to calculate variables and then does so in one place, rather than actually doing the computation in each of the variable classes as implemented by xarray-simlab.

This should make development significantly faster and less bug-prone. It should also increase model run speeds, although room for improvement exists in this realm.

Takeaways: xarray-simlab is a great candidate for more exploratory modeling work, a smaller initial project, or a project with less of a pending deadline. With more time to figure out its nuances, it seems like it could be successfully used in the future.