sporadic large CO2 uptake causing coupled CLM_CO2_TYPE=prognostic run to abort #590
Comments
|
I can look at this when I get in today, @klindsay28. To my knowledge, this is something we haven't seen in offline simulations, but I guess we wouldn't have that abort flag when running with prescribed CO2? @ekluzek what was similar behavior the motivation for #427 in the first place? |
|
@olyson , @rosiealice Thanks Will, we should investigate as a high priority. Adding in Keith and Rosie to discussion to have a few more in the loop in case not following this issue. I agree with Will that we are not aware of this issue happening in offline runs, but we may not have caught it if it happens only very rarely ... though I would expect it to show up as a large NEE anomaly even at global or regional / annual level that we would see in standard timeseries in CLM diagnostics plots. I looked at CLM5 runs and didn't see any evidence either globally or regionally in an NEE or AR spike that was outside the norm. |
|
I've never seen anything like that either, and second what Dave said, we'd probably expect to see it... Very strange :/ |
|
For what it's worth, I also checked CLM standard diagnostics from a coupled
simulation (without prognostic CO2) and I didn't see any evidence of spikes
in annual NEE or AR.
http://webext.cgd.ucar.edu/I20TR/clm50_r270_1deg_GSWP3V1_iso_newpopd_hist/lnd/clm50_r270_1deg_GSWP3V1_iso_newpopd_hist.1995_2014-b.e21.BHIST.f09_g17.CMIP6-historical.001.1995_2014/set6/set6.html
…On Fri, Dec 7, 2018 at 7:18 AM Rosie Fisher ***@***.***> wrote:
I've never seen anything like that either, and second what Dave said, we'd
probably expect to see it... Very strange :/
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#590 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AUAcVDY_hpfY2k4kEd89mOOgcsGspCw2ks5u2nilgaJpZM4ZH0Ek>
.
|
|
(I'll be offline for most of today, I'm about to board a flight to AGU.) |
|
There are a few points in the code that might generate these negative AR fluxes I'm not sure what either of these fluxes comes from, but will try cloning @klindsay28 's case and writing these out to history files. |
|
If you run into issues with the cloning, I’d be happy to rerun my case with
additional output.
…On Fri, Dec 7, 2018 at 9:10 AM will wieder ***@***.***> wrote:
There are a few points in the code that might generate these negative AR
fluxes
https://github.com/ESCOMP/ctsm/blob/7755baf3f729ff9adb0e39088c02113bbc9ebb58/src/biogeochem/CNVegCarbonFluxType.F90#L4121
(when the crop model is on)
or
https://github.com/ESCOMP/ctsm/blob/7755baf3f729ff9adb0e39088c02113bbc9ebb58/src/biogeochem/CNVegCarbonFluxType.F90#L4129
(when fun is active).
I'm not sure what either of these fluxes comes from, but will try cloning
@klindsay28 <https://github.com/klindsay28> 's case and writing these out
to history files.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#590 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AO2Xu_qN_0bDYJNMluXzeA3vpujHkGI2ks5u2pMMgaJpZM4ZH0Ek>
.
|
|
@slevisconsulting and @danicalombardozzi, do you have any old memories of what is being done with xsmr fluxes in the crop model? I'll trace this through the code, but am curious how or why we're handling AR fluxes differently in the crop model? |
|
I don't have any old memories of this, but Bin Peng and Maoyi Huong have
both encountered problems with very negative NEE during crop harvest. Bin
implemented a fix previously that constrained the xsmrpool_to_atm>=0.
Maoyi's student tried to implement this fix in CLM5 but got carbon balance
errors. I haven't followed up with them (this came to my attention right
before travel and then fell off my radar), and I'm not sure whether they
have a working solution at this point.
Danica
…On Fri, Dec 7, 2018 at 9:19 AM will wieder ***@***.***> wrote:
@slevisconsulting <https://github.com/slevisconsulting> and
@danicalombardozzi <https://github.com/danicalombardozzi>, do you have
any old memories of what is being done with xsmr fluxes in the crop model?
I'll trace this through the code, but am curious how or why we're handling
AR fluxes differently in the crop model?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#590 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AY9tQZg_bjNQdM7oFBB7ADZLLcRyngr6ks5u2pT2gaJpZM4ZH0Ek>
.
--
Dr. Danica Lombardozzi
she/her/hers
Terrestrial Sciences Section
Climate and Global Dynamics
National Center for Atmospheric Research
Boulder, CO 80305
email: dll@ucar.edu
office: (303) 497-1777
|
|
@dlawrenncar , @danicalombardozzi mentioned that you'd had a previous discussion with Maoyi and Bin about a similar issue with negative xsmr fluxes associated with harvest. From @klindsay28 runs it looks like the strongly negative fluxes may be associated with harvest in agricultural regions? The attached image shows AR fluxes from Sept 28, just before the coupled model crashes. |
|
This feature is also evident in the offline CLM5 runs we've done and can likely be seen in the monthly .h0. history files where we have negative AR in some grids for particular months. This is June 1851 from Pete's recent simulation i.e21.IHIST.f09_g17.CMIP6-land-hist.001 |
|
I am not sure if this is the same thing I experienced with ELM, but I found the algorithm in carbon allocation could lead to negative litter fluxes in some circumstances. So I guess clm has the same problem given its similarities with ELM. I fixed in my ELM branch with the multiflux limiter I presented tow years ago at the land bgc meeting.
Jinyun
…Sent from my iPhone
On Dec 7, 2018, at 10:32 AM, will wieder ***@***.***> wrote:
This feature is also evident in the offline CLM5 runs we've done and can likely be seen in the monthly .h0. history files where we have negative AR in some grids for particular months. This is June 1851 from Pete's recent simulation i.e21.IHIST.f09_g17.CMIP6-land-hist.001
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
At harvest, any C in the xsmr pool will go to the atmosphere. |
|
It wouldn't fix the underlying issue, but would a quick fix be to apply something like the hrv_xsmrpool_to_atm_dribbler to smooth out how the atmosphere sees this negative C flux? @billsacks maybe you can commend on what the 'dribbler' is supposed to do? Alternatively, could we transfer the xsmr to litter pools, instead of the atmosphere? Neither of these are very satisfying fixes, so other ideas would be welcome |
|
Oner more thought on this, @ckoven maybe you have thoughts here? Would allowing a quicker recovery of the xsmrpool potentially alleviate these negative AR fluxes with harvest? this could be done by changing the daysrecover parameter (currently set to 30 days). The issue here, is we'll also be changing global C fluxes, by modifying the calculation of availc. @dlawrenncar , I'd guess this is a non-starter at this stage of the game? |
|
Neither of these solutions is likely to solve the massive flux, right?
That is something different, like a divide by a near zero value or
something somewhere.
On Dec 7, 2018, at 1:56 PM, will wieder <notifications@github.com> wrote:
It wouldn't fix the underlying issue, but would a quick fix be to apply
something like the hrv_xsmrpool_to_atm_dribbler to smooth out how the
atmosphere sees this negative C flux? @billsacks
<https://github.com/billsacks> maybe you can commend on what the 'dribbler'
is supposed to do?
https://github.com/ESCOMP/ctsm/blob/7755baf3f729ff9adb0e39088c02113bbc9ebb58/src/biogeochem/CNVegCarbonFluxType.F90#L745
Alternatively, could we transfer the xsmr to litter pools, instead of the
atmosphere?
hrv_deadcrootc_to_litter(p) = deadcrootc(p) * m
hrv_deadcrootc_to_litter(p) = hrv_deadcrootc_to_litter(p) + xsmrpool(p) * m
https://github.com/ESCOMP/ctsm/blob/7755baf3f729ff9adb0e39088c02113bbc9ebb58/src/biogeochem/dynHarvestMod.F90#L341
Neither of these are very satisfying fixes, so other ideas would be welcome
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#590 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AUAcVMPaTDvxVfieTiT_VcwZKJW90xfXks5u2rnegaJpZM4ZH0Ek>
.
|
|
@dlawrenncar & @danicalombardozzi I've gotten lost in the crop phenology code, but don't really understand why these fluxes are zeroed out in CNCStateUpdate1? I'd assume that this is the flux giving us a large negative AR flux? |
|
@klindsay28 can you rerun your high frequency output simulations with this block of code around line 1540 of CNVegCarbonFluxType.F90? I'd like to confirm that crop harvest is causing the negative AR fluxes and big drop in CO2 concentrations. ! -- WW added for #590 ! -- WW added |
|
Sure thing @wwieder. The run is now in progress. |
|
just got off a plane and saw this. nothing obvious comes to mind to me. |
|
Sorry for the delayed response, though I'm afraid I don't have suggestions at this time. |
|
@klindsay28 's runs confirm that the large negative flux is coming from xsmrpool_to_atm_patch, which occurs at harvest in a single time step. You can see a map here The magnitude of the negative flux is really big, compared to MR and GR fluxes, but could occur with XSMRPOOL ~ -20 gC/m2 (assuming 100% crop coverage over the gridcell). It seems this is the code responsible for the large instantaneous flux: @dlawrenncar and @klindsay28 I'm a little unsure of the code modifications that would be preferred here, or the timeframe we have to work with? One patch would be to dribbling this flux to the atmosphere, as with wood harvest. This would likely alleviate the large negative AR fluxes that are causing the prognostic CO2 runs to fail. Alternatively, the harvest xsmr flux could be passed to litter, instead of the atmosphere, but I'm unsure if this could generate negative litter pools in some cases and would certainly change answers. Neither patch addresses the underlying issue with large xsmr pools that are accumulating (esp. in crops). more of Keith's simulation can be found here if you're interested, which includes pft-level h1 files if we want to dive into the causes. |
|
@wwieder Recalling @klindsay28's statement at the beginning of thread. The atmospheric CO2 drops down to something like 4ppm. A huge, huge drop, right? Maybe I am not understanding something, but if we dribbled the negative AR flux out over a year, we would still see a massive drop in CO2. My guess is still that what is happening here in the crash is an extreme version with a crazy high negative AR flux that is not really similar to the more standardly poor negative AR fluxes around harvest that are occurring frequently. @wwieder do you agree? |
|
@dlawrenncar, I think dribbling has the potential to be effective. |
|
@klindsay28 Thanks Keith. Yes, after discussing with Will just now, we agree with you that the flux dribbler this has the potential to solve the issue. @olyson Can you attempt to implement the flux dribbler solution this week? Longer term, we need to resolve the accumulation/occurrence of negative XSMRPOOL. Jinyun has thoughts about that so we will follow up with him. |
|
That's a good point, about the shallow boundary layer. I was beginning to
think everything was perhaps broken/ suffering massive silent XSMR issues...
n.b. that in FATES I resolved this (large carbon deficits killing things
too much in marginal/seasonal/inter-annually varying places) by only
allowing some (parameterized) fraction of the C demand from tissue turnover
to be met, and allowing the remaining tissue to senesce, when NPP was
negative. Thus, the live pools decline and so do respiratory costs, so the
accumulation of carbon debt goes down. That means you get, say, seasonal
oscillations in LAI instead of seasonal oscillations in carbon
debt/storage/XSMR.
Obviously the carbon allocation model would need to look different in CLM5
to accomodate that, The only other options I can see are 1) declining
maintenance respiration as a function of XSMR (i thought we did that
already?) and 2) adding some sort of specifically enhanced tissue turnover
to mimic the mortality which would result in real life from running a huge
carbon deficit.
Le sam. 8 déc. 2018 à 15:06, David Lawrence <notifications@github.com> a
écrit :
… @klindsay28 <https://github.com/klindsay28> Thanks Keith. Yes, after
discussing with Will just now, we agree with you that the flux dribbler
this has the potential to solve the issue. @olyson
<https://github.com/olyson> Can you attempt to implement the flux
dribbler solution this week? Longer term, we need to resolve the
accumulation/occurrence of negative XSMRPOOL. Jinyun has thoughts about
that so we will follow up with him.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#590 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AMWsQzhWg424pGu2zMq8JoFZ4cZ1rz8Nks5u28dOgaJpZM4ZH0Ek>
.
--
------------------------------------------------------------
Dr Rosie A. Fisher
Staff Scientist
Terrestrial Sciences Section
Climate and Global Dynamics
National Center for Atmospheric Research
1850 Table Mesa Drive
Boulder, Colorado, 80305, USA
and
Visitor @ C.E.R.F.A.C.S
Centre Européen de Recherche et de Formation Avancée en Calcul Scientifique
42 Avenue Gaspard Coriolis 31057, Toulouse, France
http://www.cgd.ucar.edu/staff/rfisher/
|
|
The line of code pointed to by @wwieder in CNCStateUpdate1Mod.F90 is preceded with the block of comments below. It's not clear to me if the concerns mentioned in these comments are applicable to xsmrpool. If so, it might be prudent to keep on eye on isotopes when dribbling is enabled. (The coupled runs do have land C isotopes enabled.)
|
|
one more favor @klindsay28 can you repeat the high run one more time with XSMRPOOL added to the h1 and h2 files? I'd like to see how big some of the crop XSMRPOOLs get? |
|
I"m just going to point you to some code. A comparison of my branch with these changes compared to the latest clm release tag is here: release-clm5.0...olyson:hrv_xsmrpool_to_atm If it helps to look at the full modules, the code I used for an offline historical is here: /gpfs/fs1/work/oleson/release-clm5.0.15_hrv_xsmrpool_to_atm/src The sourcemods I used for my clone of Keith's case are here: /gpfs/fs1/work/oleson/cesm2_0_runs/b.e21.B1850_BPRP.f09_g17.CMIP6-piControl.tst.001/SourceMods/src.clm These mods differ from my branch in that I had to comment out the new restart variables since Keith's run was a branch. I'm going to run a pair of short land-only historical runs to check energy/water/flux changes as suggested by Will. |
|
As discussed I've added a gridcell average xsmrpool_to_atm flux to nbp. Seems to have reduced the differences in NBP by a couple of orders of magnitude. After: And the global average is nearly the same as the control now. After: |
|
I'll give it a try. |
|
Keith's case ran to completion for 1 month. |
|
seems like the fix is doing it's job. What do you think, Dave?
…On Wed, Dec 19, 2018 at 10:59 AM Keith Oleson ***@***.***> wrote:
Keith's case ran to completion for 1 month.
The lowest a2x_Sa_coprog timestep value I see for the last five days of
the month is 261.153 ppm.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#590 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AHqLJAxlPw3amZc1IRsWAeZNilw4njUAks5u6n5-gaJpZM4ZH0Ek>
.
--
Will Wieder
Project Scientist
CGD, NCAR
303-497-1352
|
|
Yep. I think we should pass this back over to Keith Lindsay so that he can
run a longer simulation. Pending the outcome of that simulation, we can
then make a decision about how to proceed in the context of CESM2 CMIP6
simulations.
On Wed, Dec 19, 2018 at 11:17 AM will wieder <notifications@github.com>
wrote:
… seems like the fix is doing it's job. What do you think, Dave?
On Wed, Dec 19, 2018 at 10:59 AM Keith Oleson ***@***.***>
wrote:
> Keith's case ran to completion for 1 month.
> The lowest a2x_Sa_coprog timestep value I see for the last five days of
> the month is 261.153 ppm.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#590 (comment)>, or
mute
> the thread
> <
https://github.com/notifications/unsubscribe-auth/AHqLJAxlPw3amZc1IRsWAeZNilw4njUAks5u6n5-gaJpZM4ZH0Ek
>
> .
>
--
Will Wieder
Project Scientist
CGD, NCAR
303-497-1352
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#590 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AUAcVCCEylNv9BrZOAqcg3DAgYipzR9nks5u6oLOgaJpZM4ZH0Ek>
.
|
|
Keith, I have source code for your simulation to try here: /gpfs/fs1/work/oleson/cesm2_0_runs/b.e21.B1850_BPRP.f09_g17.CMIP6-piControl.tst.001/SourceMods/src.clm Note that I added a few restart variables in CNVegCarbonStateType.F90. But I commented those lines out to run my clone of your simulation which was a branch. If you are not running a branch then you would need to uncomment those lines. They are marked/bracketed by "!KO". Keith |
|
Keith, |
|
The new case should be able to start from the above file even if you include the new restart variables. My offline historical case starts from an initial file that doesn't have those restart variables on it. So I would uncomment the lines in CNVegCarbonStateType.F90 and try it. |
|
From Keith Lindsay: The coupled model run with CLM mods to avoid the previous aborts is nearly out 40 years. Attached are some timeseries plots of globally averaged annual mean CO2 surface values and surface fluxes (+ up) (plots not attached here). It looks like the system might be stabilizing atm CO2, but with a steady transfer of C from lnd to ocn, via atm, at a rate of about 0.1 PgC/y. Could someone please run LMWG diags on this case, so that we can look for anything suspicious? CASE b.e21.B1850_BPRP.f09_g17.CMIP6-piControl.tst.002 The run is a hybrid off of b.e21.B1850.f09_g17.CMIP6-piControl.001 at 0501-01-01, so maybe it makes sense to compare years 1-30 of the new run to 501-531 of b.e21.B1850.f09_g17.CMIP6-piControl.001. |
|
The land diagnostics for the coupled runs are here: The diagnostics for the 20-year land-only historical run I did are here: |
|
My branch for this is here: https://github.com/olyson/ctsm/tree/hrv_xsmrpool_to_atm I have done very limited testing just to make sure restarts work. The following tests pass (or fail) as expected: ERP_Ld5.f09_g17.I1850Clm50BgcCropCru.cheyenne_intel.clm-ciso We'd like to have this activated via a namelist item, so that we can turn it off for runs either than scenario runs. I'm suggesting a software engineer do that if possible. I can either run the full test suite as is right now or perhaps we should wait until the namelist item is added. |
|
Followup, based on conversation with @dlawrenncar |
|
We decided the name of the namelist variable should be: dribble_crophrv_xsmrpool_2atm |
|
There's a hard-coded constant in the mods to fix this. This is a bad practice that we know we should try to stay away from. I just checked with @olyson and @wwieder to verify that they don't think it's likely that this parameter would be tuned, and the answer is that it's unlikely enough that leaving it hardcoded is probably OK. |
|
I made the constant kprod05 a parameter, and made sure all new history variables are default='inactive'. Making kprod05 double precision changes answers, so I'm leaving it as it is. Now working on making the namelist work correctly. |
|
Fix in release-clm5.0.16 |
billsacks
added
bug
|
This was brought to master in ctsm1.0.dev093. |
|
I'm reopening this issue, because it doesn't seem to be fixed. These results are from Keith Rodgers, generated by the CESM2 LES. The plot shows daily output from 3 ensemble members for one gridcell (45N, 100W). I'm not sure why we decided to just do this with prognostic CO2, @dlawrenncar and @klindsay28 do you recall? Was it to avoid changing answers for CESM2 simulations? Would it be appropriate to do this for all runs with active crops in CTSM5.1 @danicalombardozzi ?
|
|
Yes, I believe it was not activated for all runs because it was not a
bit-for-bit change. That's my recollection at least. I would think we
want to change this setting for all configurations in CESM2.2 onwards.
Whether or not to change for the remaining CESM2 LE runs is another story.
…On Thu, May 21, 2020 at 3:08 PM will wieder ***@***.***> wrote:
I'm reopening this issue, because it doesn't seem to be fixed.
These results are from Keith Rodgers, generated by the CESM2 LES. The plot
shows daily output from 3 ensemble members for one gridcell (45N, 100W).
[image: Screen Shot 2020-05-19 at 12 14 00 AM]
<https://user-images.githubusercontent.com/8031012/82604330-636e3c80-9b71-11ea-9aff-67f6c2c9cb3c.png>
Of note are the large blips in July-Aug that seem to occur with harvest,
see concurrent declines in grid cell LAI that are associated with large
negative AR fluxes. These make me think the xsmr bug fix isn't working.
[image: Screen Shot 2020-05-19 at 6 58 49 PM]
<https://user-images.githubusercontent.com/8031012/82605112-a250c200-9b72-11ea-8b7c-6229ebd03864.png>
[image: Screen Shot 2020-05-19 at 10 17 08 PM]
<https://user-images.githubusercontent.com/8031012/82605128-a977d000-9b72-11ea-8cd7-e334c17f9873.png>
@olyson <https://github.com/olyson> confirmed that this bug was fixed in
release-clm5.0.16 and the LE is using release-clm5.0.30, but that the fix
for that bug is triggered by when CLM_CO2_TYPE is prognostic and these runs
don't have prognostic CO2.
https://github.com/ESCOMP/CTSM/blob/8265b77455ab59d2e269bbb2e7a548c4d58806e0/bld/namelist_files/namelist_defaults_ctsm.xml#L496
I'm not sure why we decided to just do this with prognostic CO2,
@dlawrenncar <https://github.com/dlawrenncar> and @klindsay28
<https://github.com/klindsay28> do you recall? Was it to avoid changing
answers for CESM2 simulations? Would it be appropriate to do this for all
runs with active crops in CTSM5.1 @danicalombardozzi
<https://github.com/danicalombardozzi> ?
- Note, this won't solve the more persistent issue of XSMR, but it
would hopefully make analysis easier...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#590 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFABYVCE7ARYPEFGUEEXLHLRSWJ3VANCNFSM4GI7IESA>
.
|
|
I agree -- we should probably make this change for all new simulations. If
the change isn't bit-for-bit, I could see folks not wanting to include this
in CESM2-LENS. It will likely result in the same annual fluxes, though will
change daily and monthly fluxes.
On Thu, May 21, 2020 at 3:14 PM David Lawrence <notifications@github.com>
wrote:
… Yes, I believe it was not activated for all runs because it was not a
bit-for-bit change. That's my recollection at least. I would think we
want to change this setting for all configurations in CESM2.2 onwards.
Whether or not to change for the remaining CESM2 LE runs is another story.
On Thu, May 21, 2020 at 3:08 PM will wieder ***@***.***>
wrote:
> I'm reopening this issue, because it doesn't seem to be fixed.
>
> These results are from Keith Rodgers, generated by the CESM2 LES. The
plot
> shows daily output from 3 ensemble members for one gridcell (45N, 100W).
> [image: Screen Shot 2020-05-19 at 12 14 00 AM]
> <
https://user-images.githubusercontent.com/8031012/82604330-636e3c80-9b71-11ea-9aff-67f6c2c9cb3c.png
>
> Of note are the large blips in July-Aug that seem to occur with harvest,
> see concurrent declines in grid cell LAI that are associated with large
> negative AR fluxes. These make me think the xsmr bug fix isn't working.
> [image: Screen Shot 2020-05-19 at 6 58 49 PM]
> <
https://user-images.githubusercontent.com/8031012/82605112-a250c200-9b72-11ea-8b7c-6229ebd03864.png
>
> [image: Screen Shot 2020-05-19 at 10 17 08 PM]
> <
https://user-images.githubusercontent.com/8031012/82605128-a977d000-9b72-11ea-8cd7-e334c17f9873.png
>
> @olyson <https://github.com/olyson> confirmed that this bug was fixed in
> release-clm5.0.16 and the LE is using release-clm5.0.30, but that the fix
> for that bug is triggered by when CLM_CO2_TYPE is prognostic and these
runs
> don't have prognostic CO2.
>
>
https://github.com/ESCOMP/CTSM/blob/8265b77455ab59d2e269bbb2e7a548c4d58806e0/bld/namelist_files/namelist_defaults_ctsm.xml#L496
> I'm not sure why we decided to just do this with prognostic CO2,
> @dlawrenncar <https://github.com/dlawrenncar> and @klindsay28
> <https://github.com/klindsay28> do you recall? Was it to avoid changing
> answers for CESM2 simulations? Would it be appropriate to do this for all
> runs with active crops in CTSM5.1 @danicalombardozzi
> <https://github.com/danicalombardozzi> ?
>
> - Note, this won't solve the more persistent issue of XSMR, but it
> would hopefully make analysis easier...
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#590 (comment)>, or
> unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AFABYVCE7ARYPEFGUEEXLHLRSWJ3VANCNFSM4GI7IESA
>
> .
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#590 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGHW2QMKNNTGADV24K5N2NDRSWKSBANCNFSM4GI7IESA>
.
--
Dr. Danica Lombardozzi
she/her/hers
Terrestrial Sciences Section
Climate and Global Dynamics
National Center for Atmospheric Research
Boulder, CO 80305
email: dll@ucar.edu
office: (303) 497-1777
|
|
I don't think we want to change this for CESM2 LE runs, but maybe I'll tag this for CESM2.2. @ekluzek can this just be folded into another upcoming tag to master? |
|
We tried putting this into the LENS experiments and it showed significant change to answers and climate: Here's an example from Jim Edwards:
|
Details of support request
I'm doing a coupled model run using CLM_CO2_TYPE=prognostic with CESM2.
The run is aborting a few years in with the error message and stack traceback:
239: ENDRUN:
239: ERROR:
239: lnd_import ERROR: CO2 is outside of an expected range
239:Image PC Routine Line Source
239:cesm.exe 0000000003529B7D Unknown Unknown Unknown
239:cesm.exe 0000000002C9B7D2 shr_abort_mod_mp_ 114 shr_abort_mod.F90
239:cesm.exe 00000000019C9C3F abortutils_mp_end 50 abortutils.F90
239:cesm.exe 00000000019C6E46 lnd_import_export 251 lnd_import_export.F90
239:cesm.exe 00000000019BE266 lnd_comp_mct_mp_l 401 lnd_comp_mct.F90
239:cesm.exe 0000000000425BE4 component_mod_mp_ 728 component_mod.F90
...
The abort occurs at model date 0004-09-28.
To diagnose what is going on, I have rerun the month 0004-09 with nstep cpl hist and nstep clm hist on CMIP6 h0, h1, h2 files. This output is in $RUNDIR, mentioned below.
Examining the last few cpl.hi files, it looks like a2x_Sa_coprog at (i,j)=(9,143) (zero based indexing) drops from ~286 ppmv to 4.2 ppmv in a single timestep. This is below the 10 ppm threshold of #427 and abort is called.
It looks like this is being caused by a larger drawdown of CO2.
l2x_Fall_fco2_lnd is large and positive in the last cpl hist file.
Looking at clm2.h0 files, NEE at that same point is negative with a large magnitude.
There is a block of values around northern Italy with large magnitude negative NEE in the last clm2.h0 file.
The structure of the anomalous NEE values does not show up in GPP, but it does show up in NPP.
It shows up in AR as a large magnitude negative value, kinda a red flag.
Neither GR or MR show the anomalous values, so I'm inferring that the uptake is from one of the C terms thrown into AR to maintain C balance (e.g., XSMR related). I don't understand the nature of these terms.
Any suggestions on how to investigate this further?
The clm2 h1 and h2 files have sub-grid cell info, so hopefully that is helpful for deciphering what is going wrong.
If I look at animations of this nstep clm (or cpl) output, I see sporadic blips of very large CO2 uptake occurring at numerous grid points. I do not see an obvious pattern to the geographic distribution of the blips. They generally seem to appear for a single timestep. The blip at (i,j)=(9,143) happens to be enough of a CO2 drawdown to bring CO2 below the #427 10 ppmv threshold.
Important details of your setup / configuration so we can better assist you
release-clm5.0.14
**Have you made any modifications to code, xml files, etc.? no
compset=1850_CAM60_CLM50%BGC-CROP-CMIP6DECK_CICE%CMIP6_POP2%ECO%ABIO-DIC_MOSART_CISM2%NOEVOLVE_WW3_BGC%BPRP
aside from using BPRP, instead of BDRD, the compset is B1850
CASEROOT=/glade/work/klindsay/cesm20_cases/B1850/b.e21.B1850_BPRP.f09_g17.CMIP6-piControl.tst.001
(The run was originally a hybrid off of b.e21.B1850.f09_g17.CMIP6-piControl.001, with RUN_REFDATE=0501-01-01, RUN_STARTDATE=0001-01-01, and modified CAM CO2 constituents (to bring their surface means closer to the 1850 values. After encountering the abort, I reran the last month with higher frequency output, having the case branch off of itself at 0004-09-01.)
RUNDIR=/glade/scratch/klindsay/b.e21.B1850_BPRP.f09_g17.CMIP6-piControl.tst.001/run
The text was updated successfully, but these errors were encountered: