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 wood product flux not being correctly reported during CBalanceCheck endrun diagnostic output #2283

Closed
glemieux opened this issue Dec 6, 2023 · 1 comment · Fixed by #2076

Comments

@glemieux
Copy link
Collaborator

glemieux commented Dec 6, 2023

Brief summary of bug

The local variable fates_woodproduct_flux appears to default to zero in the diagnostic output prior to the endrun call associated with the write statements. It should report the results of the summation that it represents.

General bug information

CTSM version you are using: ctsm5.1.dev157

Does this bug cause significantly incorrect results in the model's science? No, this is diagnostic info for a failure condition

Details of bug

The fates_woodproduct_flux is a local variable that is calculated within the column loop inside CBalanceCheck:

fates_woodproduct_flux = clm_fates%fates(ic)%bc_out(s)%hrv_deadstemc_to_prod10c + &
clm_fates%fates(ic)%bc_out(s)%hrv_deadstemc_to_prod100c

Note that it is a summation of site-level fates bc_out variables, that are dependent on the site to column mapping. Later down the code, if the error threshold is met, the variable is used in the diagnostic write statements:

write(iulog,*)'fates wood product flux = ',fates_woodproduct_flux*dt

Since the code loops through all columns before reporting the error, there is no guarantee that the fates_woodproduct_flux will be the value corresponding to the failure case.

Important details of your setup / configuration so we can reproduce the bug

I found this while regression testing #2076 with use_fates_luh = .true. using fates commit ea24aa8 and ctsm commit e8b0508.

Important output or errors that show the problem

Error message in lnd.log:

3864  column cbalance error    =   1.537941879714219E-006           7
3865  is fates column?         =  T
3866  Latdeg,Londeg=   30.0000000000000        260.000000000000
3867  begcb                    =    911.965299656670
3868  endcb                    =    911.957395544391
3869  delta store              =  -7.904112279447872E-003
3870  --- Inputs ---
3871  fates litter_flux        =   0.000000000000000E+000
3872  fates wood product flux  =   0.000000000000000E+000
3873  --- Outputs ---
3874  hr                       =   7.904112279464640E-003
3875  -1*som_c_leached         =  -3.964367563847151E-014
3876 iam = 0: local  column   index = 7
3877 iam = 0: global column   index = 5224
3878 iam = 0: global landunit index = 1953
3879 iam = 0: global gridcell index = 865
3880 iam = 0: gridcell longitude    =  260.0000000
3881 iam = 0: gridcell latitude     =   30.0000000
3882 iam = 0: column   type         = 1
3883 iam = 0: landunit type         = 1
3884  ENDRUN:
3885  ERROR: ERROR in CNBalanceCheckMod.F90 at line 406

Adding statements to write out the wood product during the loop shows the following:

3850  column cbalance error    =   1.537941879714219E-006           7
3851  begcb                    =    911.965299656670
3852  endcb                    =    911.957395544391
3853  delta store              =  -7.904112279447872E-003
3854  fates litter_flux        =   0.000000000000000E+000
3855  fates bcout dstem prod10 =   6.942099017242012E-010
3856  fates bcout dstem prod100=   1.602022850132772E-010
3857  fates wood product flux  =   8.544121867374785E-010

@ekluzek ekluzek added the next this should get some attention in the next week or two. Normally each Thursday SE meeting. label Dec 6, 2023
@glemieux glemieux linked a pull request Dec 12, 2023 that will close this issue
@glemieux
Copy link
Collaborator Author

This will be taken care of via 1a1ec94 in #2076.

@samsrabin samsrabin removed the next this should get some attention in the next week or two. Normally each Thursday SE meeting. label Mar 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants