Smaller tide amplitude following model restart

[dksasaki]

Hello all,

I am currently running a simulation at the NW Atlantic with a resolution of 1/25th of a degree, using similar forcing to Ross et al. (2023), but with some modifications to the configurations.

My issue is that tides amplitudes are reduced immediately after restarting my model (figure below) on February 1st.

I tried to update the parameter OBC_TIDE_REF_DATE, but this did not resolve the problem.

Something I noticed in the tide generation script is a line where a date is defined:

    # Tidal amplitudes are currently constant over time.
    # Seem to need a time dimension to have it read by MOM.
    # But also, this would later allow nodal modulation
    # or other long-term variations to be added.
    times = xarray.DataArray(
        pd.date_range('1980-12-01', periods=1),
        dims=['time']
    )

The date in the script I used was set to 2006, while my model is starts on 1993. Could this be causing the issue? I have modified the parameter and restarted the simulation, but any additional insights would be greatly appreciated.

Figure 1: Tide measurements (blue) and simulation results (black).

Thanks for your time!

EDIT - comments on the answer:
All three variables suggested by @yichengt900, @kshedstrom and @andrew-c-ross are probably relevant and should be adopted.

In any case, the most important option is setting RAMP_OBCS = False when restarting the model. According to the @andrew-c-ross's comment, this option 'will start the boundary sea level at 0 and then ramp up even when restarting'. The figure below shows an example of a model restart on February 1st and no reduction in the tides amplitude.

[yichengt900]

Hi @dksasaki,
Thank you for initiating this discussion. From my understanding, the date defined in the tidal generation script should not be causing the issue you’re experiencing. However, other experts may have more insights on this matter.

In the meantime, could you please share your MOM_parameter_doc.all file? This will give us a better understanding of your model configuration, particularly the parameters that might influence the tidal results.

[dksasaki]

Hi @yichengt900

Thanks for answering! I'm attaching the parameter file below.

MOM_parameter_doc.all.txt

BTW, changing the obc tides files did not help. I even tried adding with repeated fields with a second date (2030-12-31) with no improvements in the results.

[andrew-c-ross]

The date in the script I used was set to 2006, while my model is starts on 1993.
I even tried adding with repeated fields with a second date (2030-12-31) with no improvements in the results.

When FMS sees a single time point in the input data, it treats the data as constant in time. The value of the single time point is arbitrary and unimportant; there just needs to be one.

[yichengt900]

Hi @dksasaki,
Thank you for sharing the MOM_parameter_doc.all file. I quickly reviewed it and noticed that at line 1058, the parameter:

TIDES = False                   !   [Boolean] default = False
                                ! If true, apply tidal momentum forcing.

is set to False. This setting disables tidal momentum forcing. If this setting was intentional, please disregard my note. However, considering the critical role of astronomical tidal forcing (tidal potential) in accurately simulating tidal processes—particularly in some ocean regions such as the Gulf of Mexico—you probably want to reconsider this setting.

[dksasaki]

Hi @yichengt900

I agree that this parameter could potentially improve the accuracy of tides. However, it does not affect the reduced tidal amplitudes after restarting the model.

In other experiments where this parameter was enabled, the reduced tides initiated after restarting the model. In the screenshot below, you can see a case when the parameter was set to True, with a restart occurred on April 1st. The issue remained despite this setting.

Not sure if this is helpful, but the reduced tide amplitude occurs over the entire domain. I don't see any signal propagating from the boundaries either 1 hour after the restart. Maybe this could suggest the restart procedure/parameter has some issue instead of the boundaries?

I wonder if the following parameter could be responsible:

REMAP_AUXILIARY_VARS = False    !   [Boolean] default = False
                                ! If true, apply ALE remapping to all of the auxiliary 3-dimensional variables
                                ! that are needed to reproduce across restarts, similarly to what is already
                                ! being done with the primary state variables.  The default should be changed to
                                ! true.

I'll try to run the model using this parameter activated. Please, let me know if you have any other ideas, and thanks for your availability!

[kshedstrom]

You do want REMAP_AUXILIARY_VARS set to True.

Any time anything is different after a restart than it would have been running straight through, you have a bug. I like to debug these things by running very, very short runs and looking for diffs, with DEBUG output turned on. Run for an hour, restart and run the second hour. Also run for two hours straight. What changed in the DEBUG output? I realize it is rare, but I sometimes have the ability to run both runs in the debugger where I can watch things diverge. The DEBUG stuff is still a good clue as to where to look. For some rare bugs, you might need a third hour to get the divergence.

The model has both the body force tides and the boundary tides. I have them both on. Which one is being different for you? Turn on DEBUG_OBC?

[yichengt900]

@dksasaki , can you try the following configurations:

DIABATIC_FIRST = False
REMAP_AUXILIARY_VARS = True 
RAMP_OBCS = False

As @kshedstrom suggested, begin by running a very short simulation (e.g., 3 days) and save the results. Next, conduct a 1-day run, then use the restart from this 1-day run to perform an additional 2-day simulation. Compare the results of 3-day and 2-day restart runs (e.g., restart files or ocean.stats) to ensure they are identical. Once verified, you can consider repeating the experiment to determine if this resolves the issue.

For your reference, I previously opened an issue regarding restart reproducibility when combining REMAP_AUXILIARY_VARS, DIABATIC_FIRST, and OBC.

[dksasaki]

@kshedstrom and @yichengt900 thanks for your answers, I'm working already with the suggestions.

REMAP_AUXILIARY_VARS = True alone did not do the trick though.

Something that I noticed is that the restart file has only one time step, as you can see in the following excerpt of ncdump's output

netcdf MOM.res {
dimensions:
	lath = 396 ;
	lonh = 430 ;
	latq = 397 ;
	lonq = 431 ;
	Layer = 75 ;
	Interface = 76 ;
	Time = UNLIMITED ; // (1 currently)

From what I remember from ROMS and hycom, a perfect restart requires two or more time steps depending on the solver, which would preserve some tendencies in the restart. Would you have comments on this?

Thanks!

[andrew-c-ross]

If it was an issue with only the data saved in the restart files, the boundary conditions should rapidly bring the solution back after the model was restarted. Since the issue persists after restarting, it is more likely either an issue with the boundary condition data being initialized and updated, or else there was an accidental change to the model configuration or boundary condition files before the model was restarted.

You should definitely set RAMP_OBCS = False for anything other than the start of a new run, though, because when true this will start your boundary sea level at 0 and then ramp up even when restarting.

[dksasaki]

@yichengt900 ,@kshedstrom, @andrew-c-ross

RAMP_OBCS = False seems to have done the trick. I wasn't aware this option would still be considered in a restart. Below are the results after a restart on February 1st.

Thank you so much for comments!

[kshedstrom]

That was easy!

MOM6 with the ALE remapping has different restart needs from ROMS. Restarts should be perfect or else it is a bug.

[dksasaki]

In case anyone is wondering what is the impact on the tracers, this is the difference between surface salinity fields of the wrong solution and the correct one after only five days of restarting the model - blue (red) is fresher (saltier) than it should be.

Thanks again!