[MITgcm-support] 2D setup

[Martin Losch]

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