[MITgcm-devel] exf: u/v-wind interpolation and cubed sphere
chris hill
cnh at mit.edu
Fri Jun 23 11:10:04 EDT 2006
Martin,
Hello.
When is Dimitris with you? He and Benny did the interpolation stuff in
exf_ so you could talk to him. It does look weird at 90N/S.
Certainly it does not make sense to have velocity at 90N/S on a
lat-lon mesh, since directions are undefined at that point. It may make
sense to calculate a stream function along with the u/v inputs and
interpolate that to the target grid zeta points (in a 3d, unstructured
cartesian space if need be) and then get u and v from gradients on the
target grid in the region of the input grid pole(s). This will work for
non-divergent inputs, not sure how to deal with the integration constant
for divergent inputs.
BTW - Ed is creating a next generation regrid package that we hope
will do this and much more, but maybe not this year (Ed commenst?).
Chris
Patrick Heimbach wrote:
> Martin,
>
> haven't had time to look into this,
> but I second your suspicion that something is wrong at pole.
>
> The Arctic adjoint shows weird behaviour right over the pole,
> everywhere else gradients are well behaved
> (unfortunately this eventually propagates "outwards").
> Didn't find time to look into the routines.
> I had similar thought re. discarding wind vel. near pole.
>
> More l8r...
>
> -p.
>
>
>
> On Fri, 2006-06-23 at 10:29, Martin Losch wrote:
>> 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
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
More information about the MITgcm-devel
mailing list