You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
In addition to these three types having different numbers of parameters (with different values), they are have different physics and thus different solutions. Thus, they will require different methods of the diagnostic functions:
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.
The text was updated successfully, but these errors were encountered: