[MITgcm-devel] seaice adjoint and EVP

Martin Losch Martin.Losch at awi.de
Fri Jun 1 16:25:00 EDT 2007 

Dimitris,

any news?

I have created an idealized domain for testing the seaice dynamics  
and I have found that one of the critical variables is the  
"delta" (the "scale" for the strain rates, \zeta = P/(2\Delta) etc.).  
This term can become very small leading to very large (and noisy)  
\zeta and \eta. In the code, Delta = Max(Delta,SEAICE_EPS) and  
SEAICE_EPS = 1e-10. I have found that in other models this parameter   
is rather 2e-9 to 5e-9 (although this may be relatively arbitray).  
With 5e-9 I find less noise in \zeta and \eta, so maybe that's worth  
a try. (Unfortunately, SEAICE_EPS is used in other circumstances as  
well, but that should be a real problem, just changes the resolution  
for various reasons).

Martin

On 29 May 2007, at 19:40, Martin Losch wrote:

> Hi Jinlun, Dimitris,
>
> I have followed Jinlun's suggestion and set dx = dx/2 in data, so  
> that now we have an Arctic solution that is not really arctic  
> anymore, everything is shrunk by a factor of 2. Except for the  
> timestep which is still deltaT = seaice_deltaTdyn = 900sec,   
> seaice_deltaTevp = 10sec, and with that the elastic parameter being  
> 1/3 the evp relaxation timescale is 300sec. The forcing is DAILY,  
> the resolution about 13km, basically 1/8th of a degree.
>
> Bottom line: I don't see any noise like Dimitris does, no stripes  
> in the velocities.
> I put the netcdf file (10 day snapshots of the first year) here:
> http://mitgcm.org/~mlosch/aomip/runtst/diags2D.0000000000.glob.nc
> in case you want to see for yourself.
>
> Because of the really short relaxation time scale (compared to the  
> forcing timescale) the evp solution is almost exactly VP, that is,  
> almost all point fall onto the ellipse and there a very few points  
> inside the ellipse, and certainly none outside.
>
> Where does Dimitris noise come from? Could it be that is has to do  
> with the stability in the ocean? Dimitris, could you do a run with  
> deltaT = 900 or 600 instead of 1200, just to make sure that we are  
> not chasing any ghosts?
>
> Martin
>
> On 26 May 2007, at 06:37, zhang at apl.washington.edu wrote:
>
>> Martin,
>>
>> Are you using daily forcing? What is the time step? I wonder what  
>> makes
>> the problem go away. Maybe this thing is very resolution  
>> sensitive. Do you
>> want to try to artificially reduce the grid size, like adding  
>> lines like
>> DX*0.5 in the code?
>>
>> Jinlun
>>
>>> Hi there,
>>> I am about to go home for an extended weekend, but I have give you
>>> the latest news on EVP:
>>>
>>> I have tried to reproduce Dimitris' stripes in a configuration that
>>> is similar to his: it's basically Ruediger Gerdes' Arctic grid:
>>> rotated spherical grid with 1/4th degree resolution, so  
>>> approximately
>>> 25 to 27km resolution. This is a little coarser than Dimitris 18km,
>>> but that's what I have. It's basically the grid of the AWI
>>> contribution to AOMIP.
>>>
>>> The run is terrible because we don't have open boundaries, the
>>> initial conditions are very noisy and the surface forcing has all
>>> sorts of funny things in it, eg. a nice jump across the 0-meridian,
>>> which is also impressed onto the surface fields in the run, oh well.
>>>
>>> But I do not see the stripines or noise that Dimitris sees in his  
>>> evp
>>> solution (I have 180 days by now). In fact with the default LSRerror
>>> = 1e-4, the yield curves of the EVP solution are much better than
>>> those of the LSR solution. I'll make some netcdf files available,
>>> once these runs are finished (only one year runs, but still).
>>>
>>> Martin
>>>
>>> On 24 May 2007, at 18:20, Jinlun Zhang wrote:
>>>
>>>> Martin,
>>>> I would think that the noisy log10(1-area) means velocities are not
>>>> smooth in central arctic. We would likely see that if we make a log
>>>> plot of velocity.
>>>> Jinlun
>>>>
>>>> Martin Losch wrote:
>>>>
>>>>> Hi Jinlun,
>>>>>
>>>>> the velocities are quite smooth in the central Arctic, aren't
>>>>> they,  just along the ice edge I see problems. However, where does
>>>>> the noise  in the log10(1-area) plots come from? That seems to me
>>>>> to be a  different issue. I am working on reproducing these
>>>>> problems. Maybe  I'll find out something down that route.
>>>>>
>>>>> Martin
>>>>> On 24 May 2007, at 17:58, Jinlun Zhang wrote:
>>>>>
>>>>>> It is not just over open water, but also in the central arctic.
>>>>>> However, the noise is suppressed with 1s timestep over both open
>>>>>> water and pack ice. So I start to think perhaps nothing is
>>>>>> wrong,  just needing a small timestep.
>>>>>> Jinlun
>>>>>>
>>>>>> Martin Losch wrote:
>>>>>>
>>>>>>> I have a new feeble theory for the noise in the evp solver over
>>>>>>> open  ocean:
>>>>>>>
>>>>>>> heff = 0 over open ocean, therefore seaiceMassU/V = 0.
>>>>>>> momentum equation in seaice_evp is discretized (in time) as
>>>>>>> m*duice/dt = -m dphi/dx + tau_air + cd*(uice-uocean) + m*f*vice
>>>>>>> +   \nabla\sigma
>>>>>>> m*(uice(n+1)-uice(n))/dt = -m dphi(n)/dx + tau_air(n) - cd*(uice
>>>>>>> (n +1)- uocean(n)) + m*f*vice(n) + \nabla\sigma(n),
>>>>>>> so coriolis is explicit, ice-ocean stress is implicit. if the
>>>>>>> mass  m  is zero (and zetaMin=0, so that zeta=eta=press = 0 over
>>>>>>> open  ocen)  this reduces to
>>>>>>> cd*uice(n+1) = tau_air(n) + cd*uocean(N)
>>>>>>> so that uice ist a purely diagnostic quantity and not time
>>>>>>> stepped.  cd is a function of uice-uocean at the nth time step,
>>>>>>> averaged to  center points and the averaged back to velocity
>>>>>>> points.
>>>>>>>
>>>>>>> Dimitris, could that be the problem, somehow I don't think so,
>>>>>>> but  you can try by putting a minimum seaiceMassU/V in
>>>>>>> seaice_dynsolver.F,  say seaiceMassU = max
>>>>>>> (seaiceMassU,SEAICE_rhoIce*0.05)
>>>>>>>
>>>>>>> Martin
>>>>>>>
>>>>>>> On 22 May 2007, at 18:59, Jinlun Zhang wrote:
>>>>>>>
>>>>>>>> Hi Martin,
>>>>>>>> Yeah, we are sort of stuck, but hey it is very interesting
>>>>>>>> and   revealing.
>>>>>>>> I would vote against masking ice velocities over open water
>>>>>>>> because, as mentioned earlier, the ice velocities would be
>>>>>>>> wrong  at  ice edge and the ice velocity discontinuity at ice
>>>>>>>> edge will  get  into ocean. (o:. We don't do the masking with
>>>>>>>> LSR solver,  perhaps  we can avoid doing that with EVP.
>>>>>>>> Jinlun
>>>>>>>>
>>>>>>>> Martin Losch wrote:
>>>>>>>>
>>>>>>>>> Hi Jinlun,
>>>>>>>>> the evp-solver is only in place for the C-grid. I don't have
>>>>>>>>> the  time  to code the solver for the b-grid now. The b-grid
>>>>>>>>> code (for  LSR) is  still working, but I have not kept it up
>>>>>>>>> to  date, so  there may be a  few thing different other than
>>>>>>>>> the  different grids.
>>>>>>>>>
>>>>>>>>> In general I though that the c-grid is perfect for evp as all
>>>>>>>>> the   discretizations fall in place naturally. Only for this
>>>>>>>>> \delta  term  one needs to average from center to corner
>>>>>>>>> points  and vice  versa  (have a look at
>>>>>>>>> seaice_calc_strainrates and  seaice_evp).  However,  there may
>>>>>>>>> be issues with the coriolis  terms (commonly a  problem with
>>>>>>>>> the c-grid).
>>>>>>>>>
>>>>>>>>> Actually, Elizabeth told us that she masks ice velocities
>>>>>>>>> over   open  water in CICE.
>>>>>>>>>
>>>>>>>>> Now we are a little stuck, aren't we?
>>>>>>>>>
>>>>>>>>> Martin
>>>>>>>>>
>>>>>>>>> PS. I need to be able to reproduce these results myself (I
>>>>>>>>> haven't  been able to, yet), maybe I can debug the stuff this
>>>>>>>>> way.  Via email  etc. it's quite demanding (o:
>>>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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