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

C-based harvest in ELM-FATES #5106

Closed
wants to merge 33 commits into from

Conversation

sshu88
Copy link

@sshu88 sshu88 commented Aug 2, 2022

This pull request contains modification in E3SM corresponding to another FATES PR #888.
In detail, necessary input to enable FATES C-based harvest from ELM is passed to FATES through bc_in. Output from FATES used to calculate land use emission and net biosphere productivity is passed to ELM through bc_out.

@sshu88 sshu88 changed the title C-based harvest in ELM-FATES [WIP] C-based harvest in ELM-FATES Aug 2, 2022
@rljacob rljacob added the Land label Aug 3, 2022
@rljacob
Copy link
Member

rljacob commented Aug 3, 2022

The PR description should describe the code changes and not just point to another PR description.

@rljacob
Copy link
Member

rljacob commented Aug 25, 2022

Needs action and review from @sshu88 @rgknox @bishtgautam

@rljacob
Copy link
Member

rljacob commented Sep 15, 2022

Still needs action and review from @sshu88 @rgknox @bishtgautam

@rljacob
Copy link
Member

rljacob commented Oct 6, 2022

telecon notes: Waiting for a FATES update before removing WIP.

!if ( (errsol(p) /= spval) .and. (abs(errsol(p)) > 1.e-7_r8) ) then
! solar radiation balance error is high when running FATES
! adjust the threshold to 5.e-7
if ( (errsol(p) /= spval) .and. (abs(errsol(p)) > 5.e-7_r8) ) then
Copy link
Contributor

Choose a reason for hiding this comment

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

@sshu88 is this change to try and avoid the water balance error? @rgknox and I recommend that we not change this in e3sm master branch. It should be reverted to the old value.

!if ( (errsol(p) /= spval) .and. (abs(errsol(p)) > 1.e-7_r8) ) then
! solar radiation balance error is high when running FATES
! adjust the threshold to 5.e-7
if ( (errsol(p) /= spval) .and. (abs(errsol(p)) > 5.e-7_r8) ) then
Copy link
Contributor

Choose a reason for hiding this comment

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

If we bump this value up to suppress warnings, that seems fine for a FATES run. We are very aware that an audit needs to be done to reduce these fine errors in radiation scattering. However, we may want to only apply it to a fates governed patch. This "is_fates" can tell us if we are on a fates patch and if we should apply different logic:
https://github.com/E3SM-Project/E3SM/blob/v2.0.0/components/elm/src/data_types/VegetationType.F90#L70

Copy link
Author

Choose a reason for hiding this comment

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

I have revised the code as suggested. Thank you @rgknox @glemieux .

@rljacob
Copy link
Member

rljacob commented Nov 3, 2022

telecon notes: still waiting for FATES PR.

@rljacob
Copy link
Member

rljacob commented Nov 9, 2022

@rgknox this is waiting on a FATES PR and then I guess an update of FATES to E3SM.

@sshu88
Copy link
Author

sshu88 commented Jan 4, 2023

@bishtgautam We can go ahead and merge the work once the FATES part is merged.

@glemieux
Copy link
Contributor

glemieux commented Jan 4, 2023

@bishtgautam We can go ahead and merge the work once the FATES part is merged.

@bishtgautam I'm working on the final deconflict and test on the fates-side right now.

@rgknox
Copy link
Contributor

rgknox commented Jan 6, 2023

The changes just merged into this branch, in 13d0f5a , were originally overlooked, but nonetheless required for compatibility with fates API 25.

Copy link
Contributor

@glemieux glemieux left a comment

Choose a reason for hiding this comment

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

One question about the hardcoded allow_harvest_bypass_criteria

end if

call set_fates_ctrlparms('use_lu_harvest',ival=pass_lu_harvest)
call set_fates_ctrlparms('use_harvest_bypass_criteria',ival=pass_harvest_bypass_criteria)
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't see any setup for this on the fates side pr 888. Is this a future feature? I'm assuming so given that it's hard coded to false just above this.

Copy link
Author

Choose a reason for hiding this comment

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

It's an old flag. I forgot to delete this line in ELM side.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, cool. In that case would you push an update to remove it please?

