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

Bill Sacks sacks at ucar.edu
Mon Apr 9 22:09:02 MDT 2018


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/liwg-core/attachments/20180409/66d347cf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-04-09 at 8.50.56 PM.pdf
Type: application/pdf
Size: 772095 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/liwg-core/attachments/20180409/66d347cf/attachment-0002.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-04-09 at 8.59.28 PM.pdf
Type: application/pdf
Size: 697741 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/liwg-core/attachments/20180409/66d347cf/attachment-0003.pdf>


More information about the Liwg-core mailing list