[MITgcm-devel] seaice

Jinlun Zhang zhang at apl.washington.edu
Mon Feb 13 19:17:19 EST 2006



Martin Losch wrote:

> Hi Jinlun,
> thanks for the quick reply. However, I still have questions, see below:
> On Feb 12, 2006, at 12:36 AM, Jinlun Zhang wrote:
>
>>
>> Martin Losch wrote:
>>
>>> Hi there,
>>> I have (again) questions about the seaice-pkg. I am working on a   
>>> 2x2*cos(phi) deg quasi global (no arctic) model approximately 30  
>>> to  50km resolution in the Weddell Sea (and Ross Sea). I am  forcing 
>>> with  the CORE fields (with daily winds, tair and  humidity), but 
>>> my  problems probably not connected to the forcing.  I use the 
>>> exf-pkg and  kpp and seaice (SEAICE_MULTILEVEL undefined).
>>> My basic problem is that there is not enough sea-ice in the  
>>> Weddell  Sea (and the Ross Sea, but that's a different story). One  
>>> of the  reasons is that the ACC "breaks" through the South Scotia  
>>> ridge (the  extension of the Antarctic pensinsula) into the  Weddell 
>>> Sea and  directly imports warm water instead of staying  further 
>>> north and  introducing the warm water further east into  the Weddell 
>>> Gyre. As a  consquence (or a cause?) there is no  Weddell Gyre to 
>>> speak of and too  little ice (the distribution is  OK, but the 
>>> thickness is too small  towards the north-east of the  Weddell Sea).
>>
>>
>> Hi Martin,
>>
>> The MITgcm sea ice model  is the one I used/tested based on POLES  
>> forcing (http://psc.apl.washington.edu/POLES/model_forcings/ 
>> ModelForcings.html) for Arctic and NCEP/NCAR forcing for both polar  
>> oceans. Some tuning involved. If you got too little ice in the  
>> Weddell/Ross sea, it is likely that the CORE forcing (dynamic or  
>> thermal) is significantly different.
>
> I don't expect perfect seaice in the southern ocean, but something  
> that is reasonable to first order.
>
>>
>>> The funny thing is that, when I turn off the seaice-model, things   
>>> look much better (except that the surface is now too cold, which  I  
>>> would have expected in the absence of ice growth): I have a  strong  
>>> Weddell Gyre and the ACC stays completely north of the  Weddell Sea 
>>> as  it should. The same is true, when I use ncep heat  fluxes and 
>>> surface  field restoring (as in global_ocean.90x40x15).  So 
>>> topography (which  was my first guess) cannot be the reason for  
>>> this behavior, but it is  most likely the seaice that makes the  
>>> Weddell Gyre disappear and lets  the ACC into the Weddell Sea.  
>>> Candiates are:
>>> 1. not likely: buoyancy fluxes: I don't see how the buoyancy  
>>> fluxes  can cause this problem. I have SEAICE_EXTERNAL_FLUXES  
>>> defined, so  that exf does all the work over open water.
>>
>>
>> If you found that surface stress does not affect the ocean cir.,  
>> then it could be due to buoyancy fluxes.
>
> But what can go wrong in the buoyancy fluxes that causes the Weddell  
> Gyre disappear? The fluxes are modified according to ice formation  
> and melt, so that in winter the ocean does not loose enormous amounts  
> of heat and doesn't gain enormous amounts in summer. In fact the  
> oceanic stratification is not too bad with seaice, just too warm near  
> the surface, because the ACC flushes the Weddell Sea.

Hi Martin, I agree. If ocean stratification looks about right, it is 
more likely due to dynamics, driving ACC  into the Weddell Sea.

>>
>>> 2. more likely: momentum forcing: But ... I tried a physically   
>>> sensible stress formulation (seaice_concentration*ocean_ice_stress  
>>> +  (1-seaice_concentration)*ocean_air_stress, see ostres.F with   
>>> SEAICE_TEST_ICE_STRESS_1 defined); and I tried using only   
>>> ocean_air_stress as precomputed by exf_bulkformulae (no influence  
>>> of  ice on stress, the default). Both give similar results, which  I 
>>> don't  understand.
>>
>>
>> Try to just use 0*ocean_ice_stress +  (1-0)*ocean_air_stress and  see 
>> what happens. This would exclude ice dynamics effect on ocean  cir. 
>> if you suspect that ice dynamics is the trouble maker.
>
>
> I'll try that tomorrow (so far I just didn't do anything in ostres.F,  
> basically commented out the enitre routine.).
>
>>
>>>
>>> In order to understand what I am doing when I mess up the code, I   
>>> need to know what the different fields are. As far as I can see,  
>>> the  seaice-velocities UICE and VICE have three time levels, with  
>>> UICE(:,:, 1,:,:) being the most current, and UICE(:,:,2,:,:) being  
>>> the previous  timestep and level 3 probably some intermediate step/ 
>>> auxiliary  variable used in lsr.F. But what are UICEC and VICEC,  in 
>>> what sense  are they different from the first time-level of  UICE/VICE?
>>>
>>> The SEAICE_ORIGINAL_BAD_ICE_STRESS in ostres.F uses a mixture of  
>>> UICE (:,:,1,:,:), UICE(:,:,3,:,:) and UICEC to compute the  
>>> stresses, which  I do not understand at all. Which is the ice- 
>>> velocity to use for  computing ocean-seaice stresses?
>>
>>
>> UICE(1) is the one,  ice velocity, others are all intermediate  
>> quantities for numerical reasons (or stability). Since UICEC is  used 
>> in the dynamics solver, it shows up in ostres.F for an exact  
>> calculation of stress.
>
>
> Yes, but what is UICEC exactly? Or rather, what is the correct, exact  
> stress? The computations in between the #ifdef  
> SEAICE_ORIGINAL_BAD_ICE_STRESS in ostres.F? Unfortunately I don't  
> understand what's going on there, (please excuse my ignorance about  
> sea-ice models, I should probably start reading about sea-ice models,  
> but) what are these terms is ostres.F:

