-
Notifications
You must be signed in to change notification settings - Fork 92
2021 Software Engineering meeting notes
Last meeting of the year
- E3SM Issue 4709 (Memory Leak)
- Design of a fates output analysis script that is: python, supportable and user-friendly
- Weekly review of the PR Status Board: https://github.com/NGEET/fates/projects/7
- Walk on topics
- Ryan and Greg don't recall having seen MEMLEAK in ctsm before; Is there a difference between the hlm tests for this?
- Ryan is running a single site through Valgrind to assess.
- Ryan considers this a replacement for ACRE
- Ryan asked for some feedback and ideas on what we'd like to see in the way of output analysis script
- From a SE standpoint, Greg would like to have rapid plotting to help streamline global plots and regions of interest to asses DIFFs.
- Justifications for developing an analysis script: Reducing common pain points, particularly for new users
- Picking a cartographic plotting library (there are multiple options)
- Handling multiplexed dimensions
- Charlie started adding support in https://github.com/NCAR/ctsm_python_gallery/blob/master/ctsm_py/fates_xarray_funcs.py
- 'Canned' analysis that help educate users about output variables
- Have script provide users with list of (non-standard) variables to be added to their case
- Handling time conversions, particularly for discrepencies between
cftime
expectation and hlm output reality
- Script should be fates specific, but hlm agnostic
- Scripts versus notebooks discussion: should the script be a vehicle for educating users for more complex analyses?
- Script should have thorough documentation in code and with user guide. Perhaps notebooks for replicating the script line by line as tutorial?
- Aside: Greg thought this PyCon presentation on different types of documentation was helpful.
- Aside: xarray bug to be submitted by Ryan (corruption of netcdf file)
- Variable VAI bins, ctsm-side: https://github.com/ESCOMP/CTSM/pull/1562
- After discussion with Erik it was determined we should not integrate with upcoming non-b4b ctsm tag
- Erik had already started a draft PR, so we will use this
- Additions to the PR: Ryan noted from his script work that a dimension was missing and unit meta data as well
-
fates_levelement
needs to be added - need units for some of the definitions (e.g.
fates_levheight
)
-
- After discussion with Erik it was determined we should not integrate with upcoming non-b4b ctsm tag
Canceled due to AGU
- Plan towards FATES-ELM API 20
- API 18: Passing in fates%bc_in(s)%fcansno_pa(:) (Greg contacted ELM team)
- API 19: History overhaul (interface call order for zeroing and initializating)
- API 20: Running means (required splitting initialization sequence and passing model timestep early)
- Weekly review of the PR Status Board: https://github.com/NGEET/fates/projects/7
- Walk on topics
- API 17 PR under testing and review
- API 18 conversation kick started. Short term plan should be very easy and b4b.
- API 19 should be very straight forward (testmod variables update)
- We should start a conversion to discuss alternate PR workflows (Charlie)
- Should we condense multiple API updates together? E.G API 18-20
- For reference, ctsm folks like API updates to be b4b generally if lumped together. What does e3sm want?
- Should we adopt a fates_api branch for e3sm?
- This might be more palatable if e3sm likes a milestone-based approach
- This re-introduces the non-trivial task of having to rebase the api branch into master
- This might be preferred to e3sm given the standard practice of rebasing
- Should we condense multiple API updates together? E.G API 18-20
Testing
- 752: In progress
- Under Review:
- 766: Ryan to prioritize and work through checklist. Will ask me and Junyang for review.
- 800: Ready and waiting on review. Ryan self-assigned for review.
- Does not necessarily need to be synchronized with a ctsm-side API, but there are ctsm-side updates that could be rolled into a future PR.
- Charlie and Rosie to review as well.
- To Do
- 816: Marcos to test if original issue is fixed with latest tag (running means)
- 817: SP mode crops
- This is dealing with crop aream, not running like clm crops
- Rosie noted that Dave Lawrence stated that crops get shunted into nat veg
- Rosie illuminated and fixed bugs wrt order of operations for
init_cohorts
- Marcos to create an issue regarding spitfire and humidity
- Anecdotes about modern Fortran and showing FATES to others outside the subject matter
- Reference book with Fortran standards author: https://global.oup.com/academic/product/modern-fortran-explained-9780198811893?cc=us&lang=en&#
- Discussion about
bstore
- Water use efficiency discussion
- Allometry discussion about crown area
- ERS sp mode fix update: https://github.com/ESCOMP/CTSM/issues/1485
- P32x2 issue fix plan: https://github.com/ESCOMP/CTSM/issues/1518
- ELM-FATES Fractional snow coverage next steps for recent fixes: https://github.com/NGEET/fates/pull/750
- Weekly review of the PR Status Board: https://github.com/NGEET/fates/projects/7
- Walk on issues
- Greg determined when the failure mode switched from COMPARE_base_rest to RUN
- With Ryan's help, Greg has a test running to check the hypothesis that the changes to
update_hlm_dynamics
is causing the issue.- Assuming this is successful, then move on to assessing original failure mode during the restart comparison
- Greg to test out two hypotheses:
- Bill's suggestion to isolate code failure with appropriate OpenMP pragmas
- Erik's suggestion to change test to utilize all 36 processors on cheyenne (32 is a suboptimal split and could be causing some issues)
- Ryan noted that fates by design is typically thread safe
- Jennifer isn't aware of any fractional snow in e3sm
- When did this get introduced to ctsm?
- Charlie found that CLM5 paper (by Dave) seems to intro the concept to ctsm
- FATES-CTSM sp mode plus crops
- Rosie is starting to looking into how to handle crops during fates sp mode.
- Original method zeroing out crops in data doesn't seem to be working, so Rosie pivoted to trying to appropriately handling crops
- Rosie is starting to looking into how to handle crops during fates sp mode.
- Global PFT allometry parameterization status
- Discussion of allometry parameterization and with whom to coordinate on development
- Ryan has a google spreadsheet he's working up to organize the particular people and plans for a given PFT (he'll share this in the near future)
- Allometry updates are a high priority after SP mode fixes and fates-sp mode update to e3sm (per Charlie)
- Discussion of allometry parameterization and with whom to coordinate on development
- History refactor status update for the community
- Ryan will check in with Adrianna about writing up a fates community email to announce the change
- Final testing
- 752: Charlie to work on variable VAI bin widths now that history refactor is integrated
- Review
- 800 and 804: Marcos ok'd us
git cherry-picking
the relevant commit in 804 to create a new PR- Greg to take this. Ryan thinks review has been pretty thorough so we can start testing as soon as new PR is ready.
- 792: Ryan wants to re-review and see if there are more variables that we should be assessing to report to the log. Lower priority compared to others tho. Move into To Do?
- 800 and 804: Marcos ok'd us
- To Do:
- 768: Ryan and Jennifer prioritizing to work on this to bring it to review in the near future.
- Discussion of fates-docs appendix variable list: https://github.com/NGEET/fates-docs/issues/1
- Weekly review of the PR Status Board: https://github.com/NGEET/fates/projects/7
- Walk on topics
- For now consensus is to use a simple table
- We can look at future proofing with in code string docs
- Related: discussion of promotion of tech note updates
- At the least, maybe we should request that any new history variables get updated with associated pull requests
- Final testing
- 750: imminenent. Waiting on one non-fates failure.
- Greg modified tests to take care of some erroneous test updates that came in with dev062
- Prioritize an e3sm pr to correspond to this pr as well
- 802: conditional on 750. Ready otherwise.
- 750: imminenent. Waiting on one non-fates failure.
- Under Review
- 792: deprioritized for 724
- 724: Ryan actively updating to assess the differences he's seeing
- 766: Ryan to work on after 724
- To Do
- 804 and 800: 804 is built on top of 800. Marcos will recreate 804 to make it stand alone.
- Move 800 to 'Under Review'. Ryan self-assigned to review
- Punting on whether or not to make this simple scheme the default to a future discussion
- 804 and 800: 804 is built on top of 800. Marcos will recreate 804 to make it stand alone.
- WIP
- 801: Discussion of current progress
- 769: Will need conflict resolution post VAI bin widths integration
- 768: Jennifer anticipates revisiting this soon.
- SP mode ERS fix prioritization: https://github.com/ESCOMP/CTSM/issues/1485
- Update the issue with the fact that its failing prior to getting to the COMPARE_base_rest now
- Are the points where the model is failing in the same area or is the failure mode orthogonal to original issue?
- ctsm nuopc update causing snags in single point builds
- Adrianna shared the clm meeting recording where this was telegraphed
- Charlie suggested making an issue on fates repo to point to the ctsm relevant PR (Ryan to do this)
- We should also do some outreach to let people know about this on the fates-side, who might not participate in the clm meetings
- Project board new column
- Should we have columns for ctsm and e3sm PRs?
- Demonstration of Google Colab Allometry Notebook (Ryan)
- Weekly review of the PR Status Board: https://github.com/NGEET/fates/projects/7
- Summary of new PRs in "To do"
- Google colab is place to host jupyter notebooks: https://colab.research.google.com/
- Ryan gave us a step-by-step overview of how he has setup a colab notebook to run functional unit tests for the allometry code
- Goal: make this user-friendly to allow users to test out alternate parameterizations
- Compiling on colab allows users to more easily compile fortran, instead of trying to run locally
- Sharing on google colab seems to still be a work in progress
- PR 724: in progress, moved back to "Under Review"
- PR 750/752: waiting on new ctsm dev tag
- PR 805: needs regression testing
- PR 802: still needs review, but prioritize for integration after 750/752
- PR 800/804: bug fixes
- PR 801: Move to WIP
- Aside: https://github.com/NGEET/fates/issues/799 noted as location to put future post-api17 updates
- Action: Greg to draft up the elm-sp mode pull request - COMPLETE
- We also need to get an elm-side fix for PR 750
- Adrianna noted that Bill is looking to have a meeting to discuss the fates api tagging process
- Productivity note: version control visualization with ReviewNB (Greg)
- Final steps for https://github.com/NGEET/fates/pull/750?
- Radiation errors uncovered in https://github.com/NGEET/fates/pull/750
- Brief summary of and action plan for new PRs
- Walk-on topic: Galaxy clm-fates
- Diffs and commenting for Juypter notebooks: https://www.reviewnb.com/
- Greg noticed this in the context of the ctsm-python-gallery PR notification: https://github.com/NCAR/ctsm_python_gallery/pull/37
- This is good to go; fates-side testing ran with diffs as expected.
- There is a ctsm-side associate PR. Greg made Erik away and put it on the 'next tag' ctsm board
- Greg is waiting on dev062 to integrate before final testing using
aux_clm
- Inhibited second canopy layer test case from Charlie was presented
- Abrupt transition seen in rad_error seen here: https://github.com/NGEET/fates/pull/750#issuecomment-961332679
- Charlie doesn't think its the onset of n new cohorts or trimming given timing (doesn't occur at end of year)
- Hypothesis is that lowest leaf layer is partial fraction of a layer. There was discussion of potential modifications to test the hypothesis.
- Jackie suggested migrating these results and future discussion to the existing radiation balance error discussion for further discussion
- Deferred discussion of the new PRs that Marcos created as he was unable to attend the meeting
- Discussion of history variable refactor PR 802 zeroing of values
- Current recommendation is to add the new
zero_site_hvars
wrapper call to clmfates_interfacemod - Should we address direct variable zeroing in
update_history_dyn
with this PR?- Consensus was to leave this for a future PR. This idea is addressed in existing issue #231
- CTSM-related: should the companion variables on the ctsm-side align to the new fates units and when?
- Action: Greg to review companion CTSM PR 1542. Ryan to review 802.
- Current recommendation is to add the new
- Discussion of [no-comp logic fixes in PR 805](https://github.com/NGEET/fates/pull/805#discussion_r745083443 and potential future logic update (patch-level versus site level))
- PSA posted on fates issues:https://github.com/NGEET/fates/issues/806
- Action: Greg to ask about future update/trainings in the issue
- Ryan suggested chiptune (8-bit) background music for fates animations. Adrianna discussed interests in developing more animations for fates data representation.
- History refactor issue:
hio_mortality_si_pft
returning large number during first time step - Discussion of elm-fates sp mode comparison to clm-fates sp mode. Greg's notebook with comparison of results
- Check-in on radiation_error issue in PR 750
- Weekly review of the PR Status Board: https://github.com/NGEET/fates/projects/7
- Adrianna noticed that the
hio_mortality_si_pft
was returning a large variable output for the first time step - Removing the call to
update_history_dyn
results in a consistent value between thehio_mortality_si_pft
output and them
value calculations- Ryan noted that there are things that are updated and need to be calculated prior to the call in
init_coldstart
. -
hio_mortality_si_pft
should be zero at the first time step, correct?
- Ryan noted that there are things that are updated and need to be calculated prior to the call in
- Charlie: testing on a grid might be helpful in illuminating (Adrianna currently compiling with single point)
- Adrianna to start up a ctsm-side branch to help assess possible ctsm-side issue to help resolve the issue
- This might necessitate a larger refactor that is out of scope of the initial PR. Some short term suggestions made.
- There was general agreement that the fates sp mode seems to be qualitatively consistent between the two host land models
- That said, this assumes that the differences are largely due to areas where crops are predominant.
- Double checking the host land model runs, crops are turned off for HLM-SP mode (
use_crop = .false.
)- Note:
create_crop_landunit = .true.
for HLM-SP mode
- Note:
- Double checking the host land model runs, crops are turned off for HLM-SP mode (
- How to get a comparison by including crops or excluding crops in the runs?
- Rosie modified the dataset: she will get Charlie the dataset mod script
- See discussion of how to reconcile crops and fates-sp mode in issue #760
- Ryan suggested checking to see if a crop-specific LAI exists that could be accounted for in post-processing
- Charlie suggested we could possible correlate with albedo variables
- That said, this assumes that the differences are largely due to areas where crops are predominant.
Radiation error check-in (https://github.com/NGEET/fates/pull/750#issuecomment-950013937)
- Charlie noted that the radiation error was not failing out with the most recent commits
- Greg noted that the radiation is blowing up and crashing the run
- Charlie will do the experiment to compare to his output previous to Rosie's commits
- Ryan making progress on Junyan's PRs
- Ryan running means still doing some review
- Try and get #752 integrated this week
- ELM-FATES SP mode status update (Greg)
- Check-in on Running Means: https://github.com/NGEET/fates/pull/724
- Check-in on radiation_error issue in PR 750
- E3SM-FATES regression test list status and future update discussion (in the context of recent CTSM #1275)
- weekly review of the PR Status Board: https://github.com/NGEET/fates/projects/7
- Greg reported that elm-fates versus clm-fates comparison forthcoming.
- Ryan asked about success of exact restart
ERS
tests with elm-fate spmode.- Greg has not done this yet, but is a good idea to check. Also relevant to E3SM-FATES regression test list.
- Ryan reported differences between main branch and new running means on an f10 grid: https://github.com/NGEET/fates/pull/724#issuecomment-950361105
- This was run with fire on
- Charlie asked to have burned area checked as well
- Jackie noted that ultimately we should fix the temperature used for fire to be highest and not average, but this update is consistent.
- Detailed discussion largely deferred for later review with PR author
- Charlie noted that it looks something that was committed to the repo last week is introducing the issue.
- It was noted on the call and on github that radiation code could benefit from overall refactor
- Plan is to first address the issue at hand in this PR without refactoring
- Jennifer and Ryan agreed to put together a list of possible tests, and check in with the E3SM team to find out how much testing is reasonable to add to their land developer suite
- Ryan suggested adding topographic tests that was added recently
- VAI bin widths (#752) has no new update since last week.
- Leaf water potential (#736) is currently being updated by Ryan in prep for final testing
- hlm_pft_map pr (#798) should be bfb
- #768 dev on hold for the next two weeks per Jennifer
- Discussion of testing results wrt hydro. Ryan and Adrianna agreed that a retest should be done.
- Thank Greg for taking awesome notes
- History refactor updates
- E3SM-FATES regression test list status and future update discussion (in the context of recent CTSM #1275)
- Discuss #792 and report discussion with CTSM software meeting last week
- What is integration plan for #750?
- weekly review of the PR Status Board: https://github.com/NGEET/fates/projects/7
- Discuss Solar Radiation error Handling Issue #794 that came from PR792
- Adrianna presenting the notebook that she has created to run a comparison check on the variables
- Discussion of consistent
max_diff
error- Current hypothesis is that this is a double versus single precision issue
- Still need to check a few other categories of variable
- Requested double check on csv comparison table logic
- Current plan is to provide the csv file to public so that users can update their scripts
- Tabled until we can discuss with E3SM rep
- There was a good discussion during the ctsm software meeting last week about the distinction between warnings
- Ryan has started developiong a new warning reporting function
FatesWarn
- Prints warning message passed to the function and counts the number of times warnings have been issued
- Also can input and index to bin the warnings to a particular group each of which keeps separate counters
- Aside: Is e3sm seeing solar radiation balance logging?
- Action: Charlie will add comparison check results from using sp mode with and without these fixes
- Action: Rosie to test that the code gives the exact same results as before when I revert the leaf fraction to 1.0
- PR 724: Greg reviewed ctsm-side and doesn't think we need more review on that side. Will test this week and coordinate with Erik for integration timing.
- Ryan created a one-line
IBMfix
for e3sm due to specific issue. This is on API 16, so we'll need to bring this over to the next api update. - Prioritization of "Under Review"
- 752 should not be answer changing. Parameters that govern this PR have already been integrated in a preview tag. Agreed to move to testing.
- Action: Greg to test
- Quick overview of issue 794 (solar radiation error handling) to spur future discussion on github as we were close to time.
- what's going on with indenting and whitespace?
- check-in on history refactor
- check-in on #738 (rooting depth PR)
- check-in on #768 (nutrient controls on photosynth)
- check-in on CTSM #1275 testing updates and cleanup
- walk-on topics
- weekly review of the PR Status Board: https://github.com/NGEET/fates/projects/7 - SKIPPED
Whitespace standardization methodology discussion
- Do either of the host land models have styleguide?
- Adrianna noted that Bill suggests a particular Fortran documentations
- Current fates styleguide: https://github.com/NGEET/fates/wiki/Coding-Practices-and-Style-Guide
- Suggestion to provide examples of IDEs/editors example of how to enable automated compliance
- Action: Create issue for discussion
- Testing forthcoming
-
flushval
discussion- For the time being we are going to stop spawning and destroying sites (ignore) in cases where unnecessary
- In the future we may need to revisit this for land use/land cover change or similar use cases where we would be spawning/destroying fates sites
- Discussion of
hio_leaf_md_canopy_si_scls
calculation and updating the long name
- Reviews are ongoing with some recent feedback.
- Qing investigating a different approach to calculate vcmax from leaf carbon without using scaling.
-
#738: Ryan wants Rosie to sign off on this before integrating. Tests look good.
- Rosie reviewing changes now
-
#1275: Held up due to two different test failures
- Failure downloading data for
aux_clm
NEON-specific site test.- Create issue and move on is recommendation
-
ERP_D_P32X2
fates test failing to RUN due to weird issue- Create issue and move on is recommendation
- Failure downloading data for
- Greg: Success with building sp mode enabled cases for e3sm. Dealing with run failure issue for parameter file. Assuming this is user error.
- Adrianna: Should we increase the character name length for fates history variables?
- Ryan: We probably need to review this with hlm folks
- Rosie: Having issue with python settings in Cheyenne.
- Charlie noted that this may help solve the issue
module load ncarenv ncar_pylib
- Charlie noted that this may help solve the issue
- Rosie: Working on single pft sp mode issue
Skipped since we basically covered the most pressing PRs.
- quick report back on Western Sydney University updates
- updates on #738
- discussion/updates of history file refactoring?
- SP mode issue discussion: #785 and #782
- weekly review of the PR Status Board: https://github.com/NGEET/fates/projects/7
- [-] audit our issues list https://github.com/NGEET/fates/issues
- Greg had quick update on status on WSU postdoc e3sm-fates progress per Assaf. They are going to run through the tutorial this week. Questions/issue likely forthcoming in the near future. No paired programming/walkthough conducted yet.
- Intent is to get b4b results; Ryan reverted
crown_depth
PR update and generated issue #789 to achieve this. - Question of why
master
is usingcrown_depth = min(1.0,height)
; consensus appears to be that this is incorrect. - Adrianna suggested using biomass and allometry dataset which has crown depth that we could use to benchmark against
- Short term plan: switch to using
crown_depth_frac
version of equation.- Marcos offered to provide references to papers on possible parameter settings for this variable
- Discussion of
C13disc_SCPF
usingper mil
as unit- CMIP is the only protocol that uses carbon isotopes which predicated the use of
per mil
- CMIP is the only protocol that uses carbon isotopes which predicated the use of
- Action: Adrianna to leave as is an make an issue
- Testing to be started end of week
- 785: grass phenology changes within sp mode
- This suggests that something is wrong specifically with grass phenology. Xiulin continuing to investigate
- Ryan suggests we should change the title away from sp mode
- 782: single pft check
- The check is working as intended, but it does raise a question with regards to how users want to run with a subset of the hlm pfts
- Consensus appears to be to leave the check as is, but to provide a more detail warning message about the intent of the failure
- Ultimately this should be discussed in detail in the technote
- The check is working as intended, but it does raise a question with regards to how users want to run with a subset of the hlm pfts
- CTSM PR #1275 update
- #735 is good to go, Ryan to integrate
- Run testing for #758 and #764
- Running means (#724) after CTSM #1275
- Moved #750 to under review due to Charlie's PR to Rosie's branch
- No audit; ran out of time
- Jackie highlighted #236 and #772 (Radiation balance check verbose output)
- Charlie noted #191 as well
- Ryan suggesting that we simply encapsulate all warnings with internal
debug
flag - Action Ryan to create a PR for this
- discuss tropical frost mortality question from Marcos
- discuss https://github.com/NGEET/fates/issues/770
- discuss changing list of
active
history output to include only non-multiplexed variables - review plans that resulted from team meetings on hydraulics pull requests, including #746,#766
- Discuss refactor to the history
- weekly review of the PR Status Board: https://github.com/NGEET/fates/projects/7
- Simulations show a spike in
M8_SCPF
- Possible uninitalized variable?
- Appears to be during the first time step only?
- Charlie: Soil carbon distribution as a related issue
- Charlie confirmed on the fly that this is occuring in the first time step across the tropics
- Action: Marcos to open an issue - COMPLETED (https://github.com/NGEET/fates/issues/781)
- Charlie/Rosie: The intent is to prevent the leaf layers from getting infinitely thin. Meant to act as a cap.
- Action: Ryan to close issue
- Rosie: Maybe we should maintain some multiplexed as active since users may be unaware of the fact that we have multiplexed at all. The sense is that users use the default output as the first way to learn about variables.
- Charlie: As a related aside, there is a
hist_fexcl1
variable that can be used in user_nl_clm to exclude active variables -
scorch_height
,nplant_scag
,fuel_amount_ageful
are very large multiplexed- Adrianna to set to
inactive
in her work on issue 630
- Adrianna to set to
- Action: Ryan to create an issue to get a discussion going with the wider FATES community
- 766 includes all commits from 746, so close 746
- error variable discussion
- Marcos suggested adding a flag to check budgets for error threshholds to allow user to set whether or not they want to stop a run
- Do we want to change the disturbance rate outputs from per day to per year?
- Charlie/Ryan: per year
- Leave
FATES_NPATCHES
and similar variables with empty units?- Yes (altenate idea was using
1
but consensus was too confusing)
- Yes (altenate idea was using
-
hlm_hio_ignore_val
versus0
implementation forflushval
on fates sites- We need to figure out which bounds in
Flush
routine are fates bounds and which are hlm bounds- Maybe add information to history variable type
- We need to figure out which bounds in
- Action: Ryan and Adrianna to talk more about this
- #724 is on hold until CTSM #1275 is integrated
- Charlie to deconflict #750
- Greg to review and sign off on #758
- plant hydraulics / frozen soils issues. set kmax_aroot_radial_out to near-zero when soils are frozen?
- restart tests. what variables to include? Probably we should just output all default variabes for more tests if its not too expensive.
- format of SW meetings. We need to start taking minutes/notes (hence this update), and make open to any interested FATES developers.
- next PRs to deal with (https://github.com/NGEET/fates/projects/7):
- https://github.com/NGEET/fates/pull/724
- https://github.com/NGEET/fates/pull/765
- https://github.com/NGEET/fates/pull/750
- https://github.com/NGEET/fates/pull/758 -- ready for testing and integration. should be b4b.
- https://github.com/NGEET/fates/pull/764 -- need to remove change to pftindexswapper. otherwise ready to merge.
- Longer term PRs:
- https://github.com/NGEET/fates/pull/735 -- needs scientific testing and comparison of observations on roughness
- Hydraulics PRs. Need more testing and review by others. Also remove overlap between some of them as well as changes to caps, multipliers, etc.
Requirements for CESM2 incorporation:
- No answer-changing changes to scientifically-supported configurations on CLM svn trunk after Sept. 1
- No code changes at all after either beginning or middle of November.
Tasks to get us to that:
Pre-september 1 changes:
- Start adding full CLM test suite to ensure compatibility with rest of model
- Finish bringing github mods to head of CLM trunk and make this the master branch
- sort of columnization issues
- possible issues with D. Kennedy's hydraulics code
- address any other issues that come up
- Finish the core interface development that is called while timestepping, e.g. any loop changes to photosynthesis code
- bring code from github master onto CLM trunk using diff tools
Post-September 1 changes
- non-timestepping changes
- I/O
- etc.
- remove ED subdirectory from CLM
**Have weekly meeting at 11-12 on Fridays. Charlie to send invite. **
For splitting FATES repo
- Ben to update PR #202 with recent changes : in progress (04/14)
- Ryan to pull in #202 and #207 before the split. : #202 in progress, #207 DONE (04/14)
- Have moratorium on new external pull requests before split. : DONE
- One/two more PR's necessary before split - cleaning up issues : in PR #211 (04/14)
Immediate CESM interface priorities (Ben)
- Merge FATES interface back into CLM svn repository
- Ben to initiate code review of CLM branch (svn) with CLM-CMT
- Test within CLM etc.
- Make FATES external for CLM.
- Maybe iterate any required changes back into FATES repo.
- Add FATES test for aux-CLM. (to make sure CLM doesn't break the interface)
- Replace use_ed with use_fates
Other priorities for FATES
- Parameter management code (cdl/netcdf conversions)
- Other outstanding FATES issues!
- integer & character reads on parameter interface
Other pre-release priorities for CESM (Rosie/Ben)
- Release date for CESM - non Breckenridge and/or 3 months after science freeze (tbc)
- Make CLM5-FATES compset in CLM5. (Ben)
- Test CLM5-FATES compset in CLM5. (rosie) 04/14 waiting for a sensibly integrated branch
- Change testing to have a CLM5-FATES test. (Ben)
Priorities for ACME (Ryan)
- Pull out code from ACME
- Link to Gautam interface.
Other
- Have weekly meetings at 11MT : 866-740-1260 , 4866724
- Charlie to call in to CLM-CMT meeting (Ben to inform Charlie when there is relevant discussion).
- CESM code freeze: May 17th hard code freeze. May 1st 'soft' testing deadline.
- merge conflicts with PHS balance checking: new routines for computerwatermass. Plan for making these changes...
- ED tests on Cheyenne; going to ignore until the repo split happens.
- progress on critical path since last week. (see above)
- Ryan has been working on ACME interface. A mystery person has been 'improving' it.
- Link to step-by-step for splitting: https://docs.google.com/document/d/1RqbeyyJbyTwR9QO-CrSU0wUKl_fcOqmUii7rTGT5kx8/edit
- Moved next weeks meeting to thursday 20th 11MDT
- Updates on critical path to splitting repo:
(1) PR #211(2) anything else? - bugzilla 2445 - How to deal with the new surface dataset situation in CLM which gives a separate land unit for crops, including generic crop, and always has generic crops... Probable fix is to make the crop_on_own_landunit flag (I forget its name) negative with ED, and change the logic of the negative case to entrain crop area into the nat veg soil in FATES for now. This will continue to make all the ED test fail (and thus we won't catch any other issues) in CLM until we find a fix.
- bugzilla 2442 - Recap on Cheyenne numCohorts issue. (to be looked at next week?)
- what we actually discussed:
- all PRs done. proceeding with repo split
- bug 2442. still need to figure out if its a pio issue or what
- bug 2445: short term plan is to turn off all generic crop-holding landunits and add that weight to the naturally vegetated landunit. longer-term plan is to figure out how to make FATES run on its landunit, CN corp model on its landunit, and have different instances of the BGC soil model work on each, with N turned off on the FATES LU and turned on on the corp LU. Erik will try to implement the short-term solution in next day or so so that it doesn't block CLM developments.
- once the repo split happens, Ben will oversee migration of the code from the NGT "CLM" repo to the CLM svn repo.
- clean up, use_ed to use_fates
- add fates/CLM5 compset. Charlie will discuss what switches ought to be enabled on that compset. then we can test and go from there.
- Ryan to add a change thread test.
- Your agenda item here
2024 Software Engineering Meeting Notes
2023 Software Engineering Meeting Notes
2022 Software Engineering Meeting Notes
2021 Software Engineering Meeting Notes
FATES API and Host Land Model compatibility table
Relevant References page (User's Guide)
Moorcroft et al. 2001. Ecological Monographs, 74:557-586.