Update MOM_surface_forcing.F90

[Mark360s]

The adjustment of the code enables reading wind cycling not just 365 daily or 12 monthly, reading the specific wind stress time level instead.

[Hallberg-NOAA]

Thank you for this PR, @Mark360s . I understand where you are going with these changes, but I wonder whether we have gone far enough in being explicit about the frequency for wind forcing using the MOM6 solo driver. Whereas before, we (incorrectly) used the number of levels to set the frequency of the wind stress updates, assuming that if there are 365 entries in a file, it is daily, if there are 12, it is monthly, and otherwise just used the first time level, the new code assumes that if there are between 2 and 12 time-levels, they are monthly means, and otherwise they are daily. I suspect that this might not work properly if there are steady winds, and this code modification certainly would not accommodate winds that are updated 6-hourly (as some are) or another frequency. Rather than relying just on the number of time-levels in a file to guess at what their frequency might be, perhaps we should introduce a new run-time parameter that could be used to specify the wind-forcing frequency, or perhaps we might be able to use the file metadata to ascertain the update frequency rather than guessing. I believe that the latter approach is used in the FMS coupler code that we use to determine the forcing from input files in ice-ocean mode.

[Mark360s]

@Hallberg-NOAA
Dear Robert,
Thanks for your explanation of what I have done to this code. The latter approach you have mentioned is consistent with what I have found. Not sure how to exactly do this by myself... I would compile the model with my brunch and find out whether it works. update the situation using this alternative method later for those who have the same problems... hopefully, we have adjusted the FMS coupler code approach later, and this request could be closed.

[Mark360s]

Update: The adjustment works for me after recompiling and test running. This method gives an alternative way to run the MOM6 ocean-only model with various wind cycling inputs.
I have a little change later like this:
select case (CS%wind_nlev)
case (2:12) ; time_lev = time_lev_monthly
case (13:) ; time_lev = time_lev_daily
case default ; time_lev = 1
end select
To avoid missing constant wind.

Sorry for closing this request incorrectly, and I would like to update and progress MOM6 further~

[Mark360s]

I believe the next step is to create a new parameter reading wind input or try to adjust the approach~
We really want the ocean-only model could read wind input data with more universal options: like not just daily or monthly, and not just 365 or 12-time levels.

[Hallberg-NOAA]

Thank you for this revised commit, @Mark360s.

There are two problems with this commit.

1. We do not accept commits directly from individual users to the community-wide shared main branch. Instead, commits from all individual users should be made via dev/gfdl or dev/ncar or another appropriate development branch. In this case, dev/gfdl is probably the right target branch for you to use.

2. While the proposed revisions do recover the existing cases when there are 12 or 365 or 1 time levels in the input file, and they are going to work as intended for your specific case, the behavior might not be what a user might expect in other cases. For example, if there are 10 time levels, the new code would interpret them as monthly, but if there are 24 time levels, they would be interpreted as daily. So truncating an input file to only include the first few records (as we often do for testing) would silently qualitatively change the results.

My suggestion would be that we add one or two new runtime logical parameters, perhaps MONTHLY_WINDS and DAILY_WINDS, that we would set in surface_forcing_init() via a call to get_param() when (trim(CS%wind_config) == "file"), with default values that might be set based on the value of CS%wind_nlev (e.g., CS%monthly_winds defaults to .true. if CS%wind_nlev=12) and stored in the MOM_surface_forcing control structure, similarly to what is done with the other variables in this module. The periodicity should probably still be based on the number of time levels in the input file, with the time level reverting to 1 when there is only a single time level in the input file, or when DAILY_WINDS and MONTHLY_WINDS are both false. Doing so would have the virtue of giving the user very explicit indications of what is going on and why when the input winds are read in from a file.

Alternately, we might consider adding a MONTHLY_WINDS logical parameter and a real WIND_LEVELS_PER_DAY parameter that would only be used when MONTHLY_WINDS is false, where WIND_LEVELS_PER_DAY would default to 1., but could be 4.0 to support 6-hourly winds or 0.2 for winds that varied every 5 days.