>> DWATN(I,J,bi,bj)*(COSWAT*(GWATX(I,J,bi,bj)-UICE(I,J,1,bi,bj))
>>      &          -SINWAT*(GWATY(I,J,bi,bj)-VICEC(I,J,bi,bj)))
>
> This I can understand: tau = c_d*f(|u_ocean-u_ice|) * Rotation *  
> (u_ocean-u_ice), the rotation is currently zero. But this is what I  
> think should be the stress between ice and ocean. (In fact, I cannot  
> find that term in dynsolver.F, just c_d*f(|u_ocean-u_ice|) * Rotation  
> * u_ocean, so not the relative velocity, but I am probably missing  
> something?), but what are the following terms?
>
>> -( COR_ICE(I,J,bi,bj)*GWATY(I,J,bi,bj)-COR_ICE(I,J,bi,bj)*VICEC 
>> (I,J,bi,bj))
>
> -f*(v_ocean-v_ice), why do you need a coriolis term in the stress  
> formulation?
>
>> (UICE(I,J,1,bi,bj)-UICE(I,J,3,bi,bj))*AMASS(I,J,bi,bj)/SEAICE_DT*TWO,
>
> 0.5*(du_ice/dt)*rho_ice*h_ice? What is the physical meaning of this?
>
> I have to admit that so far I have only used the first term (what the  
> lay-man in me believes is the correct stress, see the current version  
> of ostres.F with SEAICE_TEST_ICE_STRESS_1
> defined.), maybe that is my problem?

UICEC is the average of UICE(1) between different time steps. The above 
piece of code is an old scheme I used to calculate stress.  It does not 
work, blowing up the code. We should just use the current scheme to 
calculate stress.
Dimitris: perhaps we should take ostres.F out to aviod confusion.

Cheers, Jinlun

                         




More information about the MITgcm-devel mailing list