[MITgcm-support] 2D setup

[Jean-Michel Campin]

Hi David,

I disagree with Martin's point of view:
For 2-D (x-z or y-z) set-up, when you use the default exchange subroutines
(i.e., not exch2), there are specific pieces of code that deal with
2-D cases (test for Nx==1 or Ny == 1). Therefore, it should be safe
to use Ny=1 in our case.
However, you still need a large enough overlap size
( Olx=Oly >= 2 in general, >= 4 for advection scheme 7, .... ).

Cheers,
Jean-Michel

On Fri, Jul 16, 2010 at 07:41:51AM -0500, David Hebert wrote:
> Does this suggest that when running a higher order advection scheme true  
> "2D" Ny=1 is not really appropriate? And it would be best to set sNy to  
> at least OLy?
>
> Thanks,
>
> David
>
>
>
> On 06/23/10 08:43, Martin Losch wrote:
>> I think 33 needs an overlap of at least 2 or 3. I thought that this would be caught by the model somewhere, oh well.
>>
>> In fact, it is weird to thave sNy=1 and Oly=3. I means that when you do an exchange you put 1-Oly+1:1 onto 2:Oly+1 and vice versa, so you basically keep replacing the overlaps by each other. Maybe unrelated, but we had a problem with such a configuration and advection scheme 70 (which requires Oly=4). It did not blow up right away, but after a few thousand time steps. When we increased sNy from 1 to 8 and 16, the situation became much better and the model stayed stable. We assume that by introducing a few horizontal points we add additional friction which damps the energy of the system, but we cannot rule out that it is related to Oly being larger than sNy.
>>
>> Martin
>>
>> On Jul 16, 2010, at 2:10 PM, David Hebert wrote:
>>
>>    
>>> Hi Martin,
>>>
>>> Thanks for response. It turns out that in SIZE.h I had set OLy=1, thinking I only had one grid cell in that direction. WHen I changed to OLy=3, the problem went away and simulation ran as expected. Not sure if the issue is related to the advection scheme I was specifying (33 for both tempAdvScheme and saltAdvScheme) or something else.
>>>
>>> Thanks,
>>>
>>> David
>>>
>>> On 06/23/10 05:08, Martin Losch wrote:
>>>      
>>>> Hi David,
>>>>
>>>> no reply yet? I think this configuration should work, and I think that there are example setups like this, e.g. internal_wave
>>>> But since it crashes in the first step, it should be easy for you to debug. First step: set debugLev=2, and you'll get more model "statistics".
>>>>
>>>> Martin
>>>>
>>>> On Jun 24, 2010, at 10:57 PM, David Hebert wrote:
>>>>
>>>>
>>>>        
>>>>> Hello all,
>>>>>
>>>>> I would like to run a very simple, 2D simulation with tides on E/W boundary and a specific T/S structure, and flat bottom. It seems that T/S are crashing after the first timestep (the U  continues to timestep). T/S are initialized good, but go to zero after 1st timestep. I'm wondering if I'm missing something regarding the obcs setup.
>>>>>
>>>>> In OBCS_OPTIONS.h I have specified #undef ALLOW_OBCS_NORTH and #undef ALLOW_OBCS_SOUTH. Then in data.obcs I have specified boundary files for U/T/S on East/West only. Relevant settings from data.obcs:
>>>>>
>>>>> &OBCS_PARM01
>>>>> OB_Ieast=1*-1,
>>>>> OB_Iwest=1*1,
>>>>> useOBCSprescribe=.TRUE.,
>>>>> OBWuFile='OBWu.bin',
>>>>> OBWtFile='OBWt.bin',
>>>>> OBWsFile='OBWs.bin',
>>>>> OBEuFile='OBEu.bin',
>>>>> OBEtFile='OBEt.bin',
>>>>> OBEsFile='OBEs.bin',
>>>>>
>>>>>
>>>>> I thought it would be periodic in N/S in this case, but perhaps I am mistaken. Is there a conflict with useOBCSprescribe and 2D, such as applying tref/sref on N/S boundary?
>>>>>
>>>>> Thanks for any suggestions you might have regarding the setup.
>>>>>
>>>>> David
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>        
>>> _______________________________________________
>>> 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
>>    
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support