Noah model: very simple, lumped model. Can prescribe lots of parameters like albedo (so attractive from an nwp perspective). Mike feels we're not considering Noah for this project.

• Martyn: eventually, his vision is that we'd want to have something as simple as Noah.

Original idea of Noah-MP was that you could reproduce Noah as one set of options... but really they are completely different models.

Noah-MP is quite similar to CLM, in terms of vertical structure. But no PFTs or any (or much) other subgrid heterogeneity

• There is a vegetated portion and a bare portion, which maps pretty directly to the bare ground fraction in CLM
• There is a separate urban model - similarly for lake. So these are somewhat similar to the ocean model - as a separate surface component. (Although there is a bit of complexity / subtlety here with respect to urban.) (And a lot more complexity with the multi-layer urban model, which protrudes into the atmosphere.)

Noah-MP is an optional land model in WRF (the default is Noah). It is also coupled to an NCEP model, and used in some other applications (Dave Gochis, LIS, etc.). But WRF is the primary use base.

Mike maintains Noah-MP, along with an offline driver for it (which mimics WRF)

At the highest level, Noah-MP does the same things as CLM

Going down to a deeper level of detail - to the individual flux terms (like H & LE through canopy), there are some similarities and some differences.

e.g., Noah-MP has a representation of K-theory, which is different from the turbulent flux formulation in CLM

Photosynthesis: Noah-mp and CLM both compute stomatal resistance, but CLM has evolved since Noah-mp branched off, so that it has much more sophisticated a photosynthesis scheme

Top-level structure of noah-mp: Phenology, energy, water, carbon

• So to a large extent, this is a subset of what's in clm - largely because of the BGC in CLM (Noah-mp isn't generally used for long-term climate simulations)

There is a dgvm in noah-mp; also a crop model

Noah-mp has many options... pretty much across the board

Different options at different levels of granularity - from a single line of code up to huge chunks of the model (e.g., canopy radiation, dynamic veg, groundwater).

There are a lot of options for reading in prescribed data; some of the big ones are:

• LAI
• spatially-varying soil properties: read in actual soil parameters themselves (as opposed to sand / silt / clay)
  • note that CLM currently just reads in sand / silt / clay... but it seems relatively straightforward to give CLM the option to read in the actual soil parameters
• other data, depending on what options you turn on
  • e.g., crop model

(So it actually sounds like it might not be a big deal to have CLM be able to use the same prescribed data that Noah-mp is capable of.)

Some of the larger differences are probably not something we'll address initially - such as all the different urban models.

If we focus on biogeophysics initially - there are a lot of similarities between the two

Dave: hard to see how we do the transition to having everyone using this unified model... this seems much more complex than just replacing the biogeophysics

e.g.:

• the flux coupler vs inline calling
• urban model separately
  • though we could set up the grid so that the unified model has a surface dataset that only encompasses the vegetated portion of the grid cell

Noah-MP runs at the same decomposition as wrf

• world is broken into rectangular tiles
• there is a land mask associated with each grid cell

Could you just dictate the decomposition to CLM? Mariana recalls some complexity when this was done before (bringing clm into wrf long ago).

This may have been dealt with somewhat in Tony's template version of lilac... but maybe not

Exchange coefficients, then land model, then boundary layer

i.e., land model happens in the middle of the atmosphere time step

Do we have an early goal of being able to run CLM in WRF?

Dave: one possible goal is to be able to reproduce a default CLM and default Noah-MP configuration (no coupling to atm model)

Martyn sees 1st year focusing on physics (Dave: and maybe numerics), 2nd year on coupling issues

Focus 1st on getting new parameterizations, or getting the summa numerical stuff? Martyn thinks we could do this at the same time, to some extent - starting with local solvers for pieces of the model.

Martyn feels it's important to have parameters highly visible and modifiable

Mariana thinks the current mechanism of namelists is the best moving forward, as opposed to relying heavily on netcdf files

Martyn: The other big piece of this is the transfer functions that were used to come up with parameters - e.g., the external processing tool (e.g., a matlab script) that was used to create a parameter

Dave suggests: Have a list of key Noah-mp parameterizations for which you'd say, "For this to be a reasonable model, it needs to do this" - i.e., both what processes are represented (probably the same as clm, besides maybe groundwater), and what specific, key parameterizations are used for each process.

We'll need to consider whether to keep everything, or ditch some things that we really don't like (e.g., obsolete).

There's a balance between supporting lots of options and backwards compatibility on the one hand, and avoiding too much code complexity on the other hand.

In some sense, the little one-line differences are the hardest - end up with conditionals sprinkled throughout the code.

Mike points out that you need to consider the various partners who use the model - if you stop supporting some option that they rely on, they'll stop updating, and diverge.