-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[0.25deg config] Sub-mesoscale parameterisation #181
Comments
I don't know why the MOM6 efficiency coefficient ( |
I also don't recall why we used |
I think |
Thanks @aekiss you are right. They are the opposite. So there are basically 2 options:
|
The relevant action is being tracked in #254, so this issue is now closed. |
This parameterisation is used to account for the unresolved submesoscale mixed layer restratification.
As discussed in the namelist discussion,
However, there are some differences in implementation between MOM5 and MOM6.
Comments:
MLE_MLD_DECAY_TIME = 2.592E+06
, (30 days) accounts for the diurnal circle. The time-filtering method is unique to MOM6 and not used in MOM5.MLE_FRONT_LENGTH
is set to 500.0 now instead of 5000.0 in OM2. This is because, in OM2, the front length acts as a floor value calculated asfront_length_inv = min(front_length_const_inv, coriolis_param/(epsln+wrk1_2d*buoy_freq_ave))
. In MOM6, it is a single value globally. That might be the reason why OM4 did a few tests in their paper, using either 200m or 500m but only for 1/2 deg configurations. Further testing is needed for our 0.25deg configuration. In another ACCESS configuration, they use 500.0 forMLE_FRONT_LENGTH
, hence we have adopted the same value for our 0.25deg setup., because the GFDL OM4 paper found that the MLD estimation based on density differences with the surface was unreliable. This is consistent with the usage ofMLE_USE_PBL_MLD = True
use_hblt_equal_mld = .true.
of OM2.Other relevant discussions can be found here #104.
The text was updated successfully, but these errors were encountered: