[MITgcm-devel] problems with llc grid?

[Martin Losch]

Hi Ed,
thanks for your answer, comment below:
On 23 May 2007, at 16:54, Ed Hill wrote:

> On Wed, 23 May 2007 11:33:21 +0200 Martin Losch <Martin.Losch at awi.de>
> 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.
>
>
> Hi Martin,
>
> OK, I think I understand.  Please bear with me as I re-state your
> observation:
>
> The dyC values match at the edges (as they should!) but these edge
> values are higher than they "ought to be" based on a smoothness
> argument.  That is, the adjacent dyC lengths within each tile are
> appreciably smaller than the dyC values right at the edges.
>
> That's the problem, right?
Yes, but
1. I don't know if it is really a "problem"
2. it also affects rAs, therefore I do not understand what you mean  
by "balance between un-even grid lengths and un-even grid cell  
areas". To me it looks like dy[C,F,U,G] is quite large along the edge  
of face3 and AS A CONSEQUENCE rAs is also quite large along the same  
edge. Where is the balance? According to your description I would  
expect that as dyC gets smoother, the cell areas get less smooth.  
Don't misunderstand me: I am not saying this has got to be a problem.  
I am just wondering if this is what you expect. (please have a look  
at eddy.csail.mit.edu:~mlosch/llc/grid.t009.nc and the other files to  
see what I mean).
If you think that this is OK, I'll shut up and live with this grid.

I am not sure that this feature of the grid is actually causing the  
problems I am having. There are so many other possibilities.

Martin.

>
> If so, then there is a way to "fix" it or to at least strike a  
> slightly
> different balance between un-even grid lengths and un-even grid cell
> areas.  The thing to do is to manually adjust the relative grid  
> spacing
> by adjusting where the grid lines "start" on each logically  
> rectangular
> region during the initial grid generation stage.  I did exactly that
> when I generated the llc grids.  I spent a fair amount of time tuning
> these parameters as I tried to produce grids with relatively "smooth"
> transitions.  Please understand that these were all "eyeball  
> norms".  I
> tried to produce grids with approximately equal-areas and similarly
> shaped cells -- especially along the transition from the lat-long
> region to the cap and at the connections between the top (northern- 
> most
> edge) of the four equator-containing faces and the north-pole- 
> containing
> face.
>
> And I'm certain that there are other ways to approach this smooothness
> issue.  Jean-Michel has written routines that adjust grid cell areas
> and/or grid cell lengths in the vicinity of, for instance, cube  
> corners.
> One can probably apply similar adjustments here.  So that would be
> another way to increase or enforce some measure of smoothness.
>
> Ed
>
> ps - I can show someone how to adjust these things.  Its all there
>      in the scripts and code that generate the llc grids.  It just
>      takes some time to (iteratively) make the adjustments and
>      decide what is/isn't better.
>
> pps - If one could pose a comprehensive norm for "grid goodness"
>       then the entire process could be treated as an optimization
>       problem.
>
>
> -- 
> Edward H. Hill III, PhD  |  ed at eh3.com  |  http://eh3.com/
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel