[MITgcm-support] 2D setup

[Martin Losch]

Hi David,

I would not worry too much: With sNy you will have the same values of T,S,U,V,W,Eta for j=1 and all overlaps in j, so that all you do you keep copying this same value around. It is just weird and I don't think that our instability is really related to this situation, I just cannot rule it out. Earlier I had similar 2D simulations with sNy=1 that worked fine.
All it means is that the MITgcm is not tailored to 2D slabs. If it were, we could just remove all the exchanges in j-direction along with all advection and diffusion and safe some time. But introducing this functionality would make the code less readible, wouldn't it?

Martin

On Jul 16, 2010, at 2:41 PM, 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