Greenland and Antarctica SMB in CAM7

[adamrher]

Switching from FV1deg -> ne30pg3 degrades the SMB in Greenland. ne30pg3 seems to have larger ice sheet wide integrated PRECIP, and larger ice sheet wide integrated melt, then FV. Both of these trends are a degradation relative to obs.

Our first PUMAS run improved precip bias over Greenland and Antarctica, likely b/c autoconversion being limited by thinner clouds. The plan is to thicken these clouds via tuning, but pls keep in mind how this may degrade precip over ice sheets.

New souretopo should improve PRECIP bias in Greenland, which is current to do #62

Background on SMB biases in AMP drive here.

@JulioTBacmeister
@andrewgettelman
@whlipscomb

[adamrher]

From @billsacks on spinning up the snowpack in CESM2:

For everyone's reference, I am copying below some relevant emails from a discussion about reset_snow when we were discussing this option in the test runs for CESM2, in 2017. I have only skimmed back through these myself, but the basic summary seems to be that there was also concern at that time about resetting the snow pack over glaciers due to the transient impact this would have, but resetting the snow pack over non-glacier columns seemed safer. I don't think it's important to read through all of this right now, but wanted others (who may not have been on the cc list 5 years ago) to have these for future reference when thinking about what to do as we get closer to the final configuration.

Here are the relevant emails from that thread, from older to newer:

From Leo van Kampenhout:

Hi Keith, Dave, and others,

Currently I'm looking at simulation 202_01 (20th C) to see whether we (as in, the LIWG) like the Greenland simulation.

Unfortunately, the ablation region is pretty narrow compared to my older runs, based off #190, in which I did a snow height reset over glacier columns. Experience tells me that resetting snow height on glaciers columns makes quite a difference in determining snow cover, seasonal or permanent, similar to what you guys must have experienced with non-glaciers cells.

The solution for non-glacier columns was to implement a namelist variable (reset_snow) that when set to TRUE, resets snow height to a small value like 100 mm SWE.

Glacier columns are excluded from this procedure, because of potential water balance problems in a coupled setup — glacier columns may take a long time to spin up to full snow height, especially in the dry interior of an ice sheet.

The current situation is therefore — please correct me if I’m wrong here — that snow height for non-glc columns is reset at the beginning of the preindustrial (B1850) simulation and snow height on glaciers is taken from a previous model run. In the case of #202 this is simulation b.e11.B1850C5CN.f09_g16.005_yr402_cesm2_v2 , which was performed with code as old as CESM 1.1, if I interpreted the casename correctly. This implicates that, as it stands today, glacier snow in new, coupled runs will be biased (i.e. have hysteresis) because of older model code, assuming that code is pre-#196 when snow albedo was changed. I believe this explains why the snow model changes do not work out as planned on Greenland.

Right now I can think of two solutions to this, I must admit, quite specific problem.

1. The proper way. For every code change that affects snow on glaciers, a new land-only spinup is performed, using CAM forcing from a cold-started, coupled run that uses the new snow code. Any new coupled B1850 simulation should then use this new spinup. I realise this adds major overhead to the current development cycle and is therefore not ideal. Still, this will be the way it will be done for the final, CMIP6 runs, right?

2. The dirty way. Just for testing purposes, we can reset snow height also over glaciers at the beginning of B1850 simulation. To avoid water balance problems, however, this is done only up to some pre-defined equilibrium height, above which we assume permanent snow and no reset is necessary. Previously I used elevation 1774 m as a threshold based on regional model output. The reason that this is dirty is because by prescribing snow height based on observed locations we’re steering model behaviour, which is not really desirable in a free-running model. But I guess this is acceptable as long as it’s only done in the testing and development cycle, in order to avoid option 1).

Bottom line: in order to properly see the effect of snow physics changes on glacier columns, hysteresis from initial files that were produced with older code must be avoided as much as possible. Therefore, my proposal would be to implement option 2) as soon as possible, unless you guys think that 1) is feasible as well.

The code changes that are required for 2) I have ready for use, and are pretty minor anyway. I suggest to implement this in two new namelist parameters, called ‘reset_snow_glc’ and ‘reset_snow_glc_ELA’ (Equilibrium Line Altitude) or something to distinguish from the existing ‘reset_snow’. I have no idea about CESM2 timelines, but even if this doesn’t make it in time for the release, it could still be useful to implement, because I feel this issue will be coming back over and over again.

Cheers,
Leo

From Jan Lenaerts:

Hi J-F,

Because the glacier cells are initiated from an earlier test simulations, the ice sheets start off with too much snow - in contrast to the land, where snow is initialised very thin. The reason why this is done is to prevent unwanted water imbalance after initialisation (the ice sheets building up snow without discharging water into the ocean until 10 m snow is reached). As this time this prevents us from analysing the 202 simulation in detail. Regardless, overall ice sheet climate appears to be consistent with previous simulations, so no obvious red flags.

If we want to do this right, we’ll have to do a branched 202 simulations with artificially initialising a thin snowpack on the ice sheets, and analyzing these outputs. But we want to make sure it is worth the substantial work effort, considering that 202 might or might not be a final simulation. Our experience (which really gets richer and richer after all this time :) ) is that the initialisation is crucial, so we’ll have to make sure this is done right in a/the final simulation. We are working with Dave Lawrence and Keith Oleson to come up with a more permanent solution for this problem.

So, my question to you is if we need to devote some time on this in the next few days, or whether we can wait a little while and see if the atmosphere changes beyond 202 are going to be considered as well?

Thanks,

Leo and Jan

From Dave Lawrence:

Thanks Leo,

Yes, this snow initial condition thing is tricky, isn't it. If you have the code, then we should try to get this implemented. As you say, whether or not it makes it into the release, it will be good to have the capability to do something like this.

And Keith [Oleson] is correct that we only intend to do reset_snow = .true. when initializing from an offline spinup with non-CESM forcing, just to avoid an 'unneccesary' transient at the beginning of a simulation.

We will start from scratch for the final spinup, whenever that happens.

Dave

From Leo:

Hi Dave, Keith,

Yes, this snow initial condition thing is tricky, isn't it. If you have the code, then we should try to get this implemented. As you say, whether or not it makes it into the release, it will be good to have the capability to do something like this.

find the code here, including namelist changes:
/glade/u/home/lvank/cesm/my_cases/bgruns202/src_reset_snow_glc

I just tested this code in an actual run and it appears to work as it should. It would be great if this could be put into place, and used in the subsequent testing runs because it would give us a handle on Greenland surface response to code changes (e.g. #196).

And Keith is correct that we only intend to do reset_snow = .true. when initializing from an offline spinup with non-CESM forcing, just to avoid an 'unneccesary' transient at the beginning of a simulation.

I agree that this is desirable for scientific runs, but for testing you could still do it though. In theory, snow may have built up because of a cold bias in older code , which would not happen if you'd recreate the forcing with newer code.

Thanks,
Leo

[adamrher]

From older issues to consider from Bill Sacks:

Hi Adam, Bill L, Gunter & Kate,

This forum post https://bb.cgd.ucar.edu/cesm/threads/difference-between-total-precipitation-over-greenland-from-clm-variable-rain-snow-and-cam-precc-precl.7712/#post-46403 from someone working with Adam reminded me of the change we made for some CMIP6 runs, which we decided at the time not to bring to CTSM master: ESCOMP/CTSM#586.

I just wanted to bring that back to your attention if you (like me) had forgotten about it, as we are thinking about the new set of CESM3 runs and their comparison to CESM2.

Adam responded:

So to be clear, the cold temperature rain from the atmosphere that were to be partitioned into snow by CLM, is instead set to runoff in order to reduce the positive accumulation bias. And that this 'runoff' behavior is specific to the Greenland region only. I think you made the right choice not to bring this onto master as this seems hacky and opaque to users.