[MITgcm-support] 2D setup
David Hebert
david.hebert at nrlssc.navy.mil
Fri Jul 16 08:41:51 EDT 2010
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
>
More information about the MITgcm-support
mailing list