[MITgcm-devel] exf: u/v-wind interpolation and cubed sphere

[Martin Losch]

Since I seem to be the only one in this discussion I have to make  
sure that I keep it alive (o:

The more I think about the code in exf_set_uv.F that deals with the  
north pole, the more I think it's wrong (I need to be bit provocative  
here in order to get more participants). I have a better (but more  
expensive) suggestion for dealing with the North Pole. It's only  
restriction is that the data-grid is a regular lat lon grid with no  
wind-velocity grid-point at 90N:

1. Do interpolation and rotation of vectors as is (without the offset  
business, that is offset=0 always or file version 1.11)
2. discard all wind velocities on model grid that are within the  
northern most latitude circle of the the data grid (yG/C > data_lat 
(end)), leaving a gap of radius 90deg-data_lat(end) around the north  
pole.
3. exchange u/vwind fields on model grid
4. interpolate discard values from model grid, e.g. using some radius  
of influence that is large enough so that values from all sides of  
the gap are used, e.g. twice or 2.5 times the radius of the gap.
The advantage is that we don't have to worry about direction and  
magnitude of the wind field because outside this gap everthing is  
okay anyway. The disadvantage is that for 4. we need global indices  
to access grid point from neighboring tiles, but that's not a  
principle problem, is it? E.g., for the high res cubed sphere the  
north pole is at the corner of 4 ajacent tiles.

Does this sound feasible?

Martin

On Jun 22, 2006, at 2:52 PM, Martin Losch wrote:

> Hi again,
>
> to follow up on this:
>
> I commented out the lines that reset the variable "offset=2" in the  
> case when yC is is within dyC of the North Pole, so that offset=0  
> always (effectively undoing the latest changes to this file and I  
> don't get these complaints by exf_check_range.
>
> I have to admit that I don't understand how this offset-thing  
> works, but why is the offset 2, when the wind is rotated near the  
> pole. What's happening is that the wind at (i,j) is replaced by the  
> wind at (i-offset,j-offset) which in at least one case means, that  
> all the information about wind and direction is taken from across  
> the pole. Is that correct/indended?
>
> Martin
>
> On Jun 22, 2006, at 11:28 AM, Martin Losch wrote:
>
>> Hi Dimitris,
>>
>> for benchmarking I successfully run the high_res cubed sphere on  
>> our XD1 with 27 cpus (its the ss216t_85x85 configuration), with  
>> monthly forcing, (the *194_92_12.bin files). We have moved the  
>> entire configuration to an IBM p690 and reran the identical  
>> experiment and get this:
>>> STOP in S/R exf_check_range
>>> STOP in S/R exf_check_range
>>> ERROR: 0032-184 MPI was not finalized  in routine unknown, task 10
>>> ERROR: 0032-184 MPI was not finalized  in routine unknown, task 11
>> We didn't save the output in STDOUT.0021 and STDOUT.0023, but  
>> appearently the u/vwinds are wrong (order 10e11) at i=85,j=1 for  
>> one tile (I think it was tile 96), and consequently wrong at  
>> i=85,j=86 for another tile because of exchanges, also at i=0,j=1  
>> and i=1,j=1 at different tiles, and this is reproducible (on the  
>> p690 in Hannover). Task 10 owns tiles 81-88 task 11 tiles 89-96; I  
>> cannot be sure, but I suspect that the grid points that cause the  
>> problem are the four points around the north pole?
>>
>> [BTW, should i change exf_check_range, so that the STOP command is  
>> executed *after* the bi,bj-i,j-loops have finished? That way we  
>> would get the numbers of more than one grid point before the  
>> system stops. Works nicely for me.
>>
>> When we do not read uwind/vwind (that is, when these fields are  
>> zero), the problem goes away.
>>
>> I suspect a problem in the interpolation routines, in particular  
>> lines such as
>>>                     if ( yC(i,j,bi,bj) .gt.
>>>      &                  (90-dyC(i,j,bi,bj)*8.9946e-06) )
>>>      &                  offset=2
>> But that just a wild guess. Do you have any ideas?
>>
>> Martin
>>
>> PS: Unfortunately I cannot reprdouce this with a simpler cs-setup.
>>
>>
>> _______________________________________________
>> 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