[MITgcm-support] XYPeriodicity

[Martin Losch]

Hi Gianmaria,

this is all meant to be this way. You interupt the periodicity by  
inserting a wall on (at least) one side of the domain or, as in your  
case by making it an open boundary. There shouldn't be any problems,  
the values of the overlaps are also overwritten by the obcs-pkg.  
(Now, that may not be true for things such as topography, if that's  
the problem the fix would be to extend the topography at the open  
boundary outward by Olx/Oly points.)

I don't know of any flags for this.

Martin

On Mar 2, 2006, at 4:24 PM, Gianmaria Sannino wrote:

> Dear Martin,
>
> I agree with you that the model needs to exchange the obcs (and the  
> other variables) through adjacent overlapping. The problem is that  
> MITgcm tends to exchange the variables also when you are running on  
> one CPU exchanging in this way your eastern end overlapping region  
> variables on the western end region and viceversa. This is evident  
> for example during one of the first exchange, i.e. during the  
> exchange of bathymetry in ini_depth.F where it copies the eastern  
> bathymetry on the western overlapping region and viceversa.
>
> This is because when MITgcm assigns the identifiers to each tile  
> and then defines a map of neighbors for each tile in  
> ini_communication_pattern.F it assigns, when uses one CPU, the  
> eastern side at the western side (and viceversa).
>
> Is there a flag to define/undefine to avoid this kind of problems?
>
> thanks in advance
> gianmaria
>
> On Thu, 2 Mar 2006 08:56:55 +0100
>  Martin Losch <mlosch at awi-bremerhaven.de> wrote:
>> Hallo Gianmaria,
>>
>> that's the way it is supposed to be, the obcs-pkg should  
>> overwrite  these values in the overlaps if necessary (it works for  
>> me with four  open boundaries).
>>
>> Martin
>> On Feb 27, 2006, at 10:53 AM, Gianmaria Sannino wrote:
>>
>>>
>>>
>>> Hello,
>>>
>>>
>>>
>>> I’m trying to set a channel experiment with a real bathymetry  
>>> and  two open boundaries on the eastern and western side. The  
>>> experiment  runs on an alpha monoCPU and this is my SIZE.h:
>>>
>>>
>>>
>>>       PARAMETER (
>>>
>>>      &           sNx =  128,
>>>
>>>      &           sNy =  90,
>>>
>>>      &           OLx =   3,
>>>
>>>      &           OLy =   3,
>>>
>>>      &           nSx =   1,
>>>
>>>      &           nSy =   1,
>>>
>>>      &           nPx =   1,
>>>
>>>      &           nPy =   1,
>>>
>>>      &           Nx  = sNx*nSx*nPx,
>>>
>>>      &           Ny  = sNy*nSy*nPy,
>>>
>>>      &           Nr  =  42)
>>>
>>>
>>>
>>> It seems that in this configuration (MPI is off) in the eastern   
>>> overlapping region there are data from the western side and   
>>> viceversa, in other words it seems that it is working a sort of   
>>> Xperiodicity.
>>>
>>> I’ve seen that in ‘ini_communication_patterns’ one can set
>>>
>>>
>>>
>>>       notUsingXPeriodicity       = .TRUE.
>>>
>>>       notUsingYPeriodicity       = .TRUE.
>>>
>>>
>>>
>>> but also in this case I still have periodicity.
>>>
>>>
>>>
>>> Anyone could help me?
>>>
>>>
>>>
>>> Ciao
>>>
>>> gianmaria
>>>
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>
> ******************************************************
> Gianmaria Sannino   ENEA (Italian Agency for Energy and Environment)
> Climate Project - Ocean Modelling Unit SP 91 - via Anguillarese 301
> S.M. di Galeria, 00060 ROMA, ITALY
> Voice: (+39) 06 3048 6799   Fax: (+39) 06 3048 4264
> e-mail: gianmaria.sannino at casaccia.enea.it
> URL: http://clima.casaccia.enea.it/staff/sannino/
> ******************************************************
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support