[MITgcm-devel] problems with llc grid?

[Martin Losch]

Hi,
I am moving this to the development list, as it seems to me that this  
should not only affect me, but everyone using an llc grid.

I include a plot of dyC (taken from the  
llc45x45x180_lonshift_correctededgeval_?.mitgcm) along the face edge  
between face 2 (tile8) and 3 (tile9). The last northern-most row of  
dyC in tile8 is the same as the first row in tile9, which is exactly  
what we want, BUT the value of this row is larger than both the next  
rows away from the edge, so that you have a "spike" in dyC when you  
go across this edge. All dy? fields have this problem, dyU is exacly  
like dyC, dyF and dyG do not have the "spike" in both face2 and 3,  
but only in 3 because ny is only 45 for them. It's also visible in rAs.
Also the corresponding thing is visible in dxC, (between face3 and  
face4) etc.
I assume that the problem (if it is one) is somewhere in  
compute_grid_perface_nX.m because I don't see this in the 1deg  
version of the llc grid?

Ed, maybe you can have a quick look at compute_grid_perface_nX.m and  
tell my what's wrong so we can correct that.

Martin


-------------- next part --------------
A non-text attachment was scrubbed...
Name: edges.png
Type: image/png
Size: 17389 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20070523/3ca8a48d/attachment.png>
-------------- next part --------------

On 22 May 2007, at 16:02, Martin Losch wrote:

