-
Notifications
You must be signed in to change notification settings - Fork 312
Meeting Notes 2020 Science
- Keith provided this documentation
- CTSM Newsletter 'published'.
- Keeping track of accomplishments & new updates?
- Upcoming model developments
- CTSM 5.1, includes FATES-sp, Biomass heat storage, + PPE branch
- CTSM 5.2, includes new surface datasets (Shifting cultivation, new lake dataset, new urban dataset, etc). a few working configurations to run with mizuRoute is independent of surface datasets, but would come in around this time.
- LMWG & BGCWG meetings, suggested Feb 23-25
- Reduced complexity modes allow testing and evaluating potential biases in the full FATES system
- specifically FATESsp uses three namelist switches:
- use_fates_nocomp=.true. (Each PFT on it’s own patch)
- use_fates_fixed_biogeog=.true. (binary mapping from HLM pfts to FATES pfts)
- use_fates_sp=.true. (reads in LAI streams)
- specifically FATESsp uses three namelist switches:
- FATES-sp has high GPP bias, especially around C4 grasses,
- Also feature in big leaf CLM & highlighting the need to evaluate C4 photosynthesis in CLM & FATES.
- FATES-sp potentially has low ET biases, but Dave noted the fluxnet ET product may not be the gold standard.
- Parameter sensitivity test show that clumping index, stomatal slope & Vcmax were strong controls over ET and GPP.
- Surprisingly, dleaf was not a big lever, perhaps because of know issues
- Additional testing with FATES-hydro warranted, but not functional in FATESsp presently.
- Slides can be seen here
- Bring FATES nextAPI (currently at dev105, Greg) up to current CTSM dev tag & merge onto
main(Erik). - Once latest FATES is on main-development, we will deprecate the use of the fates_next_api branch (fates developments will go into CTSM as other tags)
- Beta testing of coupled CESM2 (with data ocean) desired, will require new compsets from CTSM & CAM.
- Goal to have this done by LMWG meeting in Feb.
- Instructions for using the containerized CESM-Lab is posted for beta-testing
- Working group meeting, suggested Feb 23-25 from 9-12 Mountain.
- Dave's update on Isla's work on TREFHT variance (its not zetamax)
- Quadratic bug fix (small answer changes) and the
- Snow burial fix(larger answer changes). You can see results here.
- If and how to:
- Coordinate & build automated workflow
- Create & maintain datasets
- Standardize new & existing analysis & visualization tools
- That facilitates CTSM use in:
- Development
- Evaluation
- Forecasting
- Education & Training
- More...
- Slides for the discussion can be found here
- Containerization this was mostly in the chat, but it seems like a big interest and need in the community. I'm inclined to try to encourage people to use the CESM-lab containerized product if it fits their needs and to avoid duplication of efforts.
- Perhaps a demonstration of current capabilities at a forthcoming meeting would be helpful. Input from broader group might identify other strengths and weaknesses and needs. This would likely be facilitaed by a bit more work setting up the infrastructure to conduct single point runs from the containerized CESM.
- Single point inputs from atmospheric forcing, surface datasets, and domain files it seems like many of us are using a workflow that's no longer uses the PTCLM tools or the steps outlined in the user's guide. How do we best revise this workflow, code, and documentation?
- We now have a lot of sites ready to go (170 PLUMBER2) and working towards a bunch of NEON sites. Once we have a site setup, it's setup and we can maintain that. The tool we need is automated downloading and updating of the NEON forcing and observational data.
- Automated workflows Keith's .csh script does this. With some SE support this can be made more extensible & user friendly? Is this something that we maintain officially or w/in tool/contrib?
- Probably harder to make this work more generally in cloud or other systems, so maybe that is where the focus should be.
- Analysis does this rely on modelEvaluation.org, ILAMB, or a set of scripts we (re)build on our own? There seem to be some clear advantages to both outsourcing this or just keeping the analyses in-house (especially w/in CESM-lab).
- This conversation could be deferred a bit, as it needs more thought and maybe not at the top of the list in terms of 'urgency'.
- Forecasting Mike & Quinn would like CLM participation. In previous conversations with Danica, Mike suggested that necessary input data are already formatted correctly because he can use them with CLM in PECAN. Dave noted, that the Ecological Forecasting challenge is worth considering if ecological forecasting is an ultimate goal. They have setup all the parameters and protocol. My reading of the protocol is that late entries will be accepted, so maybe this could be something to focus on later in year 1 of the NCAR-NEON proposal as proof of concept for a subsequent proposal. Whether or not 'we' do it would depend on whether or not we have time.
- CESM2.2 release tag made
- CTSM5.1 tag made
- FATES w/ nutrients and hillslope are on their way.
- CESM2.2 release ~ 2 weeks away
- Sean and Jackie have hillslope-FATES model running! Hopefully updates to come.
- Gordon awarded NSF Cyber-infrastructure award for NEON-NCAR collaborations to run single point CLM in cloud w/ NEON data
- Gretchen welcomed Eugene into her family
-
Seasonal-to-MultiYear Large Ensemble (SMYLE)
-
20-member, 2 year hindcasts initialized 4x/year (Nov 1, Feb 1, May 1, Aug 1)
-
Initializations spanning 1970-2019 (50 years)
-
ESPWG is keen to get the best initial conditions out of each component model
-
LWMG interest and contributions?
-
Science questions to explore?
-
Validation data for hindcasts?
-
Dave and others have questions /concerns re. drift and assessing model skill?
-
CLM5 initialization
-
JRA55 being used to initialize sea ice, ocean (and atmosphere?) components
-
CRUJRA55 used by TRENDY
- Use Danica's recent TRENDY simulations as the initial conditions used for the SMYLE hindcasts?
-
FROM TRENDY Ian Harris (UEA) merged the “new generation” reanalysis from JRA-55 (Japanese 55-year Reanalysis) with the CRU TS dataset.
- All JRA-55 data are regridded to the CRU 0.5° grid using appropriate NCL routines based on the Spherepack package, and masked to give a land-only (excluding Antarctica) dataset.
- For the four variables tmp, dswrf, shum and pre, JRA-55 is aligned to CRU TS (v4.03) tmp, cld, vap and pre (also wet) respectively over land, using the same transformations as previously. The other four variables (pres, ugrd, vgrd, dlwrf) pass through without further modification.
- For years between 1958 and 2019, JRA-55 is used.
-
CLM5 with CRUJRA55 from TRENDY results are here http://webext.cgd.ucar.edu/I20TR/_build_set3G/index.html
-
Sensitivity of model initialized with different forcings (e.g., GSWP3)?
-
Nudging to observed states
- e.g., Modifications to get better mean sea ice thickness.
- Similar changes for land (soil moisture, LAI)?
-
Do we use some kind of anomaly forced spinup so the transition to the coupled climate is less abrupt?
- Will present to co-chairs next week. Need to find out if Mike Mills and others have time to do this quickly?
- Seminar room, Chapman and Damon all reserved for week of Sept 27 2021, but updates on remodel are TBD.
- Paul is unclear if Fleischmann building will be available for workshops.
- Do we consider saving space at CG as a backup? YES, let's just make sure we have a space.
- Greg's rebase PR:
- up to dev_tag093 on Greg's repo https://github.com/glemieux/ctsm/tree/fates_main_api
- regression tests completed
- look for users to test this (Jackie has volunteered)
- will create branch on ctsm github soon (needs cime update)
- eventually want to merge into CTSM5.1 tag
- Rosie and Charlie's work, especially WRT the rebase (#1);
- This is already included in the fate_main_api rebase
- Charlie has additional PR to help understand timing costs of FATES.
- Wait for Rosies return to get 'final' parameterization
- Do we need to harmonize Jackie's fire parameterization and Rosie's work?
- Getting CTSM-FATES into the CTSM5.1 tag (is this necessary for #4) and
- NO, run from branch, which is close to update with CESM2.2
- Need to resolve lightening data that FATES reading in [Erik].
- Maybe some cime updates, but Greg thought these would be pretty simple
- Running coupled CESM simulations this fall, what support do we need to get this to happen?
- Jackie and Charlie will do some testing from Greg's branch
- Rosie will confirm the parameter choices we're using
- Keith will run 2 degree offline w/ prescribed biogeography w/ competition
- These simulations will be used to produce initial conditions for F_case to run CAM6 w/ fixed sst's.
- Dave suggested that maybe run several flavors of FATES, since we aren't limited by computing?
- Timing costs of CTSM(FATES)
- Charlie thought there's potential savings in the vertical leaf layers that FATES is carrying around, which uses lots of memory.
- will look at this down the road to see where efficiencies can be made
Dave encouraged everyone to go ahead a spend our computing hours, starting with the TSS account
- Yifan Cheng, postdoc in RAL
- Meg Fowler, PS in TSS & AMP
- Hannah Holland-Moritz, graduate student @ CU
- A number of simulations to consider, esp. full matrix of FATES and CESM-FATES simulations
- Also discussion of 'high res' simulations (e.g. Hill slope model & vertically resolved canopy).
- snow density from LUMIP
- coupled vs. offline model results in LS3MIP
- CLM tutorial, how much lead time do we need?
- In person seems preferred.
- We need ~ 6 month lead time to plan.
- Will can look into reserving the main seminar room in Summer - Fall 2021.
- Danica noted how busy summers are, with CESM workshop and CESM tutorial in June & Aug.
- Danica also suggested we could update current tutorial information (and upload lectures) in short term if needed?
- Brief discussion on FATES contributions.
- CTSM 5.1 will have new surface datasets
- Modifications to urban, gross unrepresented land use change, changes to crop/pft distributions
- Suggest not maintaining backwards compatibility
- FATES logging PR seems ready to go for beta-testing, hopefully an AMIP run this summer!
- Will need new forest harvest datasets down road (directly from LUH2 through streams file).
- LILAC tag made!
- Leah's PR and LUNA bugs (nearly) finalized.
Reports on WRF runs with different land models, inc. CLM4.5
Let's consider having spatially-explicit planting date windows for each crop, based on Bill's dataset.
To get interannual variability, we could change the time within that window based on some rules, using shorter-term indicators than what we currently use - i.e., ditching the current metric of GDD since the start of the year, since that probably has low correlation with planting dates. These metrics could include soil moisture (soil moisture not too wet, not too dry) and/or antecedent precipitation (in some regions), absence of snow, and soil temperatures (10cm?) above freezing. A literature review may turn up additional or more refined possibilities.
Related to this, Beth Drewniak tested a few additional planting date rules in ELM based on a paper by Dobor et al. (2016). This analysis builds on a series of rules to see which provided the most reliability. The soil moisture rule is pretty broad (between 20-80% saturation). Beth added it to the ELM climate driven planting date, but didn’t see much of an impact. There is a trend toward earlier planting in the ELM planting date model, but it is very small.
We probably won't focus on trying to capture long-term trends for now, since those are probably based partly on technology / management rather than just climate.
Once we have ingested this data set, we could also have an option to use fixed, specified dates (e.g., the midpoint of the planting date range). And actually, it could be useful to do an initial sensitivity experiment: how sensitive are various model results to the planting date when it is varied from the start date to the end date of the planting window in each region?
Dobor, L., Barcza, Z., Hlásny, T., Árendás, T., Spitkó, T., & Fodor, N. (2016). Crop planting date matters: Estimation methods and effect on future yields. Agricultural and Forest Meteorology, 223, 103–115. http://doi.org/10.1016/j.agrformet.2016.03.023
This is a very preliminary analysis: no effort has gone into improving scientific performance of this coupling (we're still verifying some of the coupling fields).
CTSM took about 20% of the time of WRF. This was with hourly output, with a 90s time step. Expectation is that this could be improved, partly by reducing output, and possibly through other means.
Evaluations of scientific performance: Again, it's really important to note that no effort has gone into improving this.... That said, CTSM is currently showing a high bias in temperature across much of CONUS.
Tim Hoar: Based on his experience with WRF DA, WRF with Noah could be getting the right answers for the wrong reasons (e.g., bad soil moisture; improving soil moisture degrades the coupled simulation). This further emphasizes the point that not too much should be made of the degraded scientific performance with CTSM at this point.
Initial conditions for land for CTSM: Currently, use climatological initial conditions, not specific to the given time period. Tim Hoar points out that we could use the DART hindcast data assimilation product for the sake of initialization.
(I didn't get many notes on this, since I was giving the presentation.)
Ethan G: It seems possible that the redistribution of data between the atmosphere and land decompositions could be a bottleneck, at least at high processor counts.
- Bill: We definitely want to measure this. Based on experiences with CESM, this redistribution doesn't seem to generally be a bottleneck, but we do plan to check on this. If necessary, we could introduce a new decomposition method in CTSM that allows it to use the atmosphere's decomposition.
Ned: How to handle urban, specifically thinking about buildings that extend into the atmosphere?
- Mike Barlage: There is some question about where the urban model should live: inside CTSM vs. inside WRF.
- We'll have a future meeting focused on urban
-
General
-
Documents
-
Bugs/Issues
-
Tutorials
-
Development guides
CTSM Users:
CTSM Developer Team
-
Meetings
-
Notes
-
Editing documentation (tech note, user's guide)