Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add snow-vegetation interactions, NGEE Arctic IM3 #6607

Open
wants to merge 16 commits into
base: master
Choose a base branch
from

Conversation

thorntonpe
Copy link
Contributor

Change handling for how snow burial of shrubs is calculated, with parameterization for bending of stems.
Change the treatment of surface weather downscaling on topounits, so that the downscaling happens when using the coupler bypass code branch.
Introduce four new parameters controlling the burial of shrubs by snow into vegetation physiology file.
If new parameters are not included on the physiology file the code replaces with default values, which then produce BFB results with code before this PR.
The four new parameters are: taper, stocking, bendresist, and vegshape.
[BFB]
Development Lead: Rich Fiorella [email protected]
Development Team: Katrina Bennett [email protected], Cade Trotter [email protected], Claire Bachand [email protected]

thorntonpe and others added 15 commits September 11, 2024 15:51
Enables two major changes to the parameterization that calculates LAI
burial by snow: a) pulls stocking density and taper parameters that
influence vegetation height from hard-wired values in
biogeochem/VegStructUpdateMod.F90 to allow to be specified on the
surface file (per main/pftvarcon) and b) updates the LAI burial by snow
rate from Wang and Zeng, 2007 (linear burial) to form proposed
by Liston and Hiemstra, 2011 (linear or non-linear) burial. The Liston
and Heimstra (2011) formulation introduces two new parameters:
1) bendresist, which specifies how resistant branches are to bending
under snow loading (1 = no bending, lim->0 branches bend very rapidly)
and 2) vegshape, which specifies how the shape of the vegetation crown
affects how rapidly it is buried by snow (1 = paraboloid; 2 = hemispheroid).
These new parameters can also be specified on surface file.
Temporary change, pending merge of IM4 updates. IM4
removed a lot of the hard-coded tests that looked
for particular pfts by their assigned number. this required
modifying the helper function "woody" to be a non-binary
(i.e., now 0 = herbaceous, 1 = woody tree, 2 = woody shrub),
but this updated function isn't available to IM3 currently.
The taper array was being initialized incorrectly,
leading to developer test failures. This moves
the definition down further to be able to initialize
correctly.
Adds a new exact restart test that uses new parameters
in the param file for snow/vegetation interactions.
fixes an issue where using less than the maximum pfts
set new parameters with non-physical values
@thorntonpe
Copy link
Contributor Author

@peterdschwartz and @bishtgautam My branch is rebased to the current master. I think it should pass the land_developer test suite BFB.

Copy link
Contributor

@bishtgautam bishtgautam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@thorntonpe, the PR looks good to me.