> You are right about the grid, what how can I check that? It occurs  
> between face 1 (tile4 in my case) and face 3 (tile9). I have copied  
> my grid files (all netcdf, sorry) to eddy.csail.mit.edu:/u/u0/ 
> mlosch/llc along with my recent thsice_snapshots (the last 9  
> timesteps).
>
> If you have a look at grid.t008.nc, dyC, dyU, rAs, rAz, they look  
> different from dyF, dyG, rA, rAw respectively (the latter looking  
> much better), the same is true for grid.t004.nc
>
> If you now have a look at grid.t009.nc and the corresponding  
> fields, they all seem to have a maximum along the face edge (the  
> values are the same for both tiles 8 and 9, but both possibly too  
> large).
> Equally, dxF, dxG, etc have the problem along the other edges.
> Do you see what I mean? It looks like we still do not have the grid  
> right. Can this be the source of the problem?
>
> Martin
>
> On 22 May 2007, at 15:37, Jean-Michel Campin wrote:
>
>> Hi Martin,
>>
>> Nothing crucial has been added since checkpoint59b, so it's OK.
>>
>> And I agree, Pb comes from the advection (likely advection of
>> Qice), so it's not surprising that it works with seaice only.
>> It's worth to re-run with thsiceAdvScheme=1 (just to be sure).
>> But in general, with this implementation of sea-ice advection,
>> I think it's very sensitive to anything that is not right, and
>> specially with non-linear advection scheme (like 77).
>> I will take a look at the code, but what about the grid ?
>> If something is not perfectly right, you might not see it
>> anywhere else.
>>
>> Cheers,
>> Jean-Michel
>>
>> On Tue, May 22, 2007 at 09:43:25AM +0200, Martin Losch wrote:
>>> Hi Jean-Michel,
>>>
>>> thanks for your comments:
>>>
>>> It's working with seaice only (usethsice=.false.)
>>> and I have an old run with thsice turned on and a advection = 1,
>>> which ran for 100 years even with a long time step of 6h. I am
>>> rerunning this run right now because I cannot remember what I did  
>>> there.
>>> I am running with relatively recent code (checkpoint59b, but not the
>>> very latest).
>>> It points to
>>>> - some Pb in thsice_advection related to CS grid.
>>> In particular if I don't use thsiceAdvScheme=1, right?
>>>
>>> I am still puzzled that it blows up after 10 year, plus that it  
>>> shows
>>> first in the temperature variables (and so slowly), but that again
>>> points to problems in the advection, right?
>>>
>>> Martin
>>>
>>> On 21 May 2007, at 20:52, Jean-Michel Campin wrote:
>>>
>>>> Hi Martin,
>>>>
>>>> I did look at your previous plots, and it was happening
>>>> at the face edge; and now it seems to be also the case.
>>>> I suspect that it's related to the edges, and as I wrote earlier,
>>>> lot of things related to ice moving from 1 face to the other
>>>> have not been seriously tested.
>>>>
>>>> It could be:
>>>> - the grid files.
>>>> - some exch in seaice that are wrong (since your 1rst e-mail, I
>>>> checked
>>>> in few fixes that might do it. Are you running with those fix ?)
>>>> - some Pb in thsice_advection related to CS grid.
>>>> - some problem in the ice-dynamics at the edge (but it's unlikely
>>>> since it
>>>>  happens with LSR & EVP).
>>>> And I forgot: is it OK with 1rst order advection scheme ?
>>>>
>>>> Cheers,
>>>> Jean-Michel
>>>>
>>>> On Mon, May 21, 2007 at 11:41:17AM +0200, Martin Losch wrote:
>>>>> Hi Jean-Michel,
>>>>> can I remind you of the problem I had earlier? I have been able to
>>>>> reproduce it with a slightly different configuration: EVP  
>>>>> instead of
>>>>> LSR but still thsice with advScheme=77.
>>>>> This time it's not the point 1,8, but 1,6 at the tile (and face)
>>>>> edge.
>>>>> Again it's Tsrf/Tice1/Tice2 that "slowly" (within a few time  
>>>>> steps)
>>>>> go off and then the model crashes. I find this very difficult to
>>>>> understand as it happens on 8th hour on the 9th day of the 10th  
>>>>> year
>>>>> of the integration (my forcing is climatological, so no special
>>>>> years).
>>>>>
>>>>> What can I do to narrow down the problem?
>>>>>
>>>>> Martin
>>>>>
>>>>> On 11 May 2007, at 16:51, Jean-Michel Campin wrote:
>>>>>
>>>>>> Hi Martin,
>>>>>>
>>>>>> I don't have time right now to look at this, but will do
>>>>>> later on.
>>>>>> But just about this:
>>>>>>> point is on the tile boundary does not seem to be a problem,
>>>>>>> although
>>>>>> Is the weird point also at a face boundary ?
>>>>>>
>>>>>> We cannot exclude some problems in CS-exchanges with seaice/ 
>>>>>> thsice
>>>>>> since it has never really been tested before (or, not that I  
>>>>>> know).
>>>>>>
>>>>>> I also have few questions for you, but in an other e-mail.
>>>>>>
>>>>>> Jean-Michel
>>>>>>
>>>>>> On Fri, May 11, 2007 at 03:51:00PM +0200, Martin Losch wrote:
>>>>>>> Hi Jean-Michel,
>>>>>>>
>>>>>>> could you have quick look at
>>>>>>>
>>>>>>> authors: /u0/u/mlosch/thsice_snapshot.0000061128.t009.nc
>>>>>>>
>>>>>>> The last 34 time steps of a llc (2deg) integration  
>>>>>>> (deltaTtracer =
>>>>>>> 1h, deltaTmom = 1200sec, so we are at end of January of the  
>>>>>>> seventh
>>>>>>> year with climatological forcing). The integrations runs without
>>>>>>> any
>>>>>>> obvious problems (I guess that the velocity is noisy, because my
>>>>>>> viscosity is not high enough), until suddenly it stops (in  
>>>>>>> fact is
>>>>>>> doesn't even stop on my computer, it just stalls and doesn't do
>>>>>>> anything until I kill the job).
>>>>>>>
>>>>>>> U,V,T,S,Eta and other variables do look "normal" (no deep
>>>>>>> temperature
>>>>>>> anomaly, no convection due to instability), except for the last
>>>>>>> time
>>>>>>> step where everything is NaN/Inf. So no warning sign in the  
>>>>>>> ocean
>>>>>>> whatsoever.
>>>>>>>
>>>>>>> In thsice_snapshot.0000061128.t009.nc, you'll see that Tsrf is
>>>>>>> strange in one point at the last time step (-290degC), but  
>>>>>>> Tice1/2
>>>>>>> and Qice1/2 do develop some weird behavior in that point over  
>>>>>>> time.
>>>>>>> Do you have any idea what could be going on there? Where  
>>>>>>> should I
>>>>>>> look?
>>>>>>>
>>>>>>> I am using recent code (2days ago), thsiceAdvScheme=77 (with  
>>>>>>> 1 I do
>>>>>>> not have this problem and can run with deltaT=6h for 100 years),
>>>>>>> and
>>>>>>> dhSnowLin=0.1, fracEnFreez = 0.4, hNewIceMax = 1., The fact that
>>>>>>> this
>>>>>>> point is on the tile boundary does not seem to be a problem,
>>>>>>> although
>>>>>>> I cannot exclude it.
>>>>>>>
>>>>>>> Martin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
>