[MITgcm-support] Question About Sea Surface Height (Eta) Behavior in MITgcm

Wed Jul 9 11:11:01 EDT 2025

So Martin’s guess is correct.  Because of:
   useOBCSbalance=.TRUE.,
you are suppressing all volume transport at the boundaries except for tidal transports, which you prescribe on top of that.

D.

> On Jul 9, 2025, at 8:03 AM, Jordi Iglesias <jiglesias at icm.csic.es> wrote:
> 
> Hi everyone,
> 
> Thanks a lot for your comments and help. Following your recommendations, I’m attaching two figures and the namelists. 
> 
> Fig1.jpg shows the MEDSEA parent model, with my domain marked by a red rectangle, as well as the three points where I plotted the SSH from the parent model.
> 
> Fig2.jpg contains three subplots. The top panel corresponds to the SouthWest of Sicily, where I compare the SSH at that point with and without tides from the MEDSEA model. I also include the MEDSEA SSH averaged over my domain (black line) shared in all plots and the MITgcm output (my result) shown as a black dashed line. I repeat this comparison in the south of my domain (cyan) and in Gibraltar (red).
> 
> Note: The Y-axis scales are not shared between subplots, but in all cases, it's clear that the parent model shows a low frequency SSH signal that I’m currently unable to reproduce in MITgcm.
> As you mentioned, probably I should disable the balanced flow option. Additionally, I’m sharing the namelists data and data.obcs, if you have any advice or suggestions, I’d be happy to try them.
> 
> Thanks again for your help!
> Best regards,
> Jordi
> 
> 
> 
> On 8/7/25 17:24, Martin Losch wrote:
>> Hi Jordi,
>> 
>> it would help if you could provide your namelist files. And maybe the customised *_OPTIONS.h files, if they are very different from the standard ones.
>> Do you use open boundary conditions? Balanced flow is maybe an issue?
>> 
>> Martin
>> 
>>> On 8. Jul 2025, at 16:57, Dimitris Menemenlis <dmenemenlis at gmail.com> <mailto:dmenemenlis at gmail.com> wrote:
>>> 
>>> Hi Jodi, perhaps a good place to start would be to understand cause of the larger oscillations in MEDSEA and ROMS, which might then help you diagnose what is missing in your MITgcm configuration.  For example, if the ~10-day oscillation in MEDSEA and ROMS is primarily caused by transport through Gibraltar Strait, then you could look at MITgcm’s transport through Gibraltar Strait to see whether it has been correctly prescribed.
>>> 
>>> D.
>>> 
>>>> On Jul 8, 2025, at 6:13 AM, Jordi Iglesias <jiglesias at icm.csic.es> <mailto:jiglesias at icm.csic.es> wrote:
>>>> 
>>>> Dear MITgcm community,
>>>> 
>>>> Over the past few months, I’ve been struggling to achieve realistic sea surface height ("Eta") results in my MITgcm simulations. I’ve tried several configurations,including non-hydrostatic, quasi-non-hydrostatic, and nonlinear free surface options, but the SSH output often differs significantly from the parent model (the Copernicus Mediterranean analysis, MEDSEA). I’ve attached an example and also shared a link to illustrate the issue. I have tides configured, and the ssh is initialized from MEDSEA data. However, when I compare the SSH output with the parent model (or with a ROMS simulation, for example), it appears to oscillate around a constant value that doesn’t evolve much over time, or changes are very small.
>>>> 
>>>> A summary of my configuration: Horizontal resolution: 1.6 km, NW Mediterranean Sea, Atmospheric forcing: ECMWF, initial ssh set with pSurfInitFile, SphericalPolarGrid, quasiHydrostatic = .TRUE., nonlinFreeSurf = 3, rigidLid = .FALSE., implicitFreeSurface = .TRUE.,
>>>> 
>>>> If any additional parameters would help diagnose the issue, I’d be happy to provide them.
>>>> 
>>>> The temperature, salinity, and velocity fields are generally in good agreement with ROMS and MEDSEA, but I’d really like to improve the SSH performance. Has anyone encountered a similar issue or found strategies to improve SSH in MITgcm?
>>>> 
>>>> Thanks in advance for your help!
>>>> 
>>>> Best regards,
>>>> Jordi
>>>> 
>>>> https://saco.csic.es/s/c2fSgN5RWPRcDSQ
>>>> 
>>>> 
>>>> 
>>>> <Screenshot from 2025-07-08 14-47-52.png>_______________________________________________
>>>> MITgcm-support mailing list
>>>> MITgcm-support at mitgcm.org <mailto:MITgcm-support at mitgcm.org>
>>>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
>>> 
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org <mailto:MITgcm-support at mitgcm.org>
>>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
>> 
>> 
>> 
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org <mailto:MITgcm-support at mitgcm.org>
>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
> <fig1.jpg><data.txt><data.obcs><fig2.jpg>_______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20250709/7b4e865f/attachment.html>