[Liwg-core] Fwd: Re: non-bfb 289 to 291

Bill Sacks sacks at ucar.edu
Wed Apr 11 07:44:57 MDT 2018

Okay, thanks for these thoughts!

On 4/11/18, 7:37 AM, Laura Muntjewerf - CITG wrote:
> Hi Bill,
> Good catch, and thanks for the detailed information.
> So we can expect differences in SMB fields. Based on the input fields 
> you pointed to, I am expecting some difference in the integrated SMB. 
> However, I am more curious to see to what degree this makes spatial 
> differences. I agree with you that it is a good idea to make a 
> comparison.
> From a quick look on how the snow developed in 289, the snow pack over 
> the northern tundra takes ~20 years to equilibrate.
> I’d say run 50 years, that provides 30 years to look at the SMB climate.
> Definitely next week I have time to look at the output, I am curious 
> to see the implications.
> Laura
>> On 11 Apr 2018, at 13:38, Bill Sacks <sacks at ucar.edu 
>> <mailto:sacks at ucar.edu>> wrote:
>> Good news: It turns out that my concern about large water and energy 
>> fluxes in the first year was unfounded. i.e., this was wrong:
>>> Incidentally: this problem with CISM initial conditions means that 
>>> (I think) we also would have seen big, fictitious water and energy 
>>> fluxes from Greenland in the first year of any simulation done since 
>>> June which pointed to a land initial conditions file taken directly 
>>> from an offline spinup. I'm not sure how many of the runs over the 
>>> last year were set up in this way (as opposed to using a land file 
>>> from a hybrid case, which would be consistent with the buggy CISM).
>> It turns out that the fluxes are all generated in time step -1 – a 
>> time step that CLM does before the real start of the simulation, and 
>> fluxes generated in that time step apparently do not feed back to the 
>> rest of the system.
>> So it seems that the only issue is the different glacier cover around 
>> the margin of the Greenland ice sheet (and slightly different glacier 
>> elevations).
>> Bill
>> On 4/10/18, 12:40 PM, Bill Sacks wrote:
>>> Hi all,
>>> We discussed this issue at the co-chairs meeting today. I'm pasting 
>>> in notes about that and other notes from today's co-chairs meeting, 
>>> below.
>>> Cecile is starting a run to look at the impact of using incorrect 
>>> glacier cover in all runs since last June. This will probably be run 
>>> #293, which will be #289 + fixed glacier cover over Greenland. To 
>>> the extent that there are diffs, those diffs will probably show up 
>>> most over Greenland, including possibly affecting SMB diagnostics. 
>>> Would anyone have the time to do a comparison of #293 vs. #289 (once 
>>> #293 has run far enough) to see if there are significant diffs? How 
>>> long would Cecile need to run #293 for you to do diagnostics on it?
>>> Thanks,
>>> Bill S
>>> *April 10, 2018 *
>>> *
>>> *
>>> *Problematic issue found from non-bfb analysis, comparing #289 and #291*
>>> *
>>> *
>>> One big thing Bill S was concerned about was runs since June, 2017 
>>> that used buggy CISM init with CLM finidat from offline spinup. 
>>> These runs would have had big fluxes in the first year. But, 
>>> fortunately, it turns out that there weren't very many runs that 
>>> were configured that way.
>>> The other issue here is incorrect glacier cover over Greenland. This 
>>> probably doesn't have too large of an effect on global climate, but 
>>> concern is that any change could affect the Lab Sea.
>>> One concern is that this will affect the SMB analyses that have been 
>>> done by the LIWG over the last year.
>>> Next step: start a new run with the new code base with a CLM initial 
>>> file from 2 timesteps into #291, to look at diffs due to glacier 
>>> cover over Greenland. But actually, we might fold WACCM forcing 
>>> updates into this new run, too, so that the new run has everything 
>>> we want and can be used in the spinup process.
>>> ----
>>> *Run #290*
>>> Background on what motivated this: WACCM put in a check that aborts 
>>> if co2 goes above 720, because that goes past the end of a lookup 
>>> table. The point of this abort was to warn users not to try to do 
>>> (e.g.) a 4x CO2 run with this configuration. But the check was 
>>> triggered even for preindustrial, leading to the discovery of a 
>>> problem with diffusion.
>>> These same numeric issues affect anything being transported – 
>>> including H2O and aerosols.
>>> Run #290 has a fix to diffusion which has been confirmed to fix this 
>>> issue.
>>> Note that Lab Sea is warmer in this run, which could be a good 
>>> thing. In addition, ocean temperature and salinity look better over 
>>> Lab Sea.
>>> Feeling is that this looks promising... will look further into 
>>> whether to use this change moving forward.
>>> ----
>>> *Release planning*
>>> *
>>> *
>>> For fully-coupled compsets: The two scientifically-supported 
>>> compsets will be a preindustrial (which is a cmip6 preindustrial) 
>>> and historical compset – but this historical will NOT be a cmip6 
>>> historical. There will be other compsets that are functionally but 
>>> not scientifically supported.
>>> The CESM2.0.0 release won't be a "cmip6" release, but the plan is 
>>> for it to support cmip6 pre-industrial. A follow-up release (e.g., 
>>> CESM2.0.1) will add support for cmip6 historical & future scenarios.
>>> JF (ecohed by Dave L): Feels that priority should be supporting the 
>>> fully-coupled. Shouldn't spend a lot of time on standalone compsets 
>>> if this detracts from having the fully-coupled release done in time.
>>> What is the timeline for having the final values of tuning 
>>> parameters in place? It's possible that these tuning parameters 
>>> won't all be finalized even by the June workshop, but sense is that 
>>> we really want to have a release by the June workshop.
>>> One feeling from a number of people is that we shouldn't try to have 
>>> /any/ cmip6 science support, even for preindustrial, in the 
>>> CESM2.0.0 release. We would still provide scientific support for 
>>> preindustrial and historical in CESM2.0.0, but they wouldn't be 
>>> called cmip6.
>>> The differences for preindustrial in the cmip6 release update may 
>>> just be ocean BGC parameters. There are also some WACCM forcing 
>>> changes in the pipeline, but those should be ready by May 11.
>>> ----
>>> *Next meeting: Friday*
>>> *
>>> *
>>> *Please look at run #290 for that.*
>>> On 4/9/18, 10:09 PM, Bill Sacks wrote:
>>>> For those not on cesm2control:
>>>> -------- Original Message --------
>>>> Subject: 	Re: non-bfb 289 to 291
>>>> Date: 	Mon, 09 Apr 2018 22:02:51 -0600
>>>> From: 	Bill Sacks <sacks at ucar.edu>
>>>> To: 	Jim Edwards <jedwards at ucar.edu>
>>>> CC: 	cesm2control <cesm2control at cgd.ucar.edu>
>>>> Jim: Again, thank you very much for tracking down the diffs between 
>>>> 289 and 291, and for tracking them back to fields sent from CISM.
>>>> I have some good news and some bad news. I'm bringing cesm2control 
>>>> into the loop for the bad news. For the executive summary, just 
>>>> read the parts in bold.
>>>> One piece of good news is that I think I understand the (or at 
>>>> least a) source of the 289-291 diffs. Another piece of good news is 
>>>> that these particular diffs are limited to Greenland. The bad news 
>>>> is that the changes here are non-negligible over Greenland, and 
>>>> indicate that all of the runs done since about last June have used 
>>>> somewhat wrong glacier cover over Greenland; run 291 finally fixed 
>>>> this (unknowingly).
>>>> I'll start with the impact, and then describe the problem in more 
>>>> detail.
>>>> The impact can be seen by diffing a CLM h0 file between these two 
>>>> cases and looking at the fields PCT_LANDUNIT (% of each landunit on 
>>>> the gridcell) and PCT_GLC_MEC (% of each glacier elevation class) 
>>>> (both fields are constant in time, so it doesn't matter which file 
>>>> you choose). See 
>>>> /glade/scratch/sacks/cism_comparison/diff.291_289.clm2.h0.0001-01.nc. 
>>>> I am attaching images showing the difference in % glacier; they are 
>>>> the same data, just with different color bars.
>>>> As you can see from this figure, there are substantial differences 
>>>> in % glacier around the margin of the Greenland ice sheet. If we 
>>>> just consider the points with differences, here are statistics:
>>>> In [13]: summarize(pct291[0,3,:,:][w]-pct289[0,3,:,:][w])
>>>> count    302.000000
>>>> mean     -10.491008
>>>> std       13.153102
>>>> min      -48.280025
>>>> 25%      -18.350363
>>>> 50%       -7.774761
>>>> 75%       -1.507887
>>>> max       30.457689
>>>> That is, there are 302 grid cells over Greenland with differences 
>>>> in % glacier, and in those grid cells that differ, the percent of 
>>>> the grid cell covered by glacier is about 10% lower in 291 than in 
>>>> 289, on average. There are also diffs in mean glacier elevation in 
>>>> these and probably other grid cells in Greenland (not shown).
>>>> How did this difference come about? In all of these runs, the ice 
>>>> sheet model (CISM) is static in time, but it dictates CLM's 
>>>> (static) glacier cover over Greenland in initialization. CISM's 
>>>> glacier cover can be set either from a restart file or from 
>>>> observed initial conditions, and we've gone back and forth in terms 
>>>> of how we do this in the CESM2 test runs.
>>>> For all runs since about June, 2017, we've been doing a hybrid 
>>>> start with a refcase whose CISM restart file can be traced back to 
>>>> the refcase, 
>>>> /glade/p/cesmdata/cseg/inputdata/ccsm4_init/b.e20.B1850.f09_g17.pi_control.all.149.cism/0103-01-01/. 
>>>> I added a CISM restart file to that refcase to make it usable in 
>>>> configurations with CISM. Unfortunately, as I just discovered 
>>>> tonight, I did not give enough thought to the choice of CISM 
>>>> restart file used there: The CISM restart file we've been using was 
>>>> 2 years into a software test with an evolving ice sheet. (I should 
>>>> have used a restart file from a run with a non-evolving ice sheet; 
>>>> I'm not sure why I chose this one.) While ice sheets do not 
>>>> generally evolve much in 2 years, it is common for us to see a 
>>>> large jump in the first year of the simulation, and that's what is 
>>>> reflected here.
>>>> In the latest CISM version (cism2_1_50, in cesm2_0_alpha10b and 
>>>> later), I found a way to do what we've really wanted all along: 
>>>> forcing CISM to use observed initial conditions whenever it's 
>>>> running in no-evolve mode. This wouldn't have changed answers if 
>>>> the refcase were set up correctly, but since I put a bad restart 
>>>> file into the refcase we've been using, it resulted in the answer 
>>>> changes that we're seeing.
>>>> I guess this will have to be the first test case for the question, 
>>>> "Will we allow this answer-changing bug fix?". The refcase we've 
>>>> been using is definitely buggy in this respect. Furthermore, it is 
>>>> not directly usable in the new version of CISM (which was the 
>>>> motivation for making the behavior change in cism2_1_50). We could 
>>>> back out the change in cism2_1_50 and instead produce a patched-up 
>>>> refcase that gives bit-for-bit answers with #289 and works with the 
>>>> new version of the code. But in addition to carrying forward the 
>>>> bug, this path will cause problems for anyone doing hybrid runs off 
>>>> of other refcases. So my preference is to allow this answer change, 
>>>> but I recognize that this needs higher-level sign-off.
>>>> Bill
>> _______________________________________________
>> Liwg-core mailing list
>> Liwg-core at cgd.ucar.edu <mailto:Liwg-core at cgd.ucar.edu>
>> http://mailman.cgd.ucar.edu/mailman/listinfo/liwg-core

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/liwg-core/attachments/20180411/d92b52ae/attachment-0001.html>

More information about the Liwg-core mailing list