[MITgcm-devel] problems with llc grid?

Martin Losch Martin.Losch at awi.de
Wed May 23 06:11:36 EDT 2007 

If I may correct my previous statement: I do see these  
discontinuities also in the 1deg grid. It appears to me that (after  
rerunning make_llc_hr in development/eh3/spgrid/matlab) that dy is  
already quite large along the edges for face 3. I guess that this is  
a hard one to track down.

I am not even sure that this problem cause my run with thsice to blow  
up, but maybe there is an easy solution?

Martin

On 23 May 2007, at 11:33, Martin Losch wrote:

> 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
>
>
> <edges.png>
>
> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel

More information about the MITgcm-devel mailing list