-
Notifications
You must be signed in to change notification settings - Fork 12
Description
I've been working on implementing a more accurate version of MARGO's 1.5-layer (or "Deep-layer") Energy Balance Model. The improved solution is an exact analytical solution to the two-layer problem (see #43).
I quickly ran into a problem that the MARGO code, as it is currently written, is not nearly as flexible as we would like it to be. In particular, we do not have the appropriate abstractions for allowing submodules to be swapped out for others on the fly.
I imagine that in addition to the bare-bones MARGO configuration, other configurations could be easily created by picking and choosing the complexity of various components. If we define the abstract types in this way, it would also be easier for others in the community to make their own changes and possibly contribute them to the master branch.
One huge advantage of abstract types is that some methods will apply to the abstract types while others will apply to specific model types.