Notes on Linking an Outside Atmosphere Model to CLM4
Two options:
- Bring your atmosphere model into the CESM modeling system.
- Bring CLM4 into your modeling system
Bring your atmosphere model into the CESM modeling system
This option may seem scary, you might even have trouble finding the main program and if you do find it, it's 2500 lines long. But, the good news is that you don't really need to work with the main program -- you really only need to work with the atm_comp_mct.F90 file which is only 129 lines long (for the case with datm). Looking at that file gives you a pretty good idea of how to couple your atmosphere model into CESM. You'd have to work on the configure and build scripts for your atmosphere model as well -- but you could just use datm as a template to do it.
Bring CLM4 into your modeling system
On the second part, where you want to link CLM into your modeling system, basically the top level interface of CLM to the rest of the system is through the lnd_comp_mct.F90 module in models/lnd/clm/src/main/cpl_mct. Unfortunately it's a bit long (1.7k lines) but it's nicely broken up into subroutines. and shows the correct order of calling things from CLM. What you would probably do is replace lnd_comp_mct with something that would interface with your atmosphere model. clm_comp.F90 is also a high level module (that is called from lnd_comp_mct) that's much shorter and easier to look at, but requires other calls from lnd_comp_mct for it to actually work, but it does break up CLM into a few initialization steps and run phases.
Some details on this second option. You'll need to link in NetCDF, ESMF (or the esmf_wrf_timemgr interfaces), csm_share, gptl timing library, MCT, mpeu, and MPI. This is all handled for you with CESM, but you could add these things to the build of your model.
Additional comments from Mariana Vertenstein
The key responsibility of lnd_comp_mct.F90 is to convert coupling data structures into clm data structures and vice versa. Coupling data structures are required since clm determines its decomposition across processors independent of the other model components - and given this - having a coupling framework (such as MCT, ESMF...) makes it possible to keep this functionality and not have to re-write the clm decompsition to correspond to whatever atm you are coupling to. The coupling framework is responsible for redistribution data from clm to the atm and from the atm to clm. In addition, having a coupling framework also enables you to "easily" run clm on a different grid from the atmosphere. The coupling framework is then responsible for both regridding and re-distribution of data. So if someone wants to couple clm to another atm - and they do not use MCT or ESMF - they would have to introduce their own coupling utilities to do the redistribution and/or regridding. In addition, we also have control data
(such as nextsw_cday used for the albedo calculation) that is passed between components. This is currently done via and independent data structure called infodata in the driver. The routine lnd_comp_mct.F90 extracts the relevant control data from infodata and also puts relevant control data from clm back in. So the exchange of control data would also have to be implemented via some other mechanism (this had to be done when we put ESMF component interfaces in).