What you are proposing is a lot of work! Could you provide a link to the COSINE terraforming module you are interested in incorporating? I'm not familiar with the term terraforming being used in the context of what MARBL does -- MARBL adds tracers to an ocean model, and provides modules to compute interior tendencies and surface fluxes of those fluxes so that the ocean model can model how concentrations change over time. It just so happens that MARBL is focused on biogeochemical tracers, but the science behind the tracers is completely unknown to POP2.
That said, if COSINE does indeed add a tracer or multiple tracers for POP2 to model, then I would recommend that you introduce a new namelist variable
cosine_on that behaves similarly to
ecosys_on instead of accessing COSINE through the current
ecosys_* files, and just use the MARBL setup as a blueprint for adding a new
cosine_driver.F90. While MARBL was developed to be self-contained and "easy" to drop in to an ocean model, the infrastructure surrounding it was written to be specific to the MARBL library itself. As far as I know, there is not a generic interface that would make it easy to replace one external tracer package with another (and if such a thing existed, it would probably be specific to biogeochemical tracers, standardizing the interface for passing specific forcing fields and other inputs to the BGC package).
Lastly, this might not be very helpful... but github can compare
the last POP2 tag without MARBL to the first implementation of it as an independent library. If you do end up trying to create a set of POP2 modules to help connect COSINE to the model, the MARBL diffs may provide some guidance on changes you need to make to the build system to make sure COSINE gets built correctly, and other CESM infrastructure-related issues.
