[MITgcm-devel] heff_max...more sea ice issues
Martin Losch
Martin.Losch at awi.de
Mon Dec 18 15:47:20 EST 2006
Ahem,
then try the B-grid (o:
I personally think that the C-grid is working, but I have not tested
it in very high resolution runs (Dimitris has, though), so if you
find it being unstable (when the B-grid code is stable) it would be a
useful piece of information.
Martin
On 18 Dec 2006, at 21:30, Matthew Mazloff wrote:
> Hi Martin,
>
> In SEAICE_OPTIONS.h I set #define SEAICE_CGRID
>
> I am using seaice model version checkpoint58s_post.
>
> So unless I have missed something, I am using the C-grid seaice model.
>
> Matt
>
>
> On Dec 18, 2006, at 3:25 PM, Martin Losch wrote:
>
>> Hi Matt,
>>
>> are you using the original B-grid dynamics code? If so, do you
>> have some sort ice-ocean stress turned on? Apparently ice-ocean
>> stress can be a problem with the B-grid model. If it is not too
>> much effort, try to run with the C-grid dynamics (#define
>> SEAICE_USE_CGRID or so) and see what happens. With the C-grid the
>> ice-ocean coupling seems to be less of a problem (at least thats's
>> what Dimitris sees in his runs).
>>
>> Martin
>>
>> On 18 Dec 2006, at 20:57, Matthew Mazloff wrote:
>>
>>> Hi Jinlun,
>>>
>>> I am not 100% sure what is happening. The info I have comes from
>>> the monitor output.
>>>
>>> with: SEAICEuseDYNAMICS = .TRUE. the model crashes after 6
>>> months. Heff_max is not a smooth function but jumps quite a bit
>>> with time
>>> with: SEAICEuseDYNAMICS = .FALSE. the model runs
>>> successfully for one year. Heff_max is smooth in time and the
>>> values are at the low side of the oscillations I see with the
>>> dynamics on: I've attached a picture below
>>>
>>> The advcfl_W_hf_max is similar in both models...perhaps it is the
>>> seaice model that is crashing. Without ice dynamics, however,
>>> the ocean velocity fields have larger maxima. But the cfl numbs
>>> associated with these maxima are still OK.
>>>
>>> So maybe it is the ice model that is unstable. I do not know
>>> what stability criteria I should consider with the ice model. My
>>> setup: 1/6 degree resolution, 900 second timesteps, using C-grid
>>> ice model configuration, LSR_ERROR = 1e-3.
>>>
>>> I know this really isn't too much info....sorry about that. Any
>>> ideas?
>>>
>>> Thanks for the help,
>>> Matt
>>> <heff_max.jpg>
>>>
>>>
>>> On Dec 18, 2006, at 1:53 PM, Jinlun Zhang wrote:
>>>
>>>> Hi Matt,
>>>>
>>>> When the model crashes, is it the ice that crashes, or the ocean
>>>> crashes? Generally, thick ice won't cause crashes (or make the
>>>> ocean more stable) because it moves slower and it does not
>>>> create big buoyancy change. So change heff_max generally won't
>>>> help much if the model would eventually blow up. And it is not a
>>>> good idea to set heff_max low because if would create lots of
>>>> side effect (buoyancy). One sensitivity study is to turn off ice
>>>> dynamics and run the model for sufficiently long to see what
>>>> happens. Another thing is to make sure the calculation of ocean
>>>> surface stress is robust?
>>>>
>>>> Jinlun
>>>>
>>>> Matthew Mazloff wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> My upper layer is 10m thick. When heff_max > 5m the model
>>>>> crashes. (This only happens with dynamics on (LSR_ERROR =
>>>>> 1e-3 in my calculations so not very accurate). With dynamics
>>>>> off the ice never reaches this thickness.) I am modeling the
>>>>> Southern Ocean, I am sure Arctic modelers must have this
>>>>> problem to an even greater degree. What is other people's
>>>>> experiences with thick ice and stability? Should an effective
>>>>> thickness capping be implemented?
>>>>>
>>>>> Thanks
>>>>> -Matt
>>>>>
>>>>>
>>>>> fyi: I tried the free drift sea ice hack (i.e. setting uc ~
>>>>> uvel in seaice_advdiff.F) and the model crashed. The results
>>>>> were odd....lots of numerical noise in AREA and, it appeared,
>>>>> no significant advection.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Dec 6, 2006, at 3:45 PM, Martin Losch wrote:
>>>>>
>>>>>> Hi Jinlun,
>>>>>>
>>>>>> in the end, we want to be able to use a flux-limited 3rd
>>>>>> order advection scheme, it's just not yet possible.
>>>>>>
>>>>>> Unfortunately my model stops at 80degN. I really need to set
>>>>>> up a truly global ocean model. I do assume though, that there
>>>>>> is something fishy with the precipitation in the CORE data
>>>>>> set. Would be interesting to see if some-one else has a
>>>>>> similar experience.
>>>>>>
>>>>>> In general, though, the ice extend is too large in winter (in
>>>>>> particular in the Drake Passage, isn't it?). That 's the only
>>>>>> thing that's still worrying me.
>>>>>>
>>>>>> XKI: I am only playing with this parameter to find out how the
>>>>>> model (s) behave(s). In practice I will always use something
>>>>>> around 2. XKI only appears in the denominator in budget.F, so
>>>>>> I don't quite see what it does. I guess I have to dig up
>>>>>> Hibler79/80 and have a look at the thermodynamics, right?
>>>>>>
>>>>>> M.
>>>>>>
>>>>>> On 6 Dec 2006, at 18:34, Jinlun Zhang wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Martin Losch wrote:
>>>>>>>
>>>>>>>> Hi Jinlun,
>>>>>>>> thanks for you input. I really enjoy this discussion!
>>>>>>>>
>>>>>>>> For clarification: I use the same advection for HEFF, HSNOW,
>>>>>>>> and AREA. That is run47 has 1st order upwind for all
>>>>>>>> three variables, while run41 has 2nd order central
>>>>>>>> differences scheme (and not flooding algorithm). All runs
>>>>>>>> use a little bit of diffusion (the default values of
>>>>>>>> DIFF1=0.004), which is probably not good for run47.
>>>>>>>
>>>>>>>
>>>>>>> Hi Martin,
>>>>>>>
>>>>>>> Good the ice and snow advection is consistent. When you use
>>>>>>> 1st order upwind, perhaps you do not have to use any
>>>>>>> diffusion (if you have used any) since it is quite diffusive.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> run48 uses only 10% of the snow precipitation, but uses
>>>>>>>> flooding (it's just like 45). Are you saying that this
>>>>>>>> should not reduce the ice amount? One source of the ice is
>>>>>>>> flooded snow in the flooding algorithm in the current
>>>>>>>> version of growth.F (http:// dev.mitgcm.org/ cgi-bin/
>>>>>>>> viewcvs.cgi/MITgcm/pkg/seaice/growth.F?
>>>>>>>> rev=1.34&only_with_tag=MAIN&content-type=text/vnd.viewcvs-
>>>>>>>> markup). One of my problems was, that the huge amounts of
>>>>>>>> snow that you see in run40 (160m in some places, no
>>>>>>>> flooding, no advection) are turned into ice by flooding
>>>>>>>> and lead to ice thicknesses beyond my expectation. Either
>>>>>>>> there is too much snow to begin with, or something is
>>>>>>>> wrong in the handling of snow and not enough snow is melted.
>>>>>>>
>>>>>>>
>>>>>>> I was looking at wrong figure and had mistakenly thought that
>>>>>>> when you reduced snow, ice was pretty much gone. But
>>>>>>> actually ice was only slight reduced with run48, not really
>>>>>>> bad. Sorry for the mistake.
>>>>>>> I don't know what is wrong with run40, but I wonder if this
>>>>>>> huge snow depth also occurs in the Arctic. If that is the
>>>>>>> case in Arctic also, then definitely something is really
>>>>>>> wrong with the model.
>>>>>>>
>>>>>>>>
>>>>>>>> 1D tests: As far as I understand the physics of ice
>>>>>>>> formation: Ice forms because the atmospheric heat flux
>>>>>>>> cools the ocean surface below freezing. Ice continues to
>>>>>>>> grow as long a the atmospheric surface flux continues to
>>>>>>>> cool the ocean. In the presence of ice this atmospheric
>>>>>>>> heat is "diffused" (conducted) through the ice according
>>>>>>>> to the net conductivity. In the absense of snow this
>>>>>>>> conductivity should be SEAICE_iceConduct (XKI in
>>>>>>>> budget.F). If the ocean provides heat from below by upward
>>>>>>>> transport of warmer waters (by vertical convection), then
>>>>>>>> this heat flux can balance the atmospheric heat flux and
>>>>>>>> stop the ice from growing. When you equate these fluxes
>>>>>>>> roughly at equilibrium: Qocean = conductivity*(Tair-
>>>>>>>> Tsurfocean)/hice you get the ice thickness that follows
>>>>>>>> form this balance hice = conductivity*(Tair-Tsurfocean)/
>>>>>>>> Qocean.
>>>>>>>> Hypothetically I should be able to modify this
>>>>>>>> "equilibrium thickness" by playing with the conductivity
>>>>>>>> (or Qocean or the temperature difference). However I find
>>>>>>>> that the model parameter XKI=SEAICE_iceConduct has no
>>>>>>>> impact on hice (I use 1e-6 instead of 2!). That's
>>>>>>>> puzzling, isn't? For the thsice package, the corresponding
>>>>>>>> parameter does have an impact.
>>>>>>>
>>>>>>>
>>>>>>> Your reasoning sounds ok. But I am not sure why ice is so
>>>>>>> insensitive to XKI in equilibrium. It does not make sense.
>>>>>>> Note that XKI is a physical term that is likely determined
>>>>>>> by lad experiments. Better not use a different number. Would
>>>>>>> be interesting to see how sensitive ice thickness/extent is
>>>>>>> to XKI in real simulations.
>>>>>>> Jinlun
>>>>>>>
>>>>>>>>
>>>>>>>> Martin
>>>>>>>>
>>>>>>>>
>>>>>>>> On 5 Dec 2006, at 18:17, Jinlun Zhang wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Martin Losch wrote:
>>>>>>>>>
>>>>>>>>>> Jinlun,
>>>>>>>>>> thanks for your opinion. The thsice thermodynamics are
>>>>>>>>>> basically Winton's (2000) model, but we have not yet
>>>>>>>>>> fully sorted out the advection part.
>>>>>>>>>> I have now a run47 with SEAICEadvScheme = 1 (1st order
>>>>>>>>>> upwind, too smooth) and no flooding, and and another
>>>>>>>>>> one (run48) which is just like run45 but with only a
>>>>>>>>>> 1/10th of the snow fall, just to see what happens, see
>>>>>>>>>> http://mitgcm.org/~mlosch/run47.png
>>>>>>>>>> http://mitgcm.org/~mlosch/run48.png
>>>>>>>>>> As expected is run47 closest to what we expect. But run48
>>>>>>>>>> is not too bad either, too little snow (of course) and
>>>>>>>>>> as a consequence too little ice. So either there is too
>>>>>>>>>> much snow/ precip in the atmospheric forcing, or there
>>>>>>>>>> is something not kosher in the snow parameterizations.
>>>>>>>>>> As the problems are similar with thsice I would agree
>>>>>>>>>> that the forcing may be the problem ... I have to try
>>>>>>>>>> and find different precipitation fields.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Marin,
>>>>>>>>> Yeah run47.png looks pretty good. The advection works ok.
>>>>>>>>> But I wonder what ice advction you are using, 2nd order
>>>>>>>>> or 1st order? The one I installed is 2nd order. Ideally,
>>>>>>>>> the snow advection should be exactly the same as the ice
>>>>>>>>> advection so ice and snow won't devorce with each other.
>>>>>>>>> It is not right with run48 that when the snow is turned
>>>>>>>>> off, ice is gone. Some thing is wrong here.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I have also made another observation: I tried to run the
>>>>>>>>>> different thermodynamics without any dynamics in a 1D
>>>>>>>>>> case. I expect (and JMC agrees with me) that for
>>>>>>>>>> constant air temperature (say -30degC), ice thickness
>>>>>>>>>> should grow until there is some equilibrium thickness,
>>>>>>>>>> when the remaining heat flux out of the ocean is
>>>>>>>>>> balanced by the diffusive flux of heat through the ice.
>>>>>>>>>> I assume that the diffusion is controlled by
>>>>>>>>>> "SEAICE_iceConduct" for seaice and kice for thsice. The
>>>>>>>>>> equilibrium thickness can roughly be estimated by hequil
>>>>>>>>>> = conductivity*(Tair-Twater)/ heatflux.
>>>>>>>>>> I have only succeded yet in reaching some equilibrium
>>>>>>>>>> thickness with thsice (with an unrealistic value of
>>>>>>>>>> kice=1e-6 instead of 2). For growth, this only works if
>>>>>>>>>> I turn on some precipitation (snow). Without snow HEFF
>>>>>>>>>> is completely independent of SEAICE_iceConduct, which I
>>>>>>>>>> don't think is right.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I don't understand this equil. ice thickness )-:. As said
>>>>>>>>> above, without snow-without ice thing or ice not working
>>>>>>>>> right without snow does not make sense to me.You might
>>>>>>>>> want to check with Thorndike (199?) for a toy model of
>>>>>>>>> equil. ice thickness.
>>>>>>>>> Jinlun
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> M.
>>>>>>>>>>
>>>>>>>>>> On 5 Dec 2006, at 03:39, Jinlun Zhang wrote:
>>>>>>>>>>
>>>>>>>>>>> Martin,
>>>>>>>>>>>
>>>>>>>>>>> I would vote run45.png for best performance except that
>>>>>>>>>>> the summer ice is slightly overestimated. I would not
>>>>>>>>>>> vote run41.png because of its weird snow distribution.
>>>>>>>>>>> The snow pattern should generally follow the ice
>>>>>>>>>>> pattern (could mean a problem with ice advection). I
>>>>>>>>>>> don't know why the snow gets so thick with run40.png,
>>>>>>>>>>> the precip forcing could be way off. But obviously
>>>>>>>>>>> snow advection helps a lot. Snow flooding, if it
>>>>>>>>>>> overestimates ice, then turn it off, not big deal
>>>>>>>>>>> (since what we do is to make the fields look like
>>>>>>>>>>> observations). As for thsice, I don't know what is going
>>>>>>>>>>> on. But for any ice thermodynamics that involves ice
>>>>>>>>>>> salinity (if thsice uses ice salinity), there might be
>>>>>>>>>>> a singularity in the formulation (I had such feeling
>>>>>>>>>>> before, but I could be wrong).
>>>>>>>>>>>
>>>>>>>>>>> Jinlun
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> MITgcm-devel mailing list
>>>>>>>> MITgcm-devel at mitgcm.org
>>>>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>>>>>>
>>>>>
>>>>
>>>> --
>>>>
>>>> Jinlun Zhang
>>>> Polar Science Center, Applied Physics Laboratory
>>>> University of Washington, 1013 NE 40th St, Seattle, WA 98105-6698
>>>>
>>>> Phone: (206)-543-5569; Fax: (206)-616-3142
>>>> zhang at apl.washington.edu
>>>> http://psc.apl.washington.edu/pscweb2002/Staff/zhang/zhang.html
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> MITgcm-devel mailing list
>>>> MITgcm-devel at mitgcm.org
>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>>
>>> _______________________________________________
>>> MITgcm-devel mailing list
>>> MITgcm-devel at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
More information about the MITgcm-devel
mailing list