[MITgcm-devel] seaice

chris hill cnh at mit.edu
Tue Feb 14 10:41:29 EST 2006 

A.,

  I think it is direct from gad_calc_rhs - see

http://mitgcm.org/cgi-bin/viewcvs.cgi/MITgcm/pkg/generic_advdiff/gad_calc_rhs.F?rev=1.38&content-type=text/vnd.viewcvs-markup

also

if ( my reading of all the if endifs in gad_calc_rhs is ok ) then

  Note - advFac seems to now only be used for tracer conservation in the 
presence of divergent flows/non-linear free surface not to kill 
advection altogether (which surprised me!).

else

  Jean-Michel returns true or false

endif

  As Martin noted there are a lot of if endifs in calc_rhs so maybe I 
missed something.

Chris
Alistair Adcroft wrote:
> Martin,
> 
> The code below doesn't look right - the divergence of fluxes should be 
> split into separate loops and applied consecutively otherwise the scheme 
> will not be monotonic. Also, be sure to use "forward" time-stepping with 
> dst2/3. I'm not sure what code you based this on but I hope it wasn't 
> from gad...
> 
> A.
> 
> Martin Losch wrote:
> 
>> GAD:
>>
>> I have tried using dst3fl (withoug any explicit diffusion). It runs  
>> stably for 20 years now, but now my ice (instead of being too little)  
>> is growing endlessly (37 m in the western Weddell Sea), so I have the  
>> suspicion that I am make severe mistakes: Could someone who  
>> understand gad_calc_rhs have a look at the attached routine and tell  
>> me, if I have done things right? In particular in the update of HEFF,  
>> is it correct to have advFac=1?:
>>
>>>         DO j=1-Oly,sNy+Oly-1
>>>          DO i=1-Olx,sNx+Olx-1
>>>           HEFF(i,j,1,bi,bj)=HEFF(i,j,3,bi,bj) + DELTT *
>>>      &         maskC(i,j,kSurface,bi,bj)*recip_rA(i,j,bi,bj)
>>>      &       *( (fZon(i+1,j)-fZon(i,j))
>>>      &         +(fMer(i,j+1)-fMer(i,j))
>>>      &         -localT(i,j)*( (uTrans(i+1,j)-uTrans(i,j))
>>>      &                       +(vTrans(i,j+1)-vTrans(i,j))
>>>      &                       )*advFac
>>>      &         )
>>
>>
>>
>> Martin
>>
>>
>>
>> On Feb 14, 2006, at 3:57 PM, chris hill wrote:
>>
>>> Martin,
>>>
>>>  These all sound good.
>>>  Technically it should be possible to use gad to do the explicit  
>>> part of ice advection. Jinlun may have comments on whether this  
>>> makes sense algorithmically and on interactions with the implicit  
>>> parts of the ice dynamics.
>>>
>>> Chris
>>> Martin Losch wrote:
>>>
>>>> Hi Dimitris,
>>>> I am probably playing too much with the seaice model right now,  
>>>> but  here are a few points that I'd like to make (and maybe check  
>>>> them in,  even if they break lab_sea):
>>>> 1. I am now sure that there is a bug in advect.F that does NOT  
>>>> affect  lat-lon-grid simulations, but WILL affect cubed-sphere  
>>>> simulations  and all other irregular grid simulations. It's  
>>>> basically an idexing  error (see my previous email). I think I  will 
>>>> just fix that.
>>>> 2. I would like to replace all DXTICE DYTICE SINEICE CSTICE etc  
>>>> with  the proper combination of variables dxF,dxG, etc. from  
>>>> GRID.h. This  will --- at least as far as I can see --- make sure  
>>>> that the grid  information is correct and the same grid parameters  
>>>> that are used for  the ocean are used for seacie.
>>>> Since I want to use the seaice model on a cubed sphere grid, I do   
>>>> care about this. However, this will change the lab_sea and very  
>>>> like  (more dramatically) any cubed sphere set-up that you may  have 
>>>> (I am  currently currently playing with global_ocean.cs32x15  + 
>>>> seaice). Will  I get your OK?
>>>> 3. Advection schemes: for properties such as volume and  fractional  
>>>> area, the advection scheme should not produce negative  (or 
>>>> positve)  overshoots. A 2nd order central difference scheme  does 
>>>> that (eg., can  produce negative thicknesses). The scheme in  
>>>> advect.F is 2nd order  central difference, but I don't understand  
>>>> the time stepping scheme,  so it may be OK. Nevertheless, I  naively 
>>>> think, a positive scheme may  be better, but it is no  longer 
>>>> conservative, eg. 2n-order with flux  limiter (e.g, Hunke's  CSIM5 
>>>> uses MPDATA) or DST3FL that I use  routinely for geochemical  
>>>> tracers. The nice thing is, that all of  these schemes are there  
>>>> (in generic_advdiff), one just needs to pick  one. I have tried  
>>>> dst3fl, but again, I do not understand the time  stepping in  
>>>> advect.F (nor do I understand fully how gad_calc_rhs  works): I  
>>>> have tried dst3fl and I even got it to work, but only  halfway. If  
>>>> I am not mistaken, the DST schemes look as if they are  explicit  in 
>>>> time, that is, h(n+1) = h(n) + gh(n)*deltaT. I can  compute gh (n), 
>>>> but for that I need to know what the different time  levels  are, eg.,
>>>> HEFF(:,:,1,:,:) = current time level?
>>>> HEFF(:,:,2,:,:) = do I need these?
>>>> HEFF(:,:,3,:,:) = ?
>>>> Or do I just update HEFF(:,:,1,:,:) in advect.F?
>>>> Martin
>>>> On Feb 14, 2006, at 2:07 PM, Dimitris Menemenlis wrote:
>>>>
>>>>> Martin and Jinlun, I am out of my depth when it comes to  
>>>>> advection  schemes.  Is there a reason for changing the scheme  
>>>>> that is there  already in pkg/seaice?
>>>>>
>>>>> For cubed-sphere grid right now, I assumed that grid is  
>>>>> rectangular  near the Poles (CS*ICE=1, TNG*ICE=0).  This was a  
>>>>> quick fix to get  going but it is not exact.  So maybe that  
>>>>> explains why you get  different numerical values?
>>>>>
>>>>> Regarding coastal sflux from seaice.  One does expect coastal   
>>>>> regions around Antarctica to be ice/salt factories, but maybe  too  
>>>>> much salt is being rejected.  Carl recently send me some  slides 
>>>>> and  Ph.D. thesis from Dirk Notz:
>>>>> http://ecco.jpl.nasa.gov/~dimitri/Notz/talk_MPI16112005.pdf
>>>>> http://ecco.jpl.nasa.gov/~dimitri/Notz/PhD_thesis_Dirk.pdf
>>>>> suggesting there is considerable uncertainty regarding how much   
>>>>> salt is rejected during sea ice creation.
>>>>>
>>>>> Dimitris
>>>>> _______________________________________________
>>>>> 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
>>  
>>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>

More information about the MITgcm-devel mailing list