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

Stefano Querin squerin at ogs.it
Thu Jul 10 08:54:35 EDT 2025


Hi Jordi,

Thanks for the insights.

You could also try to:

1. check your phase and (especially) amplitude OB files: maybe the tidal model/database and/or the scripts/tools you are using (TMD or similar...) to extract phase and amplitude (from the tidal model/database) could have some issues;

2. [perhaps more effective...] the "unbalanced" SSH time series (red) shows a (increasing) trend: you could try an "offline" balancing of your OBCS velocity files (before running MITgcm), with a longer timescale (a few days) in order to maintain the tidal variability, but to avoid longer-term SSH drifts (the interpolation of boundary velocities from the nesting to the nested model -almost- necessarily creates even small unbalances along the OBs -e.g., due to the different grids- that, after a few hours/days, add up and cause possible unwanted drifts...).
I don't know if this can work... but you could try...

Cheers,

Stefano


> On 10 Jul 2025, at 13:21:03, Jordi Iglesias <jiglesias at icm.csic.es> wrote:
> 
> Hello,
> 
> Thanks everyone for the advice. I’ve repeated the simulation, this time with useOBCSbalance = .FALSE.
> In the attached figure:
> The top panel shows the comparison between the MEDSEA SSH (black), the MITgcm output with useOBCSbalance = .TRUE. (green), and with useOBCSbalance = .FALSE. (red).
> The bottom panel shows the atmospheric pressure used to force the model over the domain, as it also influences the SSH.
> Additionally, I’ve included another image with a screenshot from a mareograph near Tarragona lon=1.21° E, Lat=41.08° N (unfortunately, I don’t have access to the raw data, only the screenshot). But, it may help to get an idea of the observed nearshore SSH.
> 
> The model behaviour has improved, disabling the balance gives the model more freedom to follow the low frequency variation, which are qualitatively similar to MEDSEA. However, there are still differences in the mean SSH values.
> 
> Do you have any further suggestions I could try to improve the result?
> 
> Best regards,
> Jordi
> 
> 
> 
> On 9/7/25 17:11, Dimitris Menemenlis wrote:
>> 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> <mailto: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 <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 <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 <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 <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 <mailto:MITgcm-support at mitgcm.org>
>>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support <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 <http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support>
> <fig_imp_nobalance.png><tgn_ssh_mareograph.png>_______________________________________________
> 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/20250710/901a0e22/attachment-0001.html>


More information about the MITgcm-support mailing list