I believe you inadvertently deleted a lot of whitespaces in this PR (e.g., https://github.com/E3SM-Project/E3SM/pull/6607/files#diff-f9276b0713e2af1bcd0495bdbd37de680e27b15dcf180b1d8da1ec0243ba17dfL39). Maybe the setting of your editor is such that it removes whitespaces automatically at the end of the line of the current cursor location and you can try avoiding whitespace deletion in the future.

@thorntonpe
Copy link
Contributor Author

@bishtgautam yes, the whitespace deletion was due to an editor setting from one of the LANL developers. I'll ask that they change that setting for future development.

@thorntonpe
Copy link
Contributor Author

Based on discussion yesterday at ORNL I looked into the CPP flags that might have some influence on the use of shared executables for land developer tests. I'm not seeing any obvious issues. Could we do a test integration of this PR?

@bishtgautam
Copy link
Contributor

We are waiting for the last two open PRs for the v3.0.1 tag to be merged. Then, we should be able to begin integrating this PR.

@peterdschwartz
Copy link
Contributor

submitted test suite on pm with this on next, so should know more tomorrow

@thorntonpe
Copy link
Contributor Author

I'm seeing the pm-cpu results show most tests passing, but I was expecting to see a fail (no baseline) for the new test in this PR:
ERS.ELM_USRDAT.I1850CNPRDCTCBC.elm-snowveg_arctic
That test is not showing up in either the PASS or FAIL lists.

@thorntonpe
Copy link
Contributor Author

@peterdschwartz Realizing now that your test suite was probably submitted outside the test dashboard. Ignore previous comment.

@peterdschwartz
Copy link
Contributor

@thorntonpe I did get several DIFFs while running the test suite:

ERS.ELM_USRDAT.I1850CNPRDCTCBC.pm-cpu_gnu.elm-snowveg_arctic (Overall: DIFF) details:
  ERS.ELM_USRDAT.I1850CNPRDCTCBC.pm-cpu_gnu.elm-usrpft_codetest_I1850CNPRDCTCBC (Overall: DIFF) details:
  ERS.ELM_USRDAT.I1850CNPRDCTCBC.pm-cpu_gnu.elm-usrpft_default_I1850CNPRDCTCBC (Overall: DIFF) details:
  ERS.ELM_USRDAT.IELM.pm-cpu_gnu.elm-surface_water_dynamics (Overall: DIFF) details:
  ERS.f09_g16.I1850ELMCN.pm-cpu_gnu.elm-bgcinterface (Overall: DIFF) details:
  ERS.f19_f19.I1850ELMCN.pm-cpu_gnu (Overall: DIFF) details:
  ERS.f19_f19.I20TRELMCN.pm-cpu_gnu (Overall: DIFF) details:
  ERS.f19_g16.I1850ELM.pm-cpu_gnu.elm-betr (Overall: DIFF) details:
  ERS.f19_g16.I1850ELM.pm-cpu_gnu.elm-vst (Overall: DIFF) details:
  ERS_Ln9.ne4pg2_ne4pg2.F2010-MMF1.pm-cpu_gnu.eam-mmf_crmout (Overall: DIFF) details:
  ERS.r05_r05.IELM.pm-cpu_gnu.elm-lnd_rof_2way (Overall: DIFF) details:
  ERS.r05_r05.IELM.pm-cpu_gnu.elm-V2_ELM_MOSART_features (Overall: DIFF) details:
  SMS_Ld1.hcru_hcru.I1850CRUELMCN.pm-cpu_gnu (Overall: DIFF) details:
  SMS_Ly2_P1x1.1x1_smallvilleIA.IELMCNCROP.pm-cpu_gnu.elm-fan (Overall: DIFF) details:
  SMS_Ly2_P1x1.1x1_smallvilleIA.IELMCNCROP.pm-cpu_gnu.elm-force_netcdf_pio (Overall: DIFF) details:
  SMS_Ly2_P1x1.1x1_smallvilleIA.IELMCNCROP.pm-cpu_gnu.elm-per_crop (Overall: DIFF) details:
  SMS.r05_r05.I1850ELMCN.pm-cpu_gnu.elm-qian_1948 (Overall: DIFF) details:
  SMS.r05_r05.IELM.pm-cpu_gnu.elm-topounit (Overall: DIFF) details:

Took one and submitted it by itself and it passes, so I can look into this further

ERS.ELM_USRDAT.IELM.pm-cpu_gnu.elm-surface_water_dynamics (Overall: PASS) details:

@thorntonpe
Copy link
Contributor Author

This is the same behavior I was observing. Thanks for looking into it.

@peterdschwartz
Copy link
Contributor

peterdschwartz commented Sep 13, 2024

Ok, I can confirm that error is due to the new test ERS.ELM_USRDAT.I1850CNPRDCTCBC.pm-cpu_gnu.elm-snowveg_arctic using MODAL_AER in ELM_CONFIG_OPTS.

When run as a part of the test suite, the EXEROOT for a DIFF'ing test will be set to the new test:

EXEROOT: /pscratch/sd/p/pschwar3/IM3_testing/output/ERS.ELM_USRDAT.I1850CNPRDCTCBC.pm-cpu_gnu.elm-snowveg_arctic.C.20240912_133219_khssny/bld

The new test's ELM_CONFIG_OPTS are:

pschwar3@login35: ERS.ELM_USRDAT.I1850CNPRDCTCBC.pm-cpu_gnu.elm-snowveg_arctic.C.20240912_133219_khssny $
 --> ./xmlquery ELM_CONFIG_OPTS
        ELM_CONFIG_OPTS: -phys elm -phys elm -cppdefs -DMODAL_AER

But the DIFF'ing tests originally had:

pschwar3@login16: SMS_Ly2_P1x1.1x1_smallvilleIA.IELMCNCROP.pm-cpu_gnu.elm-fan.C.20240912_133219_khssny $
 --> ./xmlquery ELM_CONFIG_OPTS
        ELM_CONFIG_OPTS: -phys elm

I looked at the tests within the e3sm_land_exeshare and those tests all have modal aerosols enabled. So moving the test there should solve the issue.

pschwar3@login35: ERS.r05_r05.ICNPRDCTCBC.pm-cpu_gnu.elm-cbudget.C.20240912_133219_khssny $
 --> ./xmlquery ELM_CONFIG_OPTS
        ELM_CONFIG_OPTS: -phys elm -phys elm -cppdefs -DMODAL_AER

@peterdschwartz
Copy link
Contributor

@thorntonpe pushed a commit moving the tests to a different suite, which should solve testing related issues for this branch.

@rljacob
Copy link
Member

rljacob commented Sep 16, 2024

The discussion above is confusing me especially this part "When run as a part of the test suite, the EXEROOT for a DIFF'ing test will be set to the new test".

@peterdschwartz
Copy link
Contributor

@rljacob In this case, for pm-cpu_gnu, the EXEROOT for e3sm_land_developer tests was being set to the test introduced by this PR (new test: ERS.ELM_USRDAT.I1850CNPRDCTCBC.elm-snowveg_arctic), but that test uses a compset that has different CPPDEFS than the other tests. So the other tests will DIFF.

The EXEROOT seems to be set (or influenced) depending on machine/compiler name so if the EXEROOT is set to a pre-existing test, the tests (except the new test) will share an executable built with the correct CPPDEFs. That's why testing with this PR and the previous related land PR would give diffs on certain machine/compiler configs but not on others.

@thorntonpe
Copy link
Contributor Author

@peterdschwartz do you have an estimate for when this will be merged to next? I'm giving an update to the NGEE Arctic team later today

@rljacob
Copy link
Member

rljacob commented Sep 17, 2024

We are prioritizing PRs for the v3.0.1 tag this week. This could go in next week.

@thorntonpe
Copy link
Contributor Author

@peterdschwartz and @bishtgautam I'd like to get this integrated in advance of the 3.1beta bug fixes. Can we move it to the top of the list?

@peterdschwartz
Copy link
Contributor

Sure, I don't see why we couldn't.

Note: The PR is still marked BFB, but it may be possible any tests diffs that were blessed from the arctic vegetation test may DIFF as result of this PR moving that test to the correct test suite.

@thorntonpe
Copy link
Contributor Author

@peterdschwartz Thanks, and understood on the movement of tests in the test suite. We'll be watching for those.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BFB PR leaves answers BFB Land
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants