[Liwg-core] proposal

Bill Sacks sacks at ucar.edu
Thu Mar 30 20:04:52 MDT 2017


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? 
>>>> 
>>>> Thanks, 
>>>> 
>>>> miren
>>>> 
>>> 
>> 
> 

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


More information about the Liwg-core mailing list