<html><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">

</head><body bgcolor="#FFFFFF" text="#000000">For those not on 
cesm2control:<br>
<br>
-------- Original Message --------
<table class="moz-email-headers-table" border="0" cellpadding="0" 
cellspacing="0">
<tbody><tr><th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject: </th><td>Re:
 non-bfb 289 to 291</td></tr><tr><th align="RIGHT" nowrap="nowrap" 
valign="BASELINE">Date: </th><td>Mon, 09 Apr 2018 22:02:51 -0600</td></tr><tr><th
 align="RIGHT" nowrap="nowrap" valign="BASELINE">From: </th><td>Bill 
Sacks <a class="moz-txt-link-rfc2396E" href="mailto:sacks@ucar.edu"><sacks@ucar.edu></a></td></tr><tr><th align="RIGHT" 
nowrap="nowrap" valign="BASELINE">To: </th><td>Jim Edwards 
<a class="moz-txt-link-rfc2396E" href="mailto:jedwards@ucar.edu"><jedwards@ucar.edu></a></td></tr><tr><th align="RIGHT" nowrap="nowrap"
 valign="BASELINE">CC: </th><td>cesm2control 
<a class="moz-txt-link-rfc2396E" href="mailto:cesm2control@cgd.ucar.edu"><cesm2control@cgd.ucar.edu></a></td></tr></tbody>
</table>

<br>
<br>

<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">

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.<br>

<br>

I have some good news and some bad news. I'm bringing cesm2control into 
the loop for the bad news. <span style="font-weight: bold;">For the 
executive summary, just read the parts in bold.</span><br>

<br>

<span style="font-weight: 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).</span><br>

<br>

I'll start with the impact, and then describe the problem in more 
detail.<br>

<br>

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.<br>

<br>

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:<br>

<br>

<span style="font-family: monospace;">In [13]: 
summarize(pct291[0,3,:,:][w]-pct289[0,3,:,:][w])</span><br 
style="font-family: monospace;">

<span style="font-family: monospace;">count    302.000000</span><br 
style="font-family: monospace;">

<span style="font-family: monospace;">mean     -10.491008</span><br 
style="font-family: monospace;">

<span style="font-family: monospace;">std       13.153102</span><br 
style="font-family: monospace;">

<span style="font-family: monospace;">min      -48.280025</span><br 
style="font-family: monospace;">

<span style="font-family: monospace;">25%      -18.350363</span><br 
style="font-family: monospace;">

<span style="font-family: monospace;">50%       -7.774761</span><br 
style="font-family: monospace;">

<span style="font-family: monospace;">75%       -1.507887</span><br 
style="font-family: monospace;">

<span style="font-family: monospace;">max       30.457689</span><br 
style="font-family: monospace;">

<br>

<span style="font-weight: bold;">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.</span> <span style="font-weight: 
bold;">There are also diffs in mean glacier elevation in these and 
probably other grid cells in Greenland (not shown).</span><br>

<br>

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.<br>

<br>

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: <span style="font-weight: bold;">The CISM restart file we've been
 using was 2 years into a software test with an <span style="font-style:
 italic;">evolving</span> ice sheet. </span>(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.<br>

<br>

<span style="font-weight: bold;">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.</span><br>

<br>

<span style="font-weight: bold;">I guess this will have to be the first 
test case for the question, "Will we allow this answer-changing bug 
fix?". </span>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. <span style="font-weight: bold;">So my 
preference is to allow this answer change, but I recognize that this 
needs higher-level sign-off.</span><br>

<br>

Bill<br>

<br>



</body></html>