Comment on lines 158 to 160
use dynHarvestMod , only : num_harvest_vars, harvest_varnames
use dynHarvestMod , only : num_harvest_vars, harvest_varnames, wood_harvest_units
use dynHarvestMod , only : harvest_rates ! these are dynamic in space and time
use dynHarvestMod , only : num_harvest_vars, harvest_varnames, wood_harvest_units
Copy link
Contributor

Choose a reason for hiding this comment

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

@sshu88 it looks like there is some duplicate code here as well.

Copy link
Author

Choose a reason for hiding this comment

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

Thanks for checking.

Copy link
Contributor

@glemieux glemieux left a comment

Choose a reason for hiding this comment

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

Just one more minor piece of code cleanup.

@glemieux
Copy link
Contributor

@sshu88 would you remove the "[WIP]" from the title now?

@sshu88 sshu88 changed the title [WIP] C-based harvest in ELM-FATES C-based harvest in ELM-FATES Jan 18, 2023
@glemieux
Copy link
Contributor

@bishtgautam we still need to update the pointer to the fates side, but the associated PR hasn't been merged yet. I'll give you a heads up when that happens

@bishtgautam
Copy link
Contributor

Are the existing tests cover the new physics? Or, should we add a new test?

@glemieux
Copy link
Contributor

glemieux commented Jan 24, 2023

Are the existing tests cover the new physics? Or, should we add a new test?

We should add new tests, but I would like to defer that to a future PR in which we review and update all of the fates tests for the land developer suite.

Copy link
Contributor

@glemieux glemieux left a comment

Choose a reason for hiding this comment

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

I noticed one change that affects non-fates runs that needs to be addressed.

Comment on lines +2093 to +2102
this%prod10c(begc:endc) = spval
call hist_addfld1d (fname='PROD10C', units='gC/m^2', &
avgflag='A', long_name='10-yr wood product C', &
ptr_col=this%prod10c, default='inactive')

this%prod100c(begc:endc) = spval
call hist_addfld1d (fname='PROD100C', units='gC/m^2', &
avgflag='A', long_name='100-yr wood product C', &
ptr_col=this%prod100c, default='inactive')

Copy link
Contributor

Choose a reason for hiding this comment

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

@sshu88 was this a temporary change to make sure that you could read the prod10c and prod100c for when fates was running?

Copy link
Author

Choose a reason for hiding this comment

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

These are two outputs I added to the history output file for checking the change of product pool size. So it is a temporary change. But the product pool size shall be a basic output in land surface model when considering anthropogenic disturbances.

Copy link
Contributor

Choose a reason for hiding this comment

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

To clarify, does this need to be available when fates is running? The current issue is that the same call is made just below behind a .not. use_fates check, which means this will get called twice and cause a build failure for non-fates runs. If it's not necessary for fates right now, would you mind removing these lines? Otherwise, the part that is behind the .not. use_fates check could be removed.

Copy link
Author

Choose a reason for hiding this comment

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

I have removed the part below .not. use_fates check.

@glemieux
Copy link
Contributor

I'm running the land-developer tests and seeing two unexpected failures. I haven't looked into them much yet, but one is a fates smoke test failing during runtime in PhosphorusDynamicsMod and the other is a model build failure for ERS.ne30pg2_r05_EC30to60E2r2.GPMPAS-JRA.cori-haswell_intel.mosart-rof_ocn_2way.

folder location (Cori):

/global/homes/g/glemieux/cori-scratch/e3sm-tests/pr5106-merge.fates.cori-haswell.intel.Ce0716a090f-F25047167

Note I'm using Cori as perlmutter is down right now.

@rgknox
Copy link
Contributor

rgknox commented Jan 31, 2023

I submitted some updates to @sshu88 's branch to resolve the issues with the fates_eca test. Tests were passing on Cori. Should update once we get it approved and checked.

@glemieux
Copy link
Contributor

@sshu88 I created a PR to your branch to update the fates pointer now that NGEET/fates#888 is integrated on the fates-side.

@bishtgautam I ran land developer tests on Cori and all the tests except ERS.ne30pg2_r05_EC30to60E2r2.GPMPAS-JRA.gcp12_gnu.mosart-rof_ocn_2way passed (due to #5412).

Update fates submodule pointer to carbon harvest compatible tag
@glemieux
Copy link
Contributor

glemieux commented Feb 2, 2023

@bishtgautam this can be closed per #5429.

@bishtgautam bishtgautam closed this Feb 2, 2023
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.

7 participants