[Liwg-core] proposal

Kampenhout, L. van (Leo) L.vanKampenhout at uu.nl
Fri Mar 31 08:35:34 MDT 2017

Hi Bill,

I have just this simple hack that changes the maximum snow height over non-GLC points:

Depending on the desired work flow, this could be enough, or you may want something similar but only active for a certain number of time steps. The code you wrote at the beginning of this week is better in that respect.


On 31 Mar 2017, at 15:53, Bill Sacks <sacks at ucar.edu<mailto:sacks at ucar.edu>> wrote:

Hi Miren,

Okay, thanks. I will proceed with the code for doing the resetting over tundra today.

Leo: Have you gotten any chance to work on this code? If not, I'll just take it on.

And Miren and others: I'm sorry that there isn't time for me to implement a more ideal solution.

Bill S

On Mar 31, 2017, at 6:55 AM, Miren Vizcaino <M.Vizcaino at tudelft.nl<mailto:M.Vizcaino at tudelft.nl>> wrote:

Hi Bill and All,

It seems to me like there is agreement on resetting over the tundra and that is worthy to have it out-of-the-box, e.g., for Task3B and future resets

Over the ice sheet, it would make sense if it improves substantially the forcing for the snow/firn spin-up in Task3B. Raymond made some plots on climate differences caused by resetting:


The resetting does warm ablation areas and tundra (see incoming LW, temperature) when looking to these JJA means, but the effect is not striking.
However the big caveat is that the forcing will be 3-hourly and these plots are for JJA means. Also, relatively small climate differences (e.g. +1K) can make a huge difference around a tipping point

It seems clear that not resetting will result in a cold bias, but I haven't proof that it is critical

I am in favor of resetting with "reset snow for non-glacier points and for all glacier points with topographic height below x m”, to act against the danger of creating useless forcing, but from the discussion (inside and outside this email thread) I don’t think this is supported by others.

So, unless there is a massive mind change here, we have consensus only to reset over tundra.

Thanks, Bill and All, Miren

On Mar 31, 2017, at 4:04 AM, Bill Sacks <sacks at ucar.edu<mailto:sacks at ucar.edu>> wrote:

Hi Miren & others,

Please let me know if you feel there is consensus on how this resetting should be done, in some way that does not involve a spatial map. If there is consensus, I can try to implement it tomorrow (Friday).

Bill S

On Mar 30, 2017, at 2:51 PM, Bill Sacks <sacks at ucar.edu<mailto:sacks at ucar.edu>> wrote:

Hi Miren,

Sorry if I wasn't clear about what option could work. What I meant was: If there is a simple rule that could be coded up in a few lines of code in CLM, without relying on any new spatially-varying fields, then that could be doable. For example, a rule like "reset snow for non-glacier points and for all glacier points with topographic height below 1000 m" would be easy to incorporate, but a rule based on reading values for every point in space is more involved.

Bill S

On Mar 30, 2017, at 2:23 PM, Miren Vizcaino <M.Vizcaino at tudelft.nl<mailto:M.Vizcaino at tudelft.nl>> wrote:

Hi Bill,

Thanks for explaining the options. We are sorry that we misunderstood what was expected from us to provide. (Being honest, I still don't know)

Regarding the alternative, neither Raymond or me would know by ourselves how to reset the multiple variables involved in the reset ("capping") for each column manually. If someone can and wants to help, please let us know.

Thanks! Miren

On Mar 30, 2017, at 4:37 PM, Bill Sacks wrote:

Hi Miren,

As this falls into the category of ingesting a new spatial map into CLM, this is not feasible to get onto the CLM trunk in time for the spinup run: Getting a new spatial map into CLM involves either (a) adding a new "stream" input (substantial code development), or (b) adding a new field on CLM's surface dataset (moderate code development plus some tedious work of regenerating new surface datasets for every resolution). Either one takes more time than we have.

Since you seem keen on doing some resetting over the ice sheet, I'll suggest one other option: Rather than trying to get this resetting to work out-of-the-box on the CLM trunk, you or Raymond or someone else could implement this in a one-time fashion, and then process the single CLM restart file that will be used for Task 2A next week. This would be easier than the more general solution, because you could possibly do this with some python/ncl/etc. scripts rather than trying to embed it in the CLM code. However: This would mean that this option wouldn't be available out-of-the-box, and if it needs to be redone for any reason, you would need to redo this processing. Unfortunately, I don't think I can commit much time to help with this option, because there does not seem to be consensus that it is worth doing. But if you're willing to do this yourselves, then it could be a feasible option.

Bill S

On Mar 30, 2017, at 8:18 AM, Miren Vizcaino <M.Vizcaino at tudelft.nl<mailto:M.Vizcaino at tudelft.nl>> wrote:

Hi Bill,

The proposal is to use two variables from the latest run from Raymond - so it is based on inherent CESM2 model behavior.

output is here /glade/scratch/raymonds/archive/b.e20.B1850.f09_g16.pi_control.all.134_reset35_n05rep/lnd/hist

We rejected the idea of the ELA because

1) we don’t have SMB output per EC

2) prescribing an “observation-based" ELA falls into the problem of “baking" the answer

We propose to take the model output, and reset wherever Hsnow (t=20) - annual mean snow melt (average t=10-20) < 2 m w.e.  for the Greenland ice sheet.

Reset over tundra and all small glaciers

No reset for AIS, since we don’t aim to simulate ablation areas there

The idea is that this CESM run has 20 years, so enough time for the driest-with-no-melt areas to build 2 m w.e.

and we permit that grid cells with high accumulation and high melt (e.g. SE) can join the club of producing runoff

Given we have so little time, this seems like a handy solution - Is this feasible to implement?



Liwg-core mailing list
Liwg-core at cgd.ucar.edu<mailto:Liwg-core at cgd.ucar.edu>

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

More information about the Liwg-core mailing list