[Liwg-core] Can we move the skype call to an hour earlier or later?

Bette Otto-Bliesner ottobli at ucar.edu
Tue Mar 28 09:59:55 MDT 2017


Bill Sack's presentation is starting late so he asked me to let you know.
Please start without him.

On Tue, Mar 28, 2017 at 1:21 AM, Miren Vizcaino <M.Vizcaino at tudelft.nl>
wrote:

> Hi
> 4 pm is best for me, but I can do 6 pm If this works better for others
> Miren
>
> Sent from my iPhone
>
> On 28 Mar 2017, at 08:11, Kampenhout, L. van (Leo) <L.vanKampenhout at uu.nl>
> wrote:
>
> Both new times work for me.
>
> Leo
>
>
> Op 28 mrt. 2017 om 03:13 heeft Lipscomb, William Henry <lipscomb at lanl.gov>
> het volgende geschreven:
>
>
> I could talk tomorrow at 10 am MDT, but not 8 am.
>
> Thanks,
> Bill L.
>
>
> On Mar 27, 2017, at 6:01 PM, Bill Sacks <sacks at ucar.edu> wrote:
>
> Hi Jan & others,
>
> I found out I need to give a presentation at 9:20 am MDT tomorrow. Can we
> move the Skype call to either (1) 8 am MDT / 4 pm Netherlands, or (2) 10 am
> MDT / 6 pm Netherlands? Sorry for the last-minute notice.
>
> Bill S
>
> On Mar 27, 2017, at 4:29 AM, Lenaerts, J.T.M. (Jan) <j.lenaerts at uu.nl>
> wrote:
>
> I think Skype is fine. See you tomorrow!
>
>
> On 25 Mar 2017, at 02:30, Bill Sacks <sacks at ucar.edu> wrote:
>
> Sounds great. Do you want me to try to set up our usual ReadyTalk number?
> I'm happy to use Skype if you prefer... I'm billjsacks.
>
> Bill
>
> On Mar 24, 2017, at 4:47 PM, Lenaerts, J.T.M. (Jan) <j.lenaerts at uu.nl>
> wrote:
>
> Let’s go for Tuesday at 5 pm Netherlands / 9 am Boulder time then!
>
> Have a great weekend,
>
> Jan
>
>
> On 24 Mar 2017, at 17:55, Bill Sacks <sacks at ucar.edu> wrote:
>
> Something just came up for me Monday at 9 am (5 pm your time). So Tuesday
> will be easier for me, though I could do Monday at 8 am / 4 pm if that
> works best for others.
>
> Bill
>
> On Mar 24, 2017, at 8:51 AM, Kampenhout, L. van (Leo) <
> L.vanKampenhout at uu.nl> wrote:
>
> All those three options also work for me.
>
> Leo
>
>
> On 24 Mar 2017, at 14:04, Miren Vizcaino <M.Vizcaino at tudelft.nl> wrote:
>
> Dear All,
>
> I can do Monday one hour earlier (our 4 pm, 8 am for Bill) and Tuesday at
> 4 or 5 pm.
>
> Thanks, Miren
>
> On Mar 24, 2017, at 1:08 PM, Bill Sacks <sacks at ucar.edu> wrote:
>
> Hi Jan and others,
>
> Good idea. I can do a Skype Monday at 9 am MDT. Slightly earlier times, as
> well as any time Tuesday morning, would also work for me if that works
> better for others.
>
> Bill S
>
> On Mar 24, 2017, at 5:03 AM, Lenaerts, J.T.M. (Jan) <j.lenaerts at uu.nl>
> wrote:
>
> Hi Bill,
>
> Thanks, let’s decide early next week on the way forward. Besides the snow
> resetting, I don’t think other changes are warranted.
>
> To facilitate the process, can we perhaps organize a quick Skype meeting
> with you, Miren & Raymond, Bill L. (if available), and Leo and me, on
> Monday (let’s say at 5 pm our time, we are back to 8 hours difference after
> this weekend, so it will be 9 am your time)? Is everyone available then? If
> not, Tuesday would work as well, as well as earlier times (if you can meet
> us earlier than 9 am).
>
> Cheers,
>
> Jan
>
> On 23 Mar 2017, at 18:47, Bill Sacks <sacks at ucar.edu> wrote:
>
> Hi all,
>
> Raymond / Miren: Thank you for the clarifications about snowfall amounts.
> This does provide a better argument for resetting to something less than
> 100mm, at least for this region. I'd still be bothered if there is this
> strong of a sensitivity to initial conditions, but I'd be open to switching
> the initialization to something less than 100mm if others agree with that,
> and if Dave Lawrence allows this change.
>
> I am still worried about how we're going to implement this in practice. I
> understand that your procedure avoids massive ocean runoff, but it does so
> via doing an extra run. In addition, my understanding is that we'll need to
> tweak this in order to only reset h2osno_max over non-glacier points –
> because for the "real" spinup, we don't want to delete all of the snow over
> glaciers. Probably this will come down to putting in place a temporary code
> hack and having someone like Cecile add this to their instruction list for
> setting up the spinup – which would mean this procedure is a one-time thing
> that isn't available to other people who want to do their own spinups
> later. This isn't an ideal scenario, but *may* be allowable if we find
> that it's important.
>
> At the moment the model is generating too much ice melt, (because of the
> SCF), and we need to work on that.
>
>
> Can you please clarify what work you're still doing on this? If there are
> potential changes beyond just the resetting of snow, we need to let Dave
> Lawrence and others know about this.
>
> Finally, regarding the time frame for all of this: It sounds like the
> first iteration of the coupled spinup could start the week of April 3. That
> gives us next week to finalize these things. However, I feel we need to
> make any decisions by early next week, to allow time for these decisions to
> be cleared by Dave Lawrence and others, and to allow time for anything to
> get implemented on the trunk.
>
> Bill S
>
> On Mar 23, 2017, at 9:15 AM, Miren Vizcaino <M.Vizcaino at tudelft.nl> wrote:
>
> Hi Bill and All,
>
> I copy Raymond’s response to (1)
>
> "Just to clarify on point (1), what I meant with the minimum amount was
> not the ‘all-time-minimum’, but the location that has the least snowfall,
> has on average (over a 20-year period) 35mm (standard deviation: 11mm) of
> snowfall during Sep-Jan. For comparison, the location with the most
> snowfall in this region has on average 75mm of snowfall during this same
> period (standard deviation: 20mm). This means that if we initialize with
> 100mm, we initialize with a snow mass that is 1.3x - 3x more than what is
> realistic in this area, and also more than snowfall + standard deviation.
> Sure, there is also the possibility to pick a number between 35mm-100mm,
> but why not ensure that every location at least have the possibility to get
> to seasonal snow cover in the first year, rather than artificially impose a
> snow cover that represents extreme snowfall in this region?"
>
> Now my response to (1):  Northern Greenland is a dry place, so don’t
> expect large amount of snowfall variations. The mass balance is very
> sensitive to accumulation, as we saw before.
>
> As far as I understand, RACMO starts with zero snow thickness in
> September. Since we cannot do this, we cannot afford putting excessive snow
> thickness when starting in January.
>
> Regarding (3), Raymond found out that the netCDF format for CISM (scale
> factor) was responsible for the discrepancy. Maybe worth to be warned of to
> other CISM users (?)
>
> Regarding (4) I cannot attend.
>
> And now an update: Leo will be testing n_melt and Raymond on repartition.
>
> Regarding Jeremy’s question about stability of this result: we need to run
> past year 20, but first we need to do the testing for n_melt and
> repartition. At the moment the model is generating too much ice melt,
> (because of the SCF), and we need to work on that.
>
> Thanks, Miren
>
>
>
>
> On Mar 22, 2017, at 10:26 PM, Bill Sacks <sacks at ucar.edu> wrote:
>
> Hi Miren, Raymond and others,
>
> A few thoughts:
>
> (1) Regarding initialization at 35 mm: If we truly find that initializing
> at 35 mm allows for ablation areas, whereas initializing at 100 mm causes
> permanent snow cover – if the model is really this sensitive to initial
> conditions, then I think we have bigger problems. My understanding is that
> you chose 35 mm because it was the *minimum *amount of snow fall from
> Sept - Jan in this region. But that suggests to me that, at many places and
> times, we'd expect greater than 35 mm SWE on the ground on Jan 1. If the
> model is truly this sensitive to initial snow cover, then presumably a
> single year with higher-than-usual Sept - Dec snowfall would lead to
> incurable permanent snow cover, following the logic in this email thread.
>
> My point here is that I am hesitant to believe that it is important to
> initialize at 35 mm rather than 100 mm unless I see an clean experiment
> showing its effect. On the other hand, I also don't object to
> initialization at 35 mm if there is agreement to do that.
>
> (2) Regarding the initialization procedure: Thanks for the clarification
> about doing this via setting h2osno_max. I definitely see how that is a
> better way to ensure self-consistency. However, I don't think this is
> something we can hope to allow out-of-the-box, and it may meet a bit more
> reluctance from Dave Lawrence and others in the land group: In order to
> avoid hitting the ocean with a massive runoff signal, we'd need to do this
> via an additional offline run that is run for a few days (or somewhat
> longer) to allow the runoff to make its way out of the system, before
> restarting the coupled run. I would need to check with others as to whether
> this is an acceptable step in the spinup procedure. If your additional
> experiments show that resetting the snow pack (without any other changes)
> has the benefits we want, then I'll pursue this further.
>
> (3) Regarding the discrepancy that Miren mentions between the integral of
> (SMB < 0) and QICE_MELT: Without knowing exactly how you did these
> integrals, it's hard for me to say. In general, I don't think I'd expect
> these to be exactly equal: I don't think the current elevation class
> interpolation makes any guarantees about this – though this changes with
> the new scheme that Bill Lipscomb has implemented. But I'd still expect the
> integrals to be closer than what you gave. I wonder if this is due to
> missing some weighting factors in computing the integral on the CLM side?
> For example, since these QICE variables apply only over glacier landunits,
> you need to multiply by the area of the glacier landunit (PCT_LANDUNIT(4)
> on the CLM history files).
>
> (4) There will be a co-chairs meeting tomorrow (Thursday) at 10 am MDT,
> where I hope to learn more about where we are on the timeline of the CESM2
> spinup, and thus how much more time we have to finalize all of this. Feel
> free to call in if you'd like to contribute to the discussion.
>
> Bill S
>
>
> On Mar 22, 2017, at 1:54 PM, Lenaerts, J.T.M. (Jan) <j.lenaerts at uu.nl>
> wrote:
>
> Hi all,
>
> Thanks Raymond and Miren for the great work.
>
> I am a bit cautious on using this 35 mm. In this case, i.e. without
> repartitioning and with N_MELT=0.5, this seems to work, but I wonder what
> happens as soon as one of these two is reset to default values.
>
> Switching off repartitioning is undesirable, since that would create a
> huge discrepancy between land and glaciers (assuming we only switch it off
> for glaciers). We still have some room to play with N_MELT.
>
> Cheers,
>
> Jan
>
>
>
>
>
>
>
>
> On 22 Mar 2017, at 17:39, Jeremy Fyke <garmeson.lanl at gmail.com> wrote:
>
> Hi Miren
>
> This is great.  To what extent do you think this represents an
> equilibrated snow pack/ablation area?  Ie are you guys confident the snow
> pack isn't 'filling in' still, and that this ablation area would persist
> indefinitely if this simulation was continued?
>
> Jeremy
>
>
>
>
> On Wed, Mar 22, 2017 at 10:13 AM Miren Vizcaino <M.Vizcaino at tudelft.nl>
> wrote:
>
>> Hi Bill, and All
>>
>> The latest simulation is able to sustain N Greenland ablation areas and
>> seasonal snow over ice-free areas
>>
>> https://www.dropbox.com/s/da8ez62hipf04ns/134_newinitialization.pdf?dl=0
>>
>> Raymond is running another resetting simulation with the repartition on.
>>
>> For the resetting technique, please check with Leo if anything remains
>> unclear. Raymond was applying Leo’s capping approach that I assume will
>> adjust all variables.
>>
>> One important remaining issue is the mismatch between downscaled SMB<0
>> and QICE_MELT. Bill and Bill, do you have any ideas of what is going on
>> here? Could it be related to still having acab=0 over the
>>
>> accumulation areas?
>>
>> - integrated ablation for the downscaled SMB (sum of SMB<0) = 70 Gt;
>> however, integrated QICE_MELT=300 Gt (maybe due to differences in how the
>> 1-SCF is included in the computation?)
>>
>>
>>
>> Regarding refreezing, the spatial map and amounts seem to largely agree
>> with RACMO (please see slide 6 of the PDF). The % using melt as the sum of
>> QICE_MELT and snow melt is in the right ballpark.
>>
>> I’d like very much to hear from Jan, Leo and/or Michiel on the thickness
>> initialization amount. My take here is that, giving the delicate mass and
>> energy balance in northern Greenland, and that we don’t start the runs in
>> September, it is critical to follow Raymond’s recommendation.
>>
>> Thanks, Miren
>>
>>
>>
>>
>>
>> On Mar 22, 2017, at 3:28 PM, Raymond Sellevold - CITG <
>> R.Sellevold-1 at tudelft.nl> wrote:
>>
>> Hi,
>>
>> Yes, I will also do an experiment with n_melt = 1, to see the effect of
>> resetting the snowpack more clearly.
>>
>> There have been several experiments by Leo where the snow has been reset
>> to 100mm over the tundra, with the outcome that the snow keeps on growing.
>> The reason seems to be because the total melt in this region is the same as
>> the yearly snowfall and when areas that have a total snowfall of 35mm w.e.
>> between end of melt season and January are initialised with 100mm in
>> January, you end up with more snow than the model is able to melt in the
>> summer, thereby causing the permanent snow cover. The same story applies
>> for the northern ablation areas.
>>
>> Currently, I have adapted Leo’s method of doing this: h2osno_max is set
>> to 35.0 and I run the model for one day, such that the model itself
>> calculates the snow. I figured this was a better idea then editing the
>> restart files since h2osno is not the only variable related to snow.
>>
>> Raymond
>>
>> On 21 Mar 2017, at 22:16, Bill Sacks <sacks at ucar.edu> wrote:
>>
>> Hi Miren and others,
>>
>> Thanks a lot for this.
>>
>> This sounds promising, but it also sounds like we need a clean experiment
>> to just see the effect of resetting the snow pack. In addition to turning
>> the repartitioning back on, should n_melt be kept at 1 for this?
>>
>> I'm also wondering if a reset value of 100 mm would have the desired
>> effects, since that was the value that I thought we agreed on. I guess we
>> could use 35 mm, but it seems confusing to have this reset value differ
>> from the cold start value, which is currently set at 100 mm. Should we also
>> switch the cold start value to 35 mm in this case? I'm interested to hear
>> what others think about this – particularly Leo and Jan, who had thoughts
>> in the past about the appropriate snow initial conditions to avoid
>> undesirable heating of soil under snow.
>>
>>
>> Also: I realized that there could be some subtleties with how exactly we
>> should reset the snow pack. If we decide to move ahead with this solution,
>> I'd like a more detailed description of how this should be done.
>> Specifically: it's not clear to me that just resetting h2osno is enough,
>> because there are a lot of different snow variables, and resetting h2osno
>> without resetting some other variables might cause things to be in an
>> inconsistent state.
>>
>> Related variables that are integrated across the snow column are
>> int_snow_col, snow_depth_col, and possibly others. And then there are many
>> variables that are stored layer-by-layer for the snow pack. Does anyone
>> know if any of these variables need to be reset for things to be in a
>> consistent state? (From a quick look through the code, it looks like it
>> should be okay not to reset int_snow_col, but I'm not positive of that, and
>> I'm not sure about the other variables.)
>>
>> Thanks,
>> Bill S
>>
>>
>>
>> On Mar 20, 2017, at 10:41 AM, Miren Vizcaino <M.Vizcaino at tudelft.nl>
>> wrote:
>>
>> Hi,
>>
>> Raymond did a new run with #134 physics and reset of initial snow
>> thickness to 0.35mm over the GrIS and n_melt=0.5 and rainfall repartition
>> off.
>>
>> The simulations has gone through 20 years. Ablation areas of GrIS are
>> well captured and amount to 10% of ice sheet area.
>>
>> Other highlights:
>>
>> - Seasonal snow cover over tundra
>>
>> - Some high accumulation areas in the SE have reached maximum snow
>> thickness (10 m w.e.)
>>
>> - integrated ablation for the downscaled SMB (sum of SMB<0) = 70 Gt;
>> however, integrated QICE_MELT=300 Gt (maybe due to differences in how the
>> 1-SCF is included in the computation?)
>>
>> - refreezing amounts to 40% of snowmelt + QICE_MELT + rainfall and 57% of
>> snowmelt + downscaled ice melt + rainfall.  Still a high ratio. Will this
>> ratio change as snow thickness equilibrates ?
>>
>> Next steps:
>>
>> -  sensitivity to switching on rainfall repartition
>>
>> Thanks, Miren
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Liwg-core mailing list
>> Liwg-core at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/liwg-core
>>
> _______________________________________________
> Liwg-core mailing list
> Liwg-core at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/liwg-core
>
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> *Jan Lenaerts  *IMAU, Utrecht University || University of Colorado
> @lenaertsjan <https://twitter.com/lenaertsjan> || website
> <http://www.colorado.edu/lab/icesheetclimate/>
>
>
>
>
>
>
>
>
> _______________________________________________
> Liwg-core mailing list
> Liwg-core at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/liwg-core
>
>
>
>
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> *Jan Lenaerts  *IMAU, Utrecht University || University of Colorado
> @lenaertsjan <https://twitter.com/lenaertsjan> || website
> <http://www.colorado.edu/lab/icesheetclimate/>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Liwg-core mailing list
> Liwg-core at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/liwg-core
>
>
>
> _______________________________________________
> Liwg-core mailing list
> Liwg-core at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/liwg-core
>
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> *Jan Lenaerts  *IMAU, Utrecht University || University of Colorado
> @lenaertsjan <https://twitter.com/lenaertsjan> || website
> <http://www.colorado.edu/lab/icesheetclimate/>
>
>
>
>
>
>
>
>
>
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> *Jan Lenaerts  *IMAU, Utrecht University || University of Colorado
> @lenaertsjan <https://twitter.com/lenaertsjan> || website
> <http://www.colorado.edu/lab/icesheetclimate/>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Liwg-core mailing list
> Liwg-core at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/liwg-core
>
>
> ---
> William Lipscomb
> Los Alamos National Laboratory
> Group T-3, MS B216
> Los Alamos, NM 87545
> 505-667-0395 <(505)%20667-0395>
>
>
>
>
> _______________________________________________
> Liwg-core mailing list
> Liwg-core at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/liwg-core
>
> _______________________________________________
> Liwg-core mailing list
> Liwg-core at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/liwg-core
>
>
> _______________________________________________
> Liwg-core mailing list
> Liwg-core at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/liwg-core
>
>


-- 
Bette L. Otto-Bliesner
Deputy Director and Senior Scientist
Climate and Global Dynamics Laboratory

National Center for Atmospheric Research
1850 Table Mesa Drive
Boulder, Colorado 80305
Ph:  303-497-1723
Fax: 303-497-1348
Email: ottobli at ucar.edu
Web page: http://www.cgd.ucar.edu/ccr/ottobli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/liwg-core/attachments/20170328/b7600e83/attachment-0001.html>


More information about the Liwg-core mailing list