-
Notifications
You must be signed in to change notification settings - Fork 313
Meeting Notes 2018 Science
Note that these notes only capture a very small subset of the discussion, and make no attempt to summarize the presentations themselves.
Some work ongoing with getting irrigation in and parallelization of MizuRoute.
At a meeting last week, a group was concerned about the slow-ness of CanopyFluxes, and were interested in possibly helping, partly for the sake of FATES. (Anthony Walker, Nathan Collier and others.)
Let Dave know if you have things you want to discuss at these meetings. He'd like to get to the point of having these less formal, and more focused on discussing issues - at least sometimes.
Feb tutorial applications closed; CLM group will discuss format tomorrow and may solicit presentations. There are at least some applicants who are interested in NWP applications.
Dave L raises the question: In an age of limited resources, do we want to be at the forefront of developing methods for parameter estimation, or do we want to take tried-and-true tools and apply them in CTSM?
- Martyn: Most of the things he has talked about today are things that are tried-and-true. Feels that the things he has talked about are even more important in an age of limited resources: you may spend more time applying ad-hoc approaches than you would by applying more structural approaches... though that's still an open question.
- Andy Fox: Even the most tried-and-true method applied to CTSM is novel.
Dave's introduction: Historically, in CLM, we haven't used sophisticated parameter estimation approaches. We attempted this for CLM5 and failed miserably. But now we're starting fresh, with a simpler problem (without being concerned as much about biogeochemistry).
As reported last time:
- 2pft, 4 soil layer CTSM configuration runs about 3-6x slower than Noah-MP. We're exploring ways to reduce the cost, by focusing on low-hanging fruit. We are hopeful that we'll be able to make some progress on this.
- Potential cost reductions in canopy fluxes (Sam Levis)
- 20% or more cost reductions in transient simulations and 10% (?) savings from reduced heat stress calcs are in queue for integration into CTSM
Some discussion on cost reductions in canopy fluxes:
- This is related to the large number of iterations in the solution
- Gordon has some ideas here, like sub-cycling (which actually lets you avoid the need for iterations at all).
- Mike points out that this is also related to how you use the model: If you're running with a 1 min time step in a NWP model, then you don't need as many iterations; so part of this may be making this configurable.
We should determine what the goal is here. We probably won't be able to get completely to Noah-MP performance, but how close do we want to get?
Compset in cime parlance defines model configuration (i.e., namelist settings). We are moving towards having this defined - maybe in the next month or so.
- The NWP configuration does some things to reduce model cost. (Sense is
that performance will be the biggest barrier to adoption by the NWP
community; scientific performance is probably commensurate.) This is
done by making things closer to Noah-MP in WRF, like:
- reduced number of soil layers
- reduced number of PFTs
- turning off the expensive plant hydraulic stress calculation
For technical reasons, creating an NWP compset requires removing the CLM4 option. (For historical reasons, we maintain CLM4 in a different way than newer versions of CLM.) Working with WACCM-X group to get permission. (An example of types of things we'll run into in the future.)
Mike has generated a CONUS grid that we're using for testing.
Sam Levis is working to increase flexibility of PFTs (e.g., introducing methods to collapse at runtime into specified number of PFTs - e.g., the dominant 3 PFTs in each grid cell).
Working towards a big effort on generalization of flexible surface dataset (geogrid file in Noah-MP parlance) generation for NWP. This might be one of the trickier aspects of CTSM; we'll plan to have a broader meeting about this in the near future.
LILAC development is on github: https://github.com/jhamman/lilac
This is an ESMF-based coupling.
Target is to have an initial WRF-CTSM coupling with LILAC this Fall
Earlier modularization work now on CTSM's master branch (ctsm1.0.dev001). Note that we'll need to maintain CLM5 for CESM2 for quite a few years, on a release branch.
Reviewed and revised water state and flux variable data structure. Variables have been divided into true states, diagnostic variables, and variables just used for checking water balance. First step towards allowing water tracers (including water isotopes) in CTSM, which is a big CESM priority.
February 5-9, 2019
Mike compared out-of-the-box CLM5, an initial cut at an NWP configuration (preliminary: there will probably still be some changes to come up with an ideal NWP configuration) and Noah-MP, using a 1/8 deg grid over CONUS. Comparisons done using ILAMB.
One thing that stands out is that ET is generally better in CTSM.
-
First CTSM tag made: ctsm1.0.dev001: merges Bill Sacks's flux separation work with latest CLM master. Moving forward, we'll be using ctsm tags.
-
LILAC:
-
Joe Hamman will be pushing forward with the development of the LILAC coupler, to couple CTSM to WRF, etc.
-
Sam Levis (long-time CLM scientist/developer, now consultant) will be working on some aspects to improve usability
-
-
Isotopes, and water tracers in general: Mat Rothstein and Bill Sacks have begun working on the data type rework needed for this.
(There were three presentations on data assimilation, which I did not take notes on.)
Note that HRLDAS is the offline driver for Noah-MP. The coupling interface between Noah-MP and HRLDAS is the same as between Noah-MP and WRF. Dave L asks if the community using Noah-MP via HRLDAS will present difficulties in terms of switching from Noah-MP to CTSM. Mike's feeling is that LILAC will be key here: if we can couple CTSM to WRF, then we should be able to couple CTSM to HRLDAS.
Note that most or all of the non-CESM uses of CLM have been one-offs that are not long-term maintainable. This is one of the big motivations of the LILAC project, which should allow for more maintainable couplings moving forward.
Is there a system for parameter estimation / optimization? Not an out-of-the-box solution, but we have been working on pulling parameters out of the code to namelist / parameter files. We'd like to continue more down that path, possibly via LILAC. Fates-CLM has been brought into PECAN, which is a system for parameter sensitivity analyses.
What is the relationship between CLM and the E3SM land model? To a large extent, E3SM started with CLM4.5 and then added the phosphorus cycle. E3SM doesn't have most of the developments in CLM5. There are big divergences in BGC (CLM5 has a lot of new N cycle developments, such as FUN, which are not in E3SM), crop model (both CLM and E3SM have some pieces that the other doesn't have but would like), etc.
LILAC should probably satisfy a lot of the uses discussed here. However, one thing that could be missing is if LILAC just handles the land-atmosphere coupling: we could also need coupling at the bottom interface, from land to hydrologic models.
Dave L: Seems like the biggest challenge could be coupling. He doesn't see any major barriers to our plans for moving forward with CTSM based on what's been discussed.
Performance is important, because in applications in which Noah-MP is used, there are tight performance constraints.
Out-of-the-box: CLM4.5 with satellite phenology roughly 15x more expensive than Noah-MP. CLM5.0 with satellite phenology 36x more expensive than Noah-MP.
However, there are some big differences between the two:
- PFT representation: Noah-MP uses the equivalent of 2 PFTs
- Soil layers: Noah-MP generally uses 4 layers
- Number of iterations
- Internal memory allocation inefficiencies in CLM
Able to get about a 90% timing reduction from the CLM5.0 default from addressing the above 4 differences - so CLM 4x more expensive than Noah-MP.
The big remaining culprits are canopy and bare ground fluxes. There's good hope that we could reduce those further with some more work; also note that CLM uses a more complex photosynthesis scheme than Noah-MP.
Note that the Noah-MP driver scales terribly. These numbers just look at the land model itself, not the driver.
These numbers also remove i/o (which accounts for order 10% of CLM runtime).
Dave L: Overall feeling: We are probably close enough to Noah-MP that performance isn't a show-stopper.
We'll plan on monthly meetings, last Wednesday of the month.
Martyn gave an overview presentation. The following are notes from the discussion:
One big challenge moving forward will be governance - how to pull together multiple communities.
Ned raises the point that it would be good to have a more robust, easier-to-use system for 1-d land-atmosphere simulations.
Tim Hoar: Will you be able to do ensemble data assimilation via LILAC? e.g., in CESM you can use the multi-instance capabilities; will there be something similar via LILAC? We need to look at this - e.g., look at how this is done for WRF-Hydro, and make sure CTSM-LILAC will fit into this?
Will LILAC be usable for more simple-to-use data atmosphere-forced (land only) runs? Current plan is to continue to use cime/CESM for this, with the data atmosphere-LILAC piece just being used for software testing. In principle, we could use LILAC for this, but the plan is to add more capabilities / simplicity to the cime/CESM infrastructure for this purpose.
Isotopes is a near-term application area where the software redesign for CTSM will be a big benefit.
Besides model structure, another reason why CLM hasn't been used in many application areas in the past has been efficiency. This has driven one of the key focus areas of the recent CTSM work, which Mike will talk about.
Some notes from discussion:
How do you select different options? There will be some high-level selection of (e.g.) CLM5 physics, or a certain Noah-MP package. But then you can mix and match - e.g., mainly use CLM5 physics, but parameterization X from Noah-MP.
Request for some API documentation of different parameterizations. e.g., things along the line of what's required of a parameterization - does it need to compute derivatives, for example?
- There is some documentation along these lines within the code, but there is more that can be done here.
What are the near-term steps?
- A high priority is bringing in the Noah-MP parameterizations. Along those lines, SoilHydrology has been the top priority.
- Isotope development is driving some other priorities; first piece there will be CanopyHydrology.
Request for more visibility of the planned course. In part, these monthly meetings will address this.
There are some areas in which we've departed from the original plan:
- Migration to git/GitHub: this took a large amount of time, but has been hugely beneficial
- Work on performance, to make sure CTSM won't be substantially slower than Noah-MP
(Deferred to the next meeting.)
-
General
-
Documents
-
Bugs/Issues
-
Tutorials
-
Development guides
CTSM Users:
CTSM Developer Team
-
Meetings
-
Notes
-
Editing documentation (tech note, user's guide)