Enabling carbon isotopes changes answers for transient cases #675
Comments
ekluzek
added
type: bug - impacts science
priority: high
|
Note, that we don't see this in every case. The first month for BHIST, B1850, BW1850, BWHIST with and without cmip6 are identical (and cmip6 turns on c13 and c14 as well as both of the c13/c14 time-series files). So the cases that start at 1850, and have spunup Carbon isotopes from REFCASE files, all work as expected with identical answers (for at least the first month). |
|
Here's the list of fields different for the case when c14 is turned on rather than c13 (again after 1 time step). |
|
The fields that are ignored are for C14 (and a similar list for C13): Could not find match for file1 variable C14_AR in file2 |
|
The difference between the C13 and C14 case is limited to two fields (after 20 time-steps). RMS time_bounds 1.3258E-01 NORMALIZED 8.7779E-01 |
|
Strangely the case with BOTH c13 and c14 on is different from all the previous cases: no-ciso, c13 (by 117 fields), and c14 (by 157 fields). That's just at the first time-step. |
|
Turning on c13 timeseries, and comparing to c13 alone, gives answer changes, but it looks like it may largely be roundoff. 248 fields differ after 36000 seconds (20 time-steps), but the RMS difference is between E-11 and E-30, with the median around E-19, only 16 greater than E-14. |
|
subroutine Passing |
|
Ohh, nice, thanks for finding that @klindsay28! I think you are right, this looks wrong. It looks to me that the code should be... diff --git a/src/biogeochem/CNVegetationFacade.F90 b/src/biogeochem/CNVegetationFacade.F90
index 859d92b..b3b900d 100644
--- a/src/biogeochem/CNVegetationFacade.F90
+++ b/src/biogeochem/CNVegetationFacade.F90
@@ -703,12 +703,12 @@ subroutine DynamicAreaConservation(this, bounds, clump_index, &
if (use_c13) then
call CStateUpdateDynPatch(bounds, num_soilc_with_inactive, filter_soilc_with_inactive, &
this%c13_cnveg_carbonflux_inst, this%c13_cnveg_carbonstate_inst, &
- soilbiogeochem_carbonstate_inst)
+ c13_soilbiogeochem_carbonstate_inst)
end if
if (use_c14) then
call CStateUpdateDynPatch(bounds, num_soilc_with_inactive, filter_soilc_with_inactive, &
this%c14_cnveg_carbonflux_inst, this%c14_cnveg_carbonstate_inst, &
- soilbiogeochem_carbonstate_inst)
+ c14_soilbiogeochem_carbonstate_inst)
end if
call NStateUpdateDynPatch(bounds, num_soilc_with_inactive, filter_soilc_with_inactive, &
this%cnveg_nitrogenflux_inst, this%cnveg_nitrogenstate_inst, |
|
Yes, good find indeed @klindsay28 ! Mea culpa! I agree with the fix. @bishtgautam you may want to check whether the same bug exists in ELM. |
|
@billsacks Thanks for pointing this out |
|
I've tested those changes in 2 5-day long coupled ssp585 experiments, with and without carbon isotopes. CLM output, written every timestep, in these experiments is identical, and agrees with output from a non-isotope experiment done without the changes. |
|
Seems like there could be consequences in longer runs for the stable C,
which is unfortunate. I'm not sure we can properly anticipate what the
impacts would be without a long test. But ... either way this is a bug
that needs to be fixed.
…On Wed, Apr 17, 2019 at 2:25 PM Keith Lindsay ***@***.***> wrote:
I've tested those changes in 2 5-day long coupled ssp585 experiments, with
and without carbon isotopes. CLM output, written every timestep, in these
experiments is identical, and agrees with output from a non-isotope
experiment done without the changes.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#675 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFABYVD5QHTPN4WY5654X23PQ6BT3ANCNFSM4HD7SCRQ>
.
|
…ified when only isotopic soil carbon should have
|
I have a branch on my fork "cisofix" with the fix put into place. |
|
(Maybe this is already apparent to everyone following this issue, but in case not....) I believe the impact of this bug is the following: When there are changes in patch areas (in the first timestep of each year in a run with transient vegetation), what's supposed to happen is: The bulk soil C pools get an addition of C equal to (some fraction of?) the bulk C in roots, and similarly for the C isotopes. What was actually happening was that the root C isotope pools were being added to the bulk soil C pools rather than the isotope soil C pools in this case. So my guess is that the impact on bulk C is relatively small (assuming that isotope ratios are relatively small) - though I can't judge whether this might still impact long-term soil C significantly. But the impact on the isotopic concentrations would probably be larger. |
billsacks
changed the title
|
Diagnostics from a run with the bug fix compared to control run are here: [http://webext.cgd.ucar.edu/I20TR/clm50_release-clm5.0.20_1deg_GSWP3V1_isofix2_hist/lnd/clm50_release-clm5.0.20_1deg_GSWP3V1_isofix2_hist.1995_2014-clm50_release-clm5.0.20_1deg_GSWP3V1_isofix_hist.1995_2014/setsIndex.html] Main message is that bulk carbon is essentially not affected, fortunately. Significant impacts on 13C and 14C SOM, litter C, and HR are seen that effectively invalidate that data in regions where there has been land use change. |
Brief summary of bug
Turning on C13 or C14 shouldn't change answers, and yet it does in certain cases.
General bug information
CTSM version you are using: release-clm5.0.20
Does this bug cause significantly incorrect results in the model's science? Maybe?
Configurations affected: C13 or C14 turned on
Details of bug
Adding use_c13=T or use_c14=T, to the SSPRCP126 compset
Important details of your setup / configuration so we can reproduce the bug
Saw this at first in the BSSP126 compset versus BSSP126cmip6. Can also see it in I compset cases.
My test case is: SMS_Ln20.f09_g17_gl4.ISSP126Clm50BgcCrop.cheyenne_intel.clm-crop
Where I've added the following:
Set the hist_nhtfrq=1 and use_c13 = T
I know this is also a problem with use_c14=T. And the c13/c14 timeseries file might effect answers as well.
Important output or errors that show the problem
All fields are identical at step 00000, but at 01800 they start to diverge:
The text was updated successfully, but these errors were encountered: