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

Fates Fixed Biogeography #632

Merged
merged 25 commits into from
Jun 5, 2020
Merged

Fates Fixed Biogeography #632

merged 25 commits into from
Jun 5, 2020

Conversation

rosiealice
Copy link
Contributor

@rosiealice rosiealice commented Apr 20, 2020

This PR updates the FATES side to implement the transfer of the PFT area fields into FATES, and prevents plants establishing outside of areas where they are not specified in the surface dataset. The PFTs still compete, hence this is Fixed Biogeography WITH competition

Description:

This corresponds to this item in the reduced complexity modes project. https://github.com/NGEET/fates/projects/5#card-36625297

THIS PR SHOULD BE ADOPTED AT THE SAME TIME AS THE CORRESPONDING FATES_API PR ESCOMP/CTSM#985

Collaborators:

@rgknox , @ckoven , @huitang-earth @glemieux @ekluzek

Expectation of Answer Changes:

This will change answers, because all PFTs cannot live everywhere
BUT only if the new use_fates_fixed_biogeog switch is turned ON
(thus might need an extra test...)
I didn't test answer changes for when it's off...

Checklist:

  • My change requires a change to the documentation.
  • I have updated the in-code documentation .AND. (the technical note .OR. the wiki) accordingly.
  • [ x] I have read the CONTRIBUTING document.
  • FATES PASS/FAIL regression tests were run
  • [x ] If answers were expected to change, evaluation was performed and provided
    Test run output on cheyenne here:
    /glade/scratch/rfisher/archive/clm5-spfates_test/lnd/hist
    running from

/glade/work/rfisher/git/ctsm_apr20/cime/scripts/clm5-spfates_test

Test Results:

CTSM (or) E3SM (specify which) test hash-tag: rosiealice/ctsm@ad2ecaa

CTSM (or) E3SM (specify which) baseline hash-tag: ESCOMP/CTSM@d525994

FATES baseline hash-tag: 2d98623

Test Output:

All expected PASS

/glade/u/home/glemieux/scratch/clmed-tests/PR632-CTSM985-premerge-finalcheck-Cad2ecaae-F0f2ea162.fates.cheyenne.intel
/glade/u/home/glemieux/scratch/clmed-tests/PR632-CTSM985-premerge-finalcheck-Cad2ecaae-F0f2ea162.fates.cheyenne.gnu

Copy link
Contributor

@ckoven ckoven left a comment

Choose a reason for hiding this comment

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

Looks good to me, thanks @rosiealice!

! Seed input from local sources (within site)
litt%seed_in_local(pft) = litt%seed_in_local(pft) + site_seed_rain(pft)/area

! Seed input from external sources (user param seed rain, or dispersal model)
seed_in_external = seed_stoich*EDPftvarcon_inst%seed_suppl(pft)*years_per_day

if(hlm_use_fixed_biogeog.eq.itrue)then
Copy link
Contributor

Choose a reason for hiding this comment

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

should this be: ?

Suggested change
if(hlm_use_fixed_biogeog.eq.itrue)then
if ( hlm_use_fixed_biogeog .eq. itrue .and. currentSite%use_this_pft(pft) .eq. ifalse ) then

Copy link
Contributor

Choose a reason for hiding this comment

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

yeah, I agree, @ckoven , it does look like that should have the PFT filter.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So, this is the part that breaks the carbon balance at restart. In particular, we aren't actually setting any of the use_this_pft or area_pfts after the model has restarted. Fixing this is the first thing on my to-do list after this set of changes. I think it's best to have both the variables on the restart file, to be consistant with how everything else about the site is set up, rather than recalculating them from the bc_in variable. Yes? No?

Copy link
Contributor

Choose a reason for hiding this comment

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

It sounds like, following a restart, this routine is being called before use_this_pft is getting filled from the bc_in structure. I think it would probably be a good idea to put the use_this_pft filter in the restart, as its memory overhead is small compared to our cohort variables.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

On which note, I'm following 'recrate' around as an example of a similarly-dimensioned variable to figure out how to put it in the restart file. I am confused about why it is registered as a cohort variable here...

call this%set_restart_var(vname='fates_recrate', vtype=cohort_r8, &

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Also, as a matter of general code development strategies, would you typically make a new branch to add such a thing to an open PR, or just push more commits to the same branch?

Copy link
Contributor

Choose a reason for hiding this comment

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

This is just my strategy, but 95% of the time I just push new commits to the same branch. Sometimes I will pack a set of changes into a new branch and use a PR to update the branch with the original pull request, but I only do that usually in two scenarios, 1) to make it clear to reviewers what I changed per their requests, and only if the changes are significant, or 2) if I plan to make a large set of complicated changes to the original feature branch, and want a quick and easy way to abort if I totally mess things up.


do ft = 1,numpft
if(currentSite%use_this_pft(ft).eq.1)then
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
if(currentSite%use_this_pft(ft).eq.1)then
if(currentSite%use_this_pft(ft).eq.itrue)then

end if

do ft = 1,numpft
sites(s)%use_this_pft(ft) = 1
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
sites(s)%use_this_pft(ft) = 1
sites(s)%use_this_pft(ft) = itrue

sites(s)%use_this_pft(ft) = 1
if(hlm_use_fixed_biogeog.eq.itrue)then
if(sites(s)%area_pft(ft).gt.0.0_r8)then
sites(s)%use_this_pft(ft) = 1
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
sites(s)%use_this_pft(ft) = 1
sites(s)%use_this_pft(ft) = itrue

if(sites(s)%area_pft(ft).gt.0.0_r8)then
sites(s)%use_this_pft(ft) = 1
else
sites(s)%use_this_pft(ft) = 0
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
sites(s)%use_this_pft(ft) = 0
sites(s)%use_this_pft(ft) = ifalse

@@ -464,7 +488,7 @@ subroutine init_cohorts( site_in, patch_in, bc_in)
patch_in%shortest => null()

do pft = 1,numpft

if(site_in%use_this_pft(pft).eq.1)then
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
if(site_in%use_this_pft(pft).eq.1)then
if(site_in%use_this_pft(pft).eq.itrue)then

@@ -216,10 +220,12 @@ subroutine zero_site( site_in )
! canopy spread
site_in%spread = 0._r8

site_in%area_pft(:) = 0._r8
site_in%use_this_pft(:) = fates_unset_int
Copy link
Contributor

Choose a reason for hiding this comment

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

This is great, I like initializing things to unset.
Also, area_pft looks like it could be unset also.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I used 'fates_unset_int' on the use_this_pft as it's an integer, but all the other real numbers above were set to 0._r8 so that seems to be the protocol there. Is there an unset for real numbers?

Copy link
Contributor

@rgknox rgknox Apr 24, 2020

Choose a reason for hiding this comment

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

yup, fates_unset_r8, defined after fates_unset_int, see here: https://github.com/NGEET/fates/blob/master/main/FatesConstantsMod.F90#L22

@rgknox
Copy link
Contributor

rgknox commented Apr 21, 2020

@rosiealice , I was curious about future plans for the site%area_pft array.
So far, it only looks like it is being used to determine if a pft is used or not used. In later versions we are going to be using this to create patches with specific fractional areas, or other uses right?

@rosiealice
Copy link
Contributor Author

rosiealice commented Apr 24, 2020

@rgknox on your query bout area_pft, yes, indeed. When we start to use it for the no competition FBG mode, it'll have more of a role to play.. And also for SP mode.

@rosiealice
Copy link
Contributor Author

I think this might be good to go now. One the call last week we had talked about adding a test, and @rgknox mentioned that I should look at Jessie's PR for age-related mortality. #599 Having looked at that, I noticed that she had some sort of internal test

if (test_zero_mortality) then

but I couldn't find and reference to a software test of the use_cohort_age_tracking facility in the test suite, which was the kind of test I was worrying about (for the use_fixed_biogeog facility introduced here). Should I make the test suite test? If so, can someone point me to an example thereof). If not, I think this part is doneas far as I can tell.

@glemieux
Copy link
Contributor

glemieux commented May 5, 2020

@rosiealice I think the test that @rgknox was referencing may have been in @JessicaNeedham's concurrent CTSM pull request ESCOMP/CTSM#882. I think this is the relevant link: ESCOMP/CTSM@ae551ed.

@glemieux
Copy link
Contributor

glemieux commented Jun 5, 2020

Final regression test ran with comparison against fates-sci.1.35.4_api.11.0.0. All expected PASS:

/glade/u/home/glemieux/scratch/clmed-tests/PR632-CTSM985-premerge-finalcheck-Cad2ecaae-F0f2ea162.fates.cheyenne.intel
/glade/u/home/glemieux/scratch/clmed-tests/PR632-CTSM985-premerge-finalcheck-Cad2ecaae-F0f2ea162.fates.cheyenne.gnu